The return of devfs [LWN.net]

The return of devfs

Posted May 7, 2009 2:29 UTC (Thu) by foom (subscriber, #14868)
In reply to: The return of devfs by arjan
Parent article: The return of devfs

So, how come nobody has simply done a port of Debian's initramfs-tools to Fedora and SuSE so we
can be done with this whole mess of bad initramfs implementations? I've not played with any of
them extensively, but from what I've read it sounds like everyone else's initramfs implementations
are pretty terrible, and Debian's is flexible enough to be used by any distro already.

If that's all true, it ought not be much work to port it and demonstrate its superiority and people
can stop wasting time on this stuff, no?

to post comments

The return of devfs

Posted May 7, 2009 5:42 UTC (Thu) by niner (guest, #26151) [Link] (4 responses)

Now I'm curious: what does Debian do right, while others do it wrong?

The return of devfs

Posted May 8, 2009 0:57 UTC (Fri) by drag (guest, #31333) [Link] (3 responses)

The only thing that Debian does right that I haven't seen in other distros is that Debian's
initramfs is easier for end users to hack with.

A) It's documented

B) Tools to do things like rebuild the initramfs are easily accessable, documented.

C) The initrd scripts are init-like. They are modular, commented, and occupy a directory
structure in /usr/share/initramfs/ that makes sense according to their purpose and what part
of the boot process they are executed.

D) They have examples on scripts you can make on your own.

E) If you install packages that may impact boot-up proceedures, like maybe some hardware,
like LVM, then hooks are added to that directory structure. If you do not have packages for
LVM then support is not in the initramfs irregardless.

F) It's very easy to add busybox support so that you can do things like shove a 'sh' into the
boot procedure and get a shell to troubleshoot your scripts.

G) It's documented

H) The scripts have examples and decent comments.

It's certainly not perfect and there are better ways to do stuff. But most of the time dealing
with initrd scripts they are just monolithic and very unfriendly.

With a evenings worth of effort I've done things like devise a means to reliably network boot
the system using iSCSI software initiator. I've created layered root file systems using
compressed read-only file systems and things like AUFS, which I used on my EEEPC for a
number of montsh.

I did all this using my own hooks and add-on scripts that didn't affect the the existing Debian
scripts and didn't break when the system was updated.

Sure it ends up creating a little 'mini-linux-distro' that gets loaded into RAM and that ends up
making stuff slow as shit, during the initial boot process, but is actually something that a
experienced administrator can usefully use.

Every other distribution I've used always had the most horrid hacks and special-purpose
scripts that supported whatever configurations the installer supported, but were a pain to deal
with and customize.

Oh, and they were all poorly documented.

The return of devfs

Posted May 8, 2009 0:58 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Oh. And Midori mangles newlines in when you try to post comments. Hateful. Hateful. Hateful.

The return of devfs

Posted May 8, 2009 15:15 UTC (Fri) by MarkWilliamson (guest, #30166) [Link]

I'm posting from a KHTML embedded in Akregator and it newline mangles my posts
as well... Yet posting from KHTML in a full Konqueror instance does not. I think
Akregator has some Javascript restrictions but otherwise it's using the same engine.
Curious.

Got any interesting Javascript settings in Midori?

The return of devfs

Posted May 8, 2009 7:11 UTC (Fri) by niner (guest, #26151) [Link]

FWIW that sounds pretty much like mkinitrd on openSUSE. A directory structure
in /lib/mkinitrd/ containing startup scripts that may be put there by installed packages
(e.g. /lib/mkinitrd/scripts/boot-lvm2.sh is owned by the lvm2 package). Adding busybox
is just adding "busybox" to the feature list parameter of the mkinitrd call. The scripts
(including mkinitrd) are commented (which already saved me once) and the mkinitrd
manpage even contains instructions how to mount the root partition from a rescue
system with necessary bind mounts to be able to execute mkinitrd.

Seems like such a structure is the result of natural evolution :)