Re: RFC: live-initramfs 2.x features
* Daniel Baumann <email@example.com> wrote:
> As a first step, I'd like to gather a list of features (not their
> implementation!, that's a step later) that you need/want/like/use/miss
> from live-initramfs. So please also list things that the current
> live-initramfs does. If possible, please send in your list until the
> weekend. Here is mine:
> Boot methods
> * Optical media (cd, dvd, bd) and nested images
> * Mass storage (usb-zip, usb-hdd) and nested images
> * Network filesystems (nfs, smb/cifs, afs) and nested images
> * Network protocols (http, ftp, rsync)
> * Network devices (nbd, aoe, iscsi)
Addon: the network configuration should be made more flexible and
robust. I've been working on this recently, see:
> * Local filesystems (ext2-4 etc.), as image and plain.
> * Allow to include system completely in initrd.img (like debirf).
> * Allow tunneling (ssh, openvpn, ike) when network is needed to access
> the root filesystem.
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
> Boot process
> * One time argument handling (with proper respect of live.conf,
> also from /live/live.conf)
> * One time function handling
* Make sure that additional boot options can be supported without
having to patch files like scripts/live itself.
* Scan removable devices before any harddisk devices by
default and make this configurable (see bootoptions
> * Split out late user space to dedicated package (live-initscripts)
> * Distributor specific mode for overloading of functions
> * Release specific compatibility/legacy handling during package
> * i18n/l10n support during early userspace (gettext, po4a)
> * Splash support (plymouth, splashy)
* 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.
* 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.
> * 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
> * Redo persistency from scratch
> * Allow to clear persistency (by reformating the partition) through
> live-initramfs (for the firmware trick: factory reset).
> * cryptsetup for persistency layer
With increased usage of LVM/SW-RAID those layers should be
considered as well.
> * persistency layer on network shares, global and per user.
> * Improved toram (awk progressbar or something like that)
> * Redo login manager support (kdm, gdm, nodm, plain startx on tty1)
* 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 :))
* Provide a way to include further files (executables, config
files,...) without having to patch hooks/live itself.
* 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.)
> * (Almost) whatever is listed in the BTS :)
> * Document stuff properly, both the actual implementation and its
> * Use sane coding style consistently
> * Optimize sh calls for speed and simplicity
> * Drop unused, overly complicated features
> * Synchronise and unify boot parameters
* 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
I'd also suggest to cooperate with initramfs-tools developers so all
the stuff that's not live-initramfs-specific is integrated in
Please let me know if I can help anywhere.
Thanks for taking care, Daniel.
http://michael-prokop.at/ || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/