Gerard Beekmans wrote: > If we decide to go through with this, we'll need to reach a compromise > of course. Just about everybody can implement LVM. Not everybody has the > hardware to implement RAID. That might become a driving force for making > certain choices. But we don't need to completely ignore a RAID setup in > the LFS book, even if we just make a reference to it and include links > to other documentation (BLFS, hints or otherwise) that people can > side-step into to then return to the LFS book once completed. > > It might actually be an eye opener to people that there is more than > simple static partitions. At the point where we create the LFS partition > (Section 2.2) we might as well make mention of other options. I am > convinced this will make the LFS process seem more well rounded. There > will be even more information available to make informed decisions and > allow for more experimentation.
The issue here is that we are using the host's version of lvm, not the LFS version. If we already have LFS building lvm and cpio and perhaps a few other packages is not a big deal, but putting lvm in the Chapter 2 is putting things way out of order. I don't have a problem with mentioning in Chapter 2 that if you know what you are doing, you can use lvm (and/or raid and other filesystems). Starting a new user there, especially with the issue of having the root (and optionally /boot) partitions on LVM makes that first LFS boot a lot more problematic. We have enough problems with GRUB now with the very simple configuration we use. > I'd even want to go as far as considering adding a few options to > Chapter 2. We already have the single partition model and mentioning the > extra partitions (/home, /usr, etc). Would it be a bad idea to provide a > full LVM2 example there too? Yes, it'll potentially increase the load on > support but I feel it's worth exploring. Yes, it should be in BLFS and a forward reference in Chapter 2 wouldn't hurt. > For those that end up deciding against LVM for their build, the > appropriate packages in the book can then be skipped. This means the LFS > book will start to include more optional packages as a result and not > everybody is likely to install all of them anymore. I don't feel that's > a deal breaker. Putting those packages in LFS leaves them unused unless we tell the user to build them in Chapter 5, repartition, and then start over. I don't like that approach. >> There are others. Clearly we don't have to build everything, but the >> first decision is what to omit. Do we ask the user to build a subset >> just for an initramfs and then go back later if a full installation is >> desired? >> > > If an initramfs "shell" is created already, then adding more to it is > easier than trying to add an entire initramfs well after the fact. The > list I snipped is extensive and seems a little much at first glance. > Definitely some decisions will need to be made. Take a look at dracut. That seems to completely automate building the initramfs. However, it needs to be run from a functioning system. >> My overall impression is that BLFS is the right place for this with >> links to the appropriate packages that need to be built. Forward >> references in Chapter 2 and 8.3 (Kernel) and 8.4 (Grub Config) would be >> appropriate. > My "gut" feeling says that a combination of LFS changes along with > forward references to BLFS for other/more detailed/exotic options would > be the best of both worlds. You can't put everything in LFS. I think > everybody will agree on that. Adding more of what has become "common" > these days on many systems to LFS would be worth exploring. Have you looked at section iv recently? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
