Extending zfsboot.c to allow selecting filesystem from boot.config

[Andriy Gapon]

on 21/11/2011 21:13 Florian Wagner said the following:
> On Mon, 21 Nov 2011 12:53:49 +0200
> Andriy Gapon <avg at FreeBSD.org> wrote:
> 
>> Why did you have to specify MACHINE_CPUARCH?
>> Is your OS amd64 or i386?MACHINE_CPUARCH?
> 
> Otherwise I get:
> 
> # make
> "Makefile", line 22: Malformed conditional (${MACHINE_CPUARCH} == "amd64")
> "Makefile", line 27: if-less endif
> make: fatal errors encountered -- cannot continue
> 
> Looking at share/mk/sys.mk in both stable-8 and head I see that
> MACHINE_CPUARCH is only defined in head.

I see.
You still haven't said if your system is really amd64.  But that's not terribly
important.

[snip]

>> Here is the latest version from my tree:
>> https://gitorious.org/~avg/freebsd/avgbsd/trees/devel-20110921/tools/tools/zfsboottest
> 
> This one compiles and combined with zfsboottest.sh from head...
> 
> 1. # ./zfsboottest.sh root
>    The "mountpoint" property of dataset "root/stable-8-r226381" should be set to "legacy".
> 
>    The bootloader from stable-8 didn't seem to care that the mountpoint
>    was set to none, but to get further with zfsboottest I set it to
>    legacy.

The boot loader still doesn't care, neither does zfsboottest program, which you
can execute directly.  The zfsboottest.sh test script does some extra checks to
ensure trouble-free booting and mounting of the root fs.

> 2. # ./zfsboottest.sh root
>    zfsboottest.sh is reading all the files in //boot using
>    boot code and using file system code.
>    It calculates MD5 checksums for all the files and will compare them.
>    If all files can be properly read using boot code, it is very likely you
>    will be able to boot from "root" pool>:> Good luck!
> 
>    ZFS: i/o error - all block copies unavailable
>    ZFS: can't read MOS
>      pool: root
>    config:
>    
>            NAME STATE
>            root ONLINE
>              raidz2 ONLINE
>                gptid/fe19a168-12e0-11e1-9070-deadbeef1028 ONLINE
>                gptid/fe62ed10-12e0-11e1-9070-deadbeef1028 ONLINE
>                gptid/fc93472b-12e0-11e1-9070-deadbeef1028 ONLINE
>                gptid/fd8b167c-12e0-11e1-9070-deadbeef1028 ONLINE
> 
>    Then it just hangs there. I've let it run for a few minutes, but
>    even in a VM with emulated IDE controller the 11MB of files in /boot
>    shouldn't take very long.
> 
>    On repeated runs the "ZFS: i/o error" and "can't read MOS" sometimes
>    are there and sometimes they are not.
> 
> 3. Rebuilt zfsboottest with -g -O0 and ran it in gdb with my vdev
>    devices and one single file. I've attached a gdb session but haven't
>    gotten very far. My C debugging-fu is rather weak ;).
> 
>    The SIGFPE from zfsboottest.gdb.log.2 is not easily reproduced...

Unfortunately the logs that you captured do not reveal a source of the problem.
I think that it would make sense to set a breakpoint at the zfs_mount function
('b zfs_mount').  When the program stops at a break point, you can then 'step'
through the code.  Then examine all arguments upon function calls and local
variables at the interesting places.  For variables that are pointers please
print their dereferenced value (like 'p *x').  This could be time consuming.

Some more straightforward things to (re-)test.
First, are you absolutely sure that the problem never happens without the patch?
 Could you please retest that?  Please do not touch anything under /boot, just
recompile zfsboottest with the patch reverted and run it a few time.
Then, could you please test the patch with the code from head?  Again, no need
to change you real boot blocks, just checkout sys/boot from head, patch it,
recompile zfsboottest and test it.

I hope that we will be able to find the root cause.
Thank you!

-- 
Andriy Gapon