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
