* Daniel Baumann <dan...@debian.org> 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[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 > * 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: http://grml.supersized.org/archives/337-More-robust-network-booting.html > * 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 well. > 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 removable/removable-usb) > * 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) * 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 initramfs-tools? > 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 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.) > 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 * 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'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. Please let me know if I can help anywhere. Thanks for taking care, Daniel. -mika- -- http://michael-prokop.at/ || http://adminzen.org/ http://grml-solutions.com/ || http://grml.org/ -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
