Date: Wed, 7 Aug 2019 05:49:12 -0700 From: Enji Cooper <yaneurabeya@gmail.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: freebsd-current <freebsd-current@freebsd.org>, mckusick@mckusick.com Subject: Re: CURRENT: supeblock hash failure - CURRENT wrecking disks Message-ID: <39FB31E6-A8EC-484C-B297-39C19A787E44@gmail.com> In-Reply-To: <20190807103725.3d06ceca@freyja> References: <20190807103725.3d06ceca@freyja>
next in thread | previous in thread | raw e-mail | index | archive | help
(CCing Kirk) > On Aug 7, 2019, at 01:37, O. Hartmann <ohartmann@walstatt.org> wrote: > > Hello, > > today I ran into a ctastrophy with r350671. After installing a fresh compiled > system and rebooted the box, UEFI loader dropped a bunch of errors, like some > hex numbers stating, that a hash/superblock has is wrong and then the booting > stopped at the OK loader prompt. > > Rebooting the machine with the FreeBSD-13-CURRENT image from 1st August 2019 > and trying to fsck the filesystem(s) on the boot SSD (UFS2, journaling and trim > on), lots of unresolved block errors occured. But that didn't help much. > Further, after several checks, I saw some commits to the ffs code recently adn > tried to restore a copy of the superblock of each filesystem (in contrary to > the man page for fsck_ufs, the first backup superblock resides in 192, not > 160!). But things then get even worse, it seems the whole /boot structure is > corrupted, the loader can not find the recent kernel and kernel.old is crashing. > > What's wrong here :-( > > regards, > oh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39FB31E6-A8EC-484C-B297-39C19A787E44>