On Jan 13, 2012, at 12:32 PM, Nathan Coulson wrote:

> I still like the idea, that it "adds" to lfs, as opposed to being
> "required" though.  (And by that, I mean leave assumptions out of the
> bootscripts that this was booted on a initramfs/initrd)


I think that's a good design in general, even if you always plan to use the 
initramfs. Besides meaning that the base OS doesn't care how it it was booted, 
it also means you don't need to change the boot scripts if you move (or copy) 
them to the initramfs, because they'll work with or without previous setup.


> I suppose as long as you kept block drivers compiled into the kernel,
> and the initramfs did nothing with modules, that it would never have
> to change between kernel updates.


Right. If you run that way it means you can't do the full-module setup. But you 
already can't do a full-module setup with a direct-boot system so it's no more 
limiting.

And you can mix-and-match -- so long as you have everything you need to mount 
root compiled into the kernel you *can* mount the root and load additional 
modules from your normal disk while still in the initramfs. Currently I do a 
module-in-initramfs system, but I started with the no-modules initramfs, and 
I've been thinking about moving to this hybrid model; they all have their 
advantages.

And to tie in with the previous note; if you write boot scripts that will run 
in either environment (initramfs or main boot) you can simply script the 
initramfs rebuild as part of the kernel build, letting it copy the then-current 
version of your bootscripts into the initramfs. I think I've only got maybe 5 
files that are used exclusively in my initramfs, and the only reason it's not 2 
files (busybox and a shell script) is because it's sometimes handy to be able 
to run "search for a bootable disk" and similar functions as separate 
operations.

        Zach

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to