If the kernel is not located in default directory (/boot/kernel), it fails to mount zfs root during startup regardless of using vfs.root.mountfrom="zfs:zroot" or /etc/fstab record. I use FreeBSD on GPT ZFS Root. [ash@zombie ~]$ gpart show => 34 156301421 ada0 GPT (75G) 34 128 1 freebsd-boot (64K) 162 3145728 2 freebsd-swap (1.5G) 3145890 153155565 3 freebsd-zfs (73G) => 34 156301421 ada1 GPT (75G) 34 128 1 freebsd-boot (64K) 162 3145728 2 freebsd-swap (1.5G) 3145890 153155565 3 freebsd-zfs (73G) [ash@zombie ~]$ gpart show -l => 34 156301421 ada0 GPT (75G) 34 128 1 (null) (64K) 162 3145728 2 swap0 (1.5G) 3145890 153155565 3 disk0 (73G) => 34 156301421 ada1 GPT (75G) 34 128 1 (null) (64K) 162 3145728 2 swap1 (1.5G) 3145890 153155565 3 disk1 (73G) [ash@zombie ~]$ zpool status pool: zroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 Fix: Boot from LiveCD, mount zroot, rename /boot/GCAM to /boot/kernel, reboot :) How-To-Repeat: #cd /usr/src #make installkernel KODIR=/boot/GCAM #shutdown -r now Select 6 (loader prompt) from boot menu and enter: OK unload kernel OK load /boot/GCAM/kernel OK set module_path=/boot/GCAM OK load opensolaris OK load zfs OK boot kernel starts, detects hardware, but at "Trying to mount root from zfs:zroot" stops with "MOUNT ROOT ERROR:" Entering zfs:zroot at mountroot> prompt not helps.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Alexander, Have you tried setting kernelname to GCAM in your loader.conf before booting (it's not documented in loader.conf but it's a part of boot)? Another item I use to switch between kernels is symlink the suckers: $ ls -l /boot/kernel lrwxr-xr-x 1 root wheel 17 Jan 13 17:35 /boot/kernel -> BAYONETTA.r217362 This works well. HTH, -Garrett
Garrett, now I have two kernels on my box: 1. /boot/kernel/kernel â my working customized kernel 2. /boot/GENERIC/kernel â GENERIC kernel I tried the following expreriment: # shutdown -r now wait for loader menu and choose 6 - Escape to loader prompt OK unload kernel OK set kernelname=/boot/GENERIC/kernel OK set module_path=/boot/GENERIC OK load opensolaris OK load zfs OK boot and got the same result: "MOUNT ROOT ERROR" while "Trying to mount root from zfs:zroot" BTW, even if your method would work, it could not help in case of install misconfigured unbootable kernel. Let's say I install misconfigured kernel: # make installkernel KERNCONF=BADKRNL After this I get: 1. bad kernel in /boot/kernel/kernel 2. previous working kernel in /boot/kernel.old/kernel 3. GENERIC kernel in /boot/GENERIC/kernel I reboot and faced with unbootable system (because of BADKRNL as default). In fact we have now completely unbootable system due the bug I've reported with this PR. Also this bug means that from now on we have no possibility to test custom kernels by installing it to alternate directory (with KODIR variable) â it will not boot anyway. Regards, /Alexander On Tue, Jan 18, 2011 at 3:56 AM, Garrett Cooper <gcooper@freebsd.org> wrote: > Alexander, > Have you tried setting kernelname to GCAM in your loader.conf > before booting (it's not documented in loader.conf but it's a part of > boot)? > Another item I use to switch between kernels is symlink the suckers: > > $ ls -l /boot/kernel > lrwxr-xr-x 1 root wheel 17 Jan 13 17:35 /boot/kernel -> > BAYONETTA.r217362 > > This works well. > HTH, > -Garrett > -- /ash
The same happens in 8.0 (with LOADER_ZFS_SUPPORT=YES). I suspect the problem is that unload removes the zpool.cache from memory, so zfs can't find the pool any more. You can see that by doing lsmod before unload. Either reload it like this before boot: load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache or reload everything with boot's kernel & module loader: unload set module_path=/boot/GCAM boot /boot/GCAM/kernel The second way assumes your loader.conf contains zfs_load="YES", which it probably does in this case.
On Wed, Jan 19, 2011 at 9:17 AM, Alexander Naumochkin <alexander.naumochkin@gmail.com> wrote: > Wow! It starts! I've just typed boot GENERIC, and it starts and works! > Thank you very much Garrett! > > This will continue forever in next releases? I think it should be > documented in Handbook. How can I participate? If I can ever :) > > On Wed, Jan 19, 2011 at 12:20 PM, Garrett Cooper <gcooper@freebsd.org> wr= ote: >> >> On Tue, Jan 18, 2011 at 8:37 AM, Alexander Naumochkin >> <alexander.naumochkin@gmail.com> wrote: >> > Garrett, >> > now I have two kernels on my box: >> > 1. /boot/kernel/kernel =97 my working customized kernel >> > 2. /boot/GENERIC/kernel =97 GENERIC kernel >> > I tried the following expreriment: >> > # shutdown -r now >> > wait for loader menu and choose 6 - Escape to loader prompt >> > OK unload kernel >> > OK set kernelname=3D/boot/GENERIC/kernel >> > OK set module_path=3D/boot/GENERIC >> > OK load opensolaris >> > OK load zfs >> > OK boot >> > and got the same result: "MOUNT ROOT ERROR" while "Trying to mount roo= t from >> > zfs:zroot" >> > BTW, even if your method would work, it could not help in case of inst= all >> > misconfigured unbootable kernel. Let's say I install misconfigured ker= nel: >> > # make installkernel KERNCONF=3DBADKRNL >> > After this I get: >> > 1. bad kernel in /boot/kernel/kernel >> > 2. previous working kernel in /boot/kernel.old/kernel >> > 3. GENERIC kernel in /boot/GENERIC/kernel >> > I reboot and faced with unbootable system (because of BADKRNL as defau= lt). >> > In fact we have now completely unbootable system due the bug I've repo= rted >> > with this PR. Also this bug means that from now on we have no possibil= ity to >> > test custom kernels by installing it to alternate directory (with KODI= R >> > variable) =97 it will not boot anyway. >> >> Try set kernelname=3DGENERIC , etc. Or... just load the kernel modules >> and do: boot GENERIC, etc on the loader command line. It's been this way for ages with loader(8), so I doubt it's going to change too dramatically anytime soon :). That being said, the handbook [1] might need to be updated a bit with a working process (or unload needs to be properly fixed to unload everything if it's broken -- not sure). I'll have to see what happens when I issue those commands sometime on the command line. Regardless though -- if the process doesn't work as-is you should submit a doc update for the handbook so that a working process is available for end-users :). Cheers! -Garrett 1. http://www.freebsd.org/doc/handbook/boot-blocks.html
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
comment #0 is thin on details. Regarding comment#4, ZFS root mounting no longer depends on zpool.cache.