Date: Sun, 14 Jan 2018 23:22:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221075] geom_flashmap(4) exposes race rendering / on ZFS unbootable Message-ID: <bug-221075-3630-CAG70DIwpf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221075-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-221075-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221075 --- Comment #17 from Sebastian Schwarz <seschwar@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 GEN= ERIC 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 po= ol 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 numbe= r 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 ker= nel 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 G= PT it was 128. After a reboot it was 152. The original GPT was create on Lin= ux 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... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221075-3630-CAG70DIwpf>