[Bug 221075] geom_flashmap(4) exposes race rendering / on ZFS unbootable

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221075

--- Comment #17 from Sebastian Schwarz <seschwar at gmail.com> ---
I tried a few more things:

I zfs send/recv-ed the affected dataset the previously created new FreeBSD
11.1-RELEASE installation. It booted with the GENERIC kernel.

Then I used the FreeBSD installer to try to get a non-booting configuration.  I
succeeded when using diskids for the ZFS pool.  If I used /dev/ada0 the GENERIC
kernel would boot fine.  Also while creating a ZFS pool on /dev/diskid/... I
fiddled a bit with the GPT.  I tried both 4K and 1M alignment.  It made no
difference.  I tried different partition indices.  It made no difference.

Then I took the booting configuration (ZFS pool on /dev/ada0) and dd-ed the
individual backed up partitions from my original setup (containing a ZFS pool
on /dev/diskid/...) over the working ones (the partitions had the same size and
locations).  The system still booted fine with the GENERIC kernel.  So what
difference did the initial ZFS pool on /dev/ada0 really make?

Then I fiddled with the GPT again, trying different types, labels and number of
entries, but it made no difference.  The system remained bootable.

Then I dd-ed the original GPT back into place (the partitions had the same size
and locations).  But now the GENERIC kernel was unable to find my ZFS pool
again.

I tried fiddling with the GPT again.  But it made no difference.

Then I zeroed all space outside of the partitions (GPT & unused space due to
alignment) and manually recreated the partition table.  Now the GENERIC kernel
was able to boot again.

I attached the output of "gpart backup" of both the good and bad GPT.  They
only differ in two places.  The partition type of the ZFS partition and the
amount of entries (is that the number in the fist line?).  The type doesn't
matter.  I can change it to both values and it doesn't make a difference.  That
number in the first line is more interesting.  When I first recreated the GPT
it was 128.  After a reboot it was 152.  The original GPT was create on Linux
using fdisk.

I'm not really sure what's going on.  Creating the ZFS pool with /dev/ada0 like
a fix but doesn't hold up to verification.  Changing the partition table
doesn't matter until it is was zeroed before.  Maybe someone can make sense of
this...

-- 
You are receiving this mail because:
You are the assignee for the bug.