Re: RFC: live-initramfs 2.x features
Michael Prokop wrote:
> Addon: the network configuration should be made more flexible and
> robust. I've been working on this recently, see:
> http://grml.supersized.org/archives/337-More-robust-network-booting.html
thanks for the pointer, for me it's about implementation, so i'll take
it up in the next round.
> Not sure whether it's already included under "Local filesystems [..]
> as image and plain" (or somewhere else) but Grml's
> isofrom=/fromiso=/findiso=foo.iso feature for booting from ISOs that
> are on any local device (like a local disk) might be interesting as
> well.
that was ment as included, yes.
> * Make sure that additional boot options can be supported without
> having to patch files like scripts/live itself.
yep, that's sorted in my list as 'Distributor specific mode for
overloading of functions'.
> * Scan removable devices before any harddisk devices by
> default and make this configurable (see bootoptions
> removable/removable-usb)
implementation.
> * Logging interface so there are different types of messages (info,
> warn, error,...). Depending on the log-level just the according
> level messages are visible (so informal messages aren't visible if
> the user is interested in error messages only). All boot messages
> should be logged for later investigation.
ack, very nice.
> * 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?
>> * 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).
> With increased usage of LVM/SW-RAID those layers should be
> considered as well.
ack, adding.
> * Make sure configuration of live.conf can be overriden with boot
> options (and maybe even provide a way to disallow this with a
> specific boot option as well :))
ack, adding.
> * Provide a way to include further files (executables, config
> files,...) without having to patch hooks/live itself.
ack, adding.
> * 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?
> * 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.
> 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.
> 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.
> Thanks for taking care, Daniel.
thanks for the feedback.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: