Re: RFC: live-initramfs 2.x features
* Daniel Baumann <daniel@debian.org> wrote:
> Michael Prokop wrote:
>> * Provide a bootoption which displays the currently executed code.
>> This avoids panic on user's side if something takes longer than
>> usual, so let’s inform the user instead.
> what do you understand under 'display executed code', something like
> what you'd see from set -x?
Jepp. This would allow users to debug initramfs (and provide
screenshots/logs to developers) without having to rebuild it
manually (which sometimes just isn't possible at all).
>>> * Use initramfs keyb functions, rather than re-implenting wheels
>> What's this "keyb functions" about?
>> Isn't this something for live-initscripts or even better
>> initramfs-tools?
> as you know, everything that needs to happen before the actual root
> system is mounted needs to happen in initramfs (everything else can
> happen in early stage of late userspace through sysvinit/upstart/$whatever).
> opening an encrypted volume of the rootfs needs to reside in initramfs,
> and the user has to enter a passphrase. if the user has a localized
> keyboard, he should be able to use it and not need to learn to type his
> passphrase on en_US qwerty.
> that's why initramfs has a function to setup localized keyboards for use
> during initramfs stage. current live-initramfs reimplemented the wheel
> (well, at that time, initramfs didn't have that function yet, it came
> somewhen after etch).
Ah good point, thanks for explanation.
>> * Provide a possibility to verify the boot media. matches_uuid()
>> is a good start but this should be extended further and be made
>> more flexible and secure. (I'm working in this area those days.)
> sounds interesting, could you elaborate a bit for those playing at home?
A situation some users might know is when you're booting a live
system from CD/DVD/USB pen and it fails at a specific point or you
don't get what you expected, being: Kernel and initrd are loaded and
then the initrd searches for the live filesystem (squashfs). If
there's a live filesystem on a *different* device it might be taken
into account for usage. If you're lucky it might just match, in some
cases you're getting a half way broken system and sometimes it won't
boot at all because kernel/initrd <-> filesystem just don't match.
Now, being annyoing for users it's something that can be fixed with
the uuid approach that AFAICS comes from Ubuntu's Casper originally.
But if you're working in IT forensics and/or have special security
requirements this won't be enough. Someone could prepare a device
that fullfills the uuid requirements but provides a hacked
filesystem which does "something you definitely don't want". ;) So
you need additional ways to make sure you're booting the correct
filesystem and that's what I'm currently working on.
>> * Be as backwards compatible as possible. Document where
>> configurations/semantics/bootoptions/... was changed from the
>> user's POV (for a clean upgrade path, wide and fast adoption of
>> live-initramfs 2.x).
> i explicitly do not intent to be backwards compatible in the meaning of
> that old boot parameters will work with the new one. this is a rewrite
> to get rid of the mess. but it will be documented extensively, of course.
Ok.
>> I'd also suggest to cooperate with initramfs-tools developers so all
>> the stuff that's not live-initramfs-specific is integrated in
>> initramfs-tools instead.
> i'll intend to through out everything that is not live specific anyway, yes.
Excellent.
>> Please let me know if I can help anywhere.
> i'll be setting up a plan once the core is done, so that everyone can
> help at the same time.
Perfect, thanks.
-mika-
--
http://michael-prokop.at/ || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/
Reply to: