I guess the only case where this is relevant is when installing to a prefix where ${prefix}/dev is a tmpfs, and not bindmounted to /dev. If you then want to chroot into ${prefix} before rebooting it might not work (i.e. one could imagine that what is done in the initrd needs to be done on install time). However, I think this is pretty far-fetched, so I'm in favor of making the change in principle. Does anyone else have any thoughts on this?

Just some thoughts what might be a problem:
- booting without initramfs
- using dracut instead of mkinitcpio (or any other software)

But all these problems should be solved when /dev gets mounted by rc.sysinit before doing anything else (even before sourcing rc.conf and functions). If devtmpfs isn't available /dev/{console,null,zero} must also be created by rc.sysinit.

Now I'm not sure if that idea was really so good. Does anyone know how this is solved in other distributions?

I don't think putting nodes on the underlying /dev will help during boot at all, as a tmpfs (or better, a devtmpfs) is mounted over it pretty early. So I think you are right that this can just be removed, I don't see the point of it at all. Anyone who were around when this was needed who would like ta add anything?

The udev commit that introduces the post-install hook says:
"- Added a post_install so that /dev/{console,null,zero} are created again, so we don't break FTP installations when we move to core"

This was done three years ago by Thomas. I don't know exactly why it was needed, but my guess is that it is not any longer.

@brain0: Is it still relevant?

You need at least /dev/console for non-devtmpfs boot (i.e., if devtmpfs is not automounted by the kernel or initramfs, or devtmpfs is not supported). It is irrelevant for our default setup.

Try to boot a kernel that does not automount devtmpfs and without initramfs. This kernel will panic because it cannot open the console for init. In initramfs, /dev/console is created if it is not present.

Good point, I won't touch this. I hope people are auto-mounting devtmpfs though, as I don't know if anyone is testing any other case (I'm a bit worried about the gap between mounting /dev and the basic devices being copied over by udev).

I was going to say, kill it:
1) Installations from the installer will work (devtmpfs is always mounted in our default setup).
2) Old installations won't break.
3) If anyone must really have a kernel with no initramfs and no devtmpfs-automounting (unlikely, and likely to break for other reasons), creating the nodes in the real /dev is easy.

I had just committed a comment saying "this is a bad idea, but we'll try to make it work for now". I agree with killing it though (I hate having workarounds for extreme edge-cases that I will never test). It is probably better that people who want this have to jump through some hoops so they don't get the impression that it is supported.