The return of devfs [LWN.net]

The return of devfs

Posted May 7, 2009 1:36 UTC (Thu) by arjan (subscriber, #36785)
Parent article: The return of devfs

This devtmpfs is not need to boot fast. Really.

This is a workaround for a certain distros crappy mkinitrd basically, and nothing more; if you do the initrd correct (or if you don't use an initrd at all), you don't need this "solution" and you'll even boot faster....

to post comments

The return of devfs

Posted May 7, 2009 2:29 UTC (Thu) by foom (subscriber, #14868) [Link] (5 responses)

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?

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 :)

The return of devfs

Posted May 7, 2009 9:53 UTC (Thu) by vrfy (guest, #13362) [Link]

That's not quite right, distros don't do (needless) crack here. Some use braindead tools, which should not even exist in the first place, but that's a totally different story, which is not touched at all by devtmpfs.

Having static device nodes would be a very dangerous hack for a general purpose distro in the light of dynamic device numbers. You access a /dev name but you can't be sure, you talk to the right device. That's a problem you need to avoid for correctness, not for speed reasons. And we have many subsystems which have dynamic minors only. Even sd* disk nodes can be already, and likely will be dynamic for some systems pretty soon.

/dev needs to be on tmpfs these days for security reasons, because tools mess around here, and adding user access control lists to device nodes, and create tons of symlinks, which are only meaningful during the lifetime of a specific device.

Besides simplicity and reliability devtmpfs covers the transition time from the empty mounted tmpfs to the populated /dev. During this time, you can't do much else, but devtpmfs does not have that requirement at all, because /dev always reflects all currently known devices.

The return of devfs

Posted May 7, 2009 10:39 UTC (Thu) by mjthayer (guest, #39183) [Link]

mkinitrd seems to be a rather nasty, complex thing though (even if Debian have apparently got it right). Perhaps 600 lines of kernel code is a price worth paying for simplifying things a bit. After all, the idea of an initramfs was (IIRC) to move things out of the kernel that could be done better in userspace. If this can be done more easily in the kernel, why not do it there?