On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote:
> On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote:
>
> > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote:
> >
> > > Hi Otto,
> > >
> > > * Otto Moerbeek wrote:
> > > > Hi,
> > > >
> > > > This is amd64 only, it contains some i386 pieces, but those are
> > > > incomplete.
> > > >
> > > > With the diff, install uses ffs2 for the filesystems created during
> > > > install. All boot loaders (except the floppy one) contain support for
> > > > loading a kernel from ffs2.
> > > >
> > > > To test, create a snapshot (see release(8)) with this diff and use it
> > > > to install a new system. You could also use the snap at
> > > > www.drijf.net/openbsd/66. Note that it is unsigned.
> > > >
> > > > Note that when you manually create an fs, it still will be ffs1 by
> > > > default. That is to not disturb other platforms. Use -O2 for ffs2.
> > > >
> > > > Please test and provide feedback. One think you should see is that the
> > > > newfs is much faster and fsck as well, since ffs2 creates inodes
> > > > lazily and thus has much less inodes to check in the typical case.
> > >
> > > I used your provided snap to do a few installations with VMs. The
> > > following things worked as expected:
> > >
> > > * Default install on one disk
> > > * Install on softraid crypto disk
> > > * Install on softraid 1 with two disks below
> > >
> > > I verified each time with dumpfs that FFS2 was used indeed.
> > >
> > > I also checked out a large git repo on the first VM into /home and
> > > pulled the plug to see how fsck behaves. After reboot, fsck marked / as
> > > clean and then I saw the message that init changed the secure level from
> > > 0 to 1, but nothing more happened. I could type so the system was not
> > > hanging, however, it was also not checking /home (which I expected). I
> > > waited for 5 minutes, pulled the plug again and the fsck worked as
> > > normal and the system booted to the login prompt.
> > >
> > > I did that multiple times and each time it stopped on the first run.
> > > After power cycling, everything worked as expected and ... wow, fsck on
> > > FFS2 is indeed fast.
> > >
> > > Cheers
> > >
> > > Matthias
> >
> > Thanks for testing. I am seeing the same problem if I do a vmctl stop
> > -f of a VM. After that, / gets fscked followed by a hang. Another reset
> > fixes things. Going to check if this happens with a standard snap.
> >
> > -Otto
> >
>
> It odes not happen with an ffs1 root. With ffs2, I'm seeing:
>
> WARNING: / was not properly unmounted
> Automatic boot in progress: starting file system checks.
> /dev/sd0a (d7c346af87544f00.a): 1806 files, 41159 used, 463552 free
> (48 frags, 57938 blocks, 0.0% fragmentation)
> /dev/sd0a (d7c346af87544f00.a): MARKING FILE SYSTEM CLEAN
> panic: init died (signal 11, exit 0)
>
> If I go to single user mode, I can run fsck -p, but then the / fs is gone...
> that explains why init would die. Investigating further...
>
> -Otto
>
It looks like something is going wrong with the special case for root
filesystems, a so called hot root. See fsck_ffs/main.c
To be continued.
-Otto
