Linux 3.2.44 with devtmpfs

Eudev developer 'blueness' advised me that I needed to enable these two in the kernel, for module-loading with eudev to work:

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

Up until now, we have been using udev version 167 in our puppies. One of the things it does is create device nodes, if they don't already exist.
However, from a later version, it may be 18x, udev no longer does this. Instead, the kernel has to do it, which requires those above-two config options.

With those options, the kernel creates a tmpfs on /dev, then populates it, and will do so dynamically as new hardware is detected.

I have compiled the 3.2.44 kernel with those options enabled, for the purpose of experimenting with the latest eudev.

Here it is (23.3M):
http://distro.ibiblio.org/quirky/pet_packages-precise/linux_kernel-3.2.44-nopae-i586-devtmpfs-precise.pet

---

Comments

devtmpfs not mounted in initramfs
Username: jamesbond
I was wondering what this is special config that is required for eudev to work :) Please be aware that CONFIG_DEVTMPFS_MOUNT only automatically mounts devtmpfs on /dev if you don't use initramfs - in other words, it only works when you use full-install. If you use initramfs, it has no effect and you still have to mount it manually on initrd using [code]mount -t devtmpfs devtmpfs /dev[/code] and later 'move' this mount to the /initrd/pup_new just before you switch root: [code]busybox mount -o move /dev /initrd/pup_new/dev[/code] *Do not* attempt to mount a new devtmpfs after you switch root - it doesn't always work correctly (at least in my case).

/bin/mountpoint
Username: K Godt
"Can we expect/bin/mountpoint in initrd.gz then ?

udev version 176
Username: BarryK
"jamesbond, Yes, I did some reading up on devtmpfs, discovered that need to mount it in initramfs. I also read here: https://patchwork.kernel.org/patch/1780891/ that it was udev version 176 that no longer create device nodes, and requires the kernel to do it. That's why you will see some distros such as T2 and Debian using version 175.

mounting devtmpfs
Username: BarryK
"Just before I read this blog thread, I had just setup things for an experiment. I left the static /dev in the initramfs, and just run: mount -t devtmpfs devtmpfs /pup_new/dev just before the switch_root.

Woof and devtmpfs
Username: BarryK
"After a successful test, I have modified Woof to be "devtmpfs aware". The two scripts modified are 'init' in the initrd and '3builddistro'. They detect if the kernel has devtmpfs enabled, and modify their behaviour accordingly. Woof commit: http://bkhome.org/fossil/woof2.cgi/info/a2710687b6 This does assume that if you are building with a devtmpfs-enabled kernel, that you are also using udev >= 186 or eudev. I don't know whether there would be a clash using an older udev. Eudev works, so I will make it up into a PET.

clarification
Username: jamesbond
"Yes, static /dev in initramfs and devtmpfs before switch_root works too. My original post wasn't too informative. Of course one can mount devtmpfs in rc.sysinit. What I was trying to say is that devtmpfs should not be mounted in two places (unless one uses bind mount), because the second instance doesn't work correctly: if it is already mounted in initramfs, it should be moved before switch_root instead of mounting a second devtmpfs instance in rc.sysinit. As for udev, Fatdog has been using devtmpfs with udev 175 without problems for over a year by now.

Re udev 176
Username: BarryK
"It should be noted too, that udev version 176 also requires kmod, instead of module-init-tools. I discovered that by reading the changelog.

Tags: puppy