Re: RFC: live-initramfs 2.x features
2010/1/19 Daniel Baumann <daniel@debian.org>:
> Hi,
>
> over the time, the current live-initramfs has shown that new features
> cannot be added without ugly hacks and that it needs to be rewritten in
> a more modern, modular way.
>
> 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[0]:
>
> ---snipp----
>
> 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
If by nested images you mean something like a full live iso on a http
server or usb-hdd with supporting kernel/initramfs that loads the
squashfs from it. This has apparently its limits but is still quite
useful in many situations. Some of the limits would go away if you
could kexec the kernel and initramfs included in the image.
> * Network protocols (http, ftp, rsync)
I don't think rsync or ftp is utterly useful - AFAIK they are wget
equivalent (which still has its uses, especially with the cheap RAM
these days).
> * Network devices (nbd, aoe, iscsi)
Nice to have but not utterly useful either. You need special servers
for these and there was no visible performance difference, for me at
least. With nested images you could perhaps use stock iscsi hardware
somewhat efficiently. Still requires iscsid that works in initramfs,
currently patch is required.
> * Local filesystems (ext2-4 etc.), as image and plain.
> * Allow to include system completely in initrd.img (like debirf).
Probably not very useful - the initrd is usually loaded using very
slow code path with many limitation (especially on the image size) -
BIOS. Can be a replacement for wget with less configuration required,
though.
> * Allow tunneling (ssh, openvpn, ike) when network is needed to access
> the root filesystem.
Perhaps adding ssl to httpfs would be the simplest way. I wonder which
of these would run in the limited initramfs environment.
Also consider the security of the vmlinux/initramfs. Is adding more
security later really useful?
>
> Boot process
> ------------
>
> * One time argument handling (with proper respect of live.conf,
> also from /live/live.conf)
> * One time function handling
What is one-time in a live system?
It's always one-time, although possibly repeated.
> * Split out late user space to dedicated package (live-initscripts)
> * Distributor specific mode for overloading of functions
> * Release specific compatibility/legacy handling during package
> build-time
> * i18n/l10n support during early userspace (gettext, po4a)
> * Splash support (plymouth, splashy)
For me l-i works with splashy quite well. There is minor problem that
during l-i there is no progress, not even the "unknown progress", the
bar is just empty. Requires moving around some non-live initramfs
stuff because splashy uses libdirectfb which breaks the system if
initialized twice (such as in initramfs and after system resume). As
d-l is not utterly swsusp compatible to start with this is of little
concern.
> * Use initramfs keyb functions, rather than re-implenting wheels
>
> Features
> --------
>
> * 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
> * persistency layer on network shares, global and per user.
GFS or other distributed fs?
> * Improved toram (awk progressbar or something like that)
wget has a progress bar of its own ;-)
> *
> * Redo login manager support (kdm, gdm, nodm, plain startx on tty1)
You forget the classic: xdm. This one might be incompatible with
auto-login, though :-(
>
> Bugs
> ----
>
> * (Almost) whatever is listed in the BTS :)
>
> General
> -------
>
> * Document stuff properly, both the actual implementation and its
> customization
> * Use sane coding style consistently
> * Optimize sh calls for speed and simplicity
> * Drop unused, overly complicated features
> * Synchronise and unify boot parameters
Yes, defining some sane interfaces for the shell functions should make
them reusable for all the above boot methods plus anything else
somebody comes up with.
Thanks
Michal
Reply to: