Re: Installing on LFS

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

On Mon, 16 Nov 2015, Eduardo Horvath wrote:

> On Sat, 14 Nov 2015, Paul Goyette wrote:
>
> > On Sat, 14 Nov 2015, Paul Goyette wrote:
> >
> > > I've been trying to install NetBSD on an LFS partition.  sysinst allows
> > > me to set the partition table fstype to 4.4LFS but when I tell it that
> > > the partitions are OK, it reports
> > >
> > > 	No bootcode for specified FS type of root partition |
> > >
> > > >Hit enter to continue
> > >
> > > (This is within a qemu virtual machine.)
> >
> > Hmm, OK, it appears that sysinst doesn't know which bootcode to use for
> > lfs partitions.
> >
> > Since lfs version 1 is deprecated, and any new partitions default to
> > lfs version 2, would the following patch be acceptable??
> >
> > Index: md.h
> > ===================================================================
> > RCS file: /cvsroot/src/usr.sbin/sysinst/arch/amd64/md.h,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 md.h
> > --- md.h        26 Jul 2014 19:30:44 -0000      1.1
> > +++ md.h        14 Nov 2015 11:59:00 -0000
> > @@ -66,6 +66,7 @@
> >  #define        BOOTXXDIR       "/usr/mdec"
> >  #define        BOOTXX_FFSV1    "bootxx_ffsv1"
> >  #define        BOOTXX_FFSV2    "bootxx_ffsv2"
> > +#define        BOOTXX_LFS      "bootxx_lfsv2"
> >
> >
> >  /*
> >
> >
> > Similar changes could also be made to other arch's if they support lfs.
>
> Does the amd64 first stage bootloader support LFS?

It seems to work just fine.  I'll admit to not having stress-tested
the system, but I'd expect that, as long as the bootxx_lfsv2 file
doesn't get relocated, it will continue to boot.

I'm definitely not suggesting that anyone use LFS for the root file
system on a production machine!  I just needed a way to boot the
(qemu virtual) machine without having FFS built-in to my kernel.  (I
was testing interaction with FFS and WAPBL modules.)  Adding LFS
support to sysinst was less work than building a custom CD9660+MFS
image!  :)


> Remember, the LFS filesystem cleaner may decide to relocate blocks of
> existing files to other parts of the disk during garbage collection.  The
> the first level bootloaders for several architectures, due to limited
> space, encode a list of disk blocks containing the second level bootloader
> as part of the first level bootloader.  I know sparc works that way, I
> thought x86/amd64 did as well.  Over time, those disk blocks may get
> reclaimed and then your machine won't boot any more.
>
> Now several years ago I did get sparc64 booting from LFS.  Unlike the
> sparc port, the first level boot block is 3.5KB of FCode that is capable
> of interpreting the filesystem metadata.  After enhancing it to understand
> LFS in addition to FFS, and enabling LFS in the second level bootloader, I
> was able to get it to consistently boot from LFS.
>
> Having said that, the way LFS currently works (unless someone's
> significantly enhanced it since that last time I looked) isn't suitable
> for the root fileystem.  Although, theoretically, LFS should be much more
> resilient than FFS even with WABPL, and the kernel should be able to
> recover at least some of a filesystem suffering major corruption even
> without fsck, most of that code does not exist.
>
> FFS has lots of superblocks scattered throughout the disk.  If you lose
> one or two you can still recover the filesystem.  LFS only has one
> superblock at the beginning of the partition and one at the end, and the
> pointer to the inode file (ifile)  is kept there.  Both of them are
> periodically updated when the log is rolled forward.  If something happens
> to both of them, the filesystem is not recoverable.  Since both of them
> are being constantly updated, if something happens during the update you
> could lose both superblocks.
>
> In theory, the ifile should be recoverable by scanning the filesystem
> looking for inode blocks.  That code has not been written yet.
>
> If a fileystem block gets corrupted, it should be possible to recover
> parts of the file by skiping the block and looking for a previous version
> of it earlier in the log.  That code doesn't exist.
>
> Also, because of its recursive nature, some parts of the LFS filesystem
> code had a tendency to deadlock writing the log on occasion.
>
> Eduardo

+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+