Gordon Schumacher wrote: > Bruce Dubbs wrote: > >> Bryan Kadzban wrote: >> >>>> Ticket 2033 -- initramfs. This way people with crappy software "RAID1 >>>> cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows, >>>> can still boot from those cards. Also, support for MD RAID (*real* >>>> software RAID ;-) ), LVM, and encrypted rootfs would be nice. >>>> >>>> (The mkinitramfs repo linked to from that ticket will already work for >>>> everything above, except encrypted rootfs.) >>> > > Again, this is very, very probably something I will need to do for > Linux-Live support; I'm not 100% positive yet, but I do know that for > the sort of application I am after, I personally will need an initramfs; > I need something that will run on any PC system, which means I can't > just compile the specific drivers I need for boot into the kernel. (And > indeed, that includes fakeraid.) > >> Even it it's poor hardware support, does the frequency of occurrence rise to >> the >> level of needing to be in the LFS book? As several comments in the ticket >> suggest, initramfs would be more appropriate for BLFS, but I'm thinking that >> even that is too much and an updated hint or wiki entry would be more >> appropriate. > > So, here's something to ponder... is it a requirement that the LFS book > be 100% linear? That is to say, that the build process is always identical?
Generally, we want to minimize any differences between builds. When we go to 64-bit, we'll probably need to cover more than one boot loader though. > The reason I ask is this: if you're starting from the XML, using > profiling it's pretty simple to generate different books out of the same > source. Perhaps a hybrid approach could be taken to generating the > HTML, with something like a little JavaScript page at the beginning to > set options like initramfs or package management, and the necessary > links and sections could be displayed accordingly? Failing that, > perhaps a message to the effect of "If you do not require initramfs > support, you may skip this section" with a helpful link to do so? > > Just some thoughts, I'm not sure of the best way for such a thing myself. I'm not saying to not do it. I'm saying that LFS is the wrong place. BLFS is where the user picks and chooses. I don't want to 'hide' anything in the book by having different content for different situations. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
