Date: Sun, 20 Mar 2022 18:03:19 +0300 From: Yuri <yuri@aetern.org> To: questions@freebsd.org Subject: Re: weird issue after -p8 update Message-ID: <be394c90-b7c3-a4a1-639c-2f599b9c199a@aetern.org> In-Reply-To: <20220320141644.k2vp2okgueauwd4i@x1> References: <20220318125525.6k75j3cajbttwyni@x1> <3a22b52e-a167-85b1-67ab-b43cd8953d58@holgerdanske.com> <20220320141644.k2vp2okgueauwd4i@x1>
next in thread | previous in thread | raw e-mail | index | archive | help
Julien Cigar wrote: > On Fri, Mar 18, 2022 at 09:15:40PM -0700, David Christensen wrote: >> On 3/18/22 05:55, Julien Cigar wrote: >>> Hello, >>> >>> I've updated an old HPE Microserver Gen8 from FreeBSD 13.0-p7 to 13.0-p8 >>> and since I'm unable to boot. I thought it was the bootcode but even >>> after updating I'm getting this: https://pasteboard.co/WesqiS5Lrw56.png >>> >>> (this is classical non-uefi bios) >>> >>> any idea? I'm lost. >>> >>> Thanks, >>> Julien >> >> >> The BIOS sees 4 drives. >> >> >> It looks like the FreeBSD bootloader (?) is having trouble reading the >> drive(s) that contain the pool "zroot_jupiler" (is that supposed to be >> "zroot_jupiter"?), which contains the / (root) and /boot filesystems (?). > > yes it is supposed to be zroot_jupiler. > >> >> >> I would boot a 13.0-R installer USB stick into a live system, start a root >> shell, and try to determine if the disks, partitions, ZFS pools, etc., are >> okay. If you run a 'zpool import ...', consider using the "altroot=..." >> and "readonly=on" properties. >> > > I tried, zpool import -NR /foo zroot_jupiler works, no error, scrub > works well too. > > I finally reinstalled the machine and I think there is a serious issue > with that latest -p8 ZFS updates as the machine is unbootable again > (this is what I'm getting: https://gist.github.com/silenius/e7c14d639c058f2734e6ffc078a43646 > > any idea? Seeing as how the previous thread on the list ("Use specific FreeBSD patch version with poudriere") seems to report similar issue with -p8, I was going to ask you to get this reported somewhere developers would be looking (e.g. fs@ or stable@, not questions@), but then I noticed the following commit that came in just now that might be related to your problem: The branch releng/13.0 has been updated by markj: URL: https://cgit.FreeBSD.org/src/commit/?id=b8ae329db949868b8275091da0844ffbff50c65a commit b8ae329db949868b8275091da0844ffbff50c65a Author: Brian Behlendorf <behlendorf1@llnl.gov> AuthorDate: 2021-11-11 00:14:32 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2022-03-20 14:10:36 +0000 Restore dirty dnode detection logic In addition to flushing memory mapped regions when checking holes, commit de198f2d95 modified the dirty dnode detection logic to check the dn->dn_dirty_records instead of the dn->dn_dirty_link. Relying on the dirty record has not be reliable, switch back to the previous method. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #11900 Closes #12745 (cherry picked from commit d7e640cf95f72deeca501d34afed59a0bc9d7940) Approved by: so Security: FreeBSD-EN-22:13.zfs If it's not please use the lists I mentioned above to report this.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be394c90-b7c3-a4a1-639c-2f599b9c199a>