Re: Installing on LFS

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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?

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