Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 353024 - genkernel should use devtmpfs
Summary: genkernel should use devtmpfs
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2011-01-28 09:38 UTC by Xake
Modified: 2011-02-26 08:22 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch against the experimental branch (0001-Use-devtpmfs-when-avaible.patch,1.35 KB, patch)
2011-01-28 09:44 UTC, Xake
Details | Diff
Use the same options as in udev-mount (0001-Update-options-for-devtmpfs.patch,919 bytes, patch)
2011-02-01 18:53 UTC, Xake
Details | Diff
Move devtmpfs from ramdisk to chroot (0002-Move-dev-to-chroot.patch,1.27 KB, patch)
2011-02-01 18:57 UTC, Xake
Details | Diff
0001-Use-tmpfs-if-devtmpfs-is-not-available.patch (0001-Use-tmpfs-if-devtmpfs-is-not-available.patch,1.85 KB, patch)
2011-02-07 18:32 UTC, Xake
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xake 2011-01-28 09:38:49 UTC
the implementation of mdev in busybox seems to be lacking more and more, mostly in regards to carry information in over to udev (like for example in bug #344407, part of bug #330651 for example).

One way to handle this is to use devtmpfs in genkernel if available instead of mdev.
This at least fixes for me the problem with lvm2 created devicenodes during initrd not being re-created by udev later.

We may find another solution for people unwilling to use devtmpfs, however currently even at least some udev devs advices to use devtmpfs with udev.
Comment 1 Xake 2011-01-28 09:44:05 UTC
Created attachment 260899 [details, diff]
patch against the experimental branch

This patch mounts devtmpfs if possible, otherwise starts mdev -s as it did before.

It then checks if devtmpfs is mounted if it is tries to unmount it, as /etc/init.d/udev-mount fails to mount it later on otherwise.

Works fine on my system (using root-on-lvm-on-mdraid) and has removed problems with regards to devicenodes created before udevd is launched.
Comment 2 Sebastian Pipping gentoo-dev 2011-01-31 12:54:20 UTC
So udev brings the nodes back if devtmpfs has learned about them before?

I have applied your patch and removed the subshell from it:

http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=c202dbe67d57af630c2bf7dc5b521d1f6bae8c5f

I wonder if we should enable CONFIG_DEVTMPFS in the shipped kernel configs, if so on which arches and how that can be done without pulling in bits from my local arch by accident.  Would

  make ARCH=ppc64 oldconfig menuconfig

work?
Comment 3 Sebastian Pipping gentoo-dev 2011-01-31 13:15:36 UTC
PS: Maybe we should check if /dev is mounted already before booting?
I could imagine that option CONFIG_DEVTMPFS_MOUNT could get you into that situation.
Comment 4 Xake 2011-01-31 18:55:25 UTC
(In reply to comment #3)
> PS: Maybe we should check if /dev is mounted already before booting?
> I could imagine that option CONFIG_DEVTMPFS_MOUNT could get you into that
> situation.
> 

Not a chance AFAIK, I have that enabled and as far as I can tell that only kicks in if you have the kernel mounting root directly (i.e. not using a initrd/initramfs).
But to be honest I think I heard after doing this patch that the "best practices" way is to move the /dev mount from the ramdisk to new_root before chrooting into it (many applications like bootchart2 tht wants to be able to run in the ramdisk and survive the chroot hijacks /dev because of this). However I do not know how openrc or /etc/init.d/udev-mount handles that move. I think I should try and report back.
Comment 5 Xake 2011-01-31 19:43:35 UTC
So /etc/init.d/udev-mount survives if /dev is already mounted, so maybe we should change the logic to something like "if ! mount --move /dev "${CHROOT}/dev ; then umount -a -t devtmpfs || echo 'moving or unmounting /dev failed'; fi".
Because /etc/init.d/udev-mount will fail if devtmpfs is mounted anywhere else but /dev, we should make a umount per filesystem.
Comment 6 Sebastian Pipping gentoo-dev 2011-02-01 00:46:04 UTC
(In reply to comment #4)
> But to be honest I think I heard after doing this patch that the "best
> practices" way is to move the /dev mount from the ramdisk to new_root before
> chrooting into it (many applications like bootchart2 tht wants to be able to
> run in the ramdisk and survive the chroot hijacks /dev because of this).

What do you mean by hijacking /dev?
Interestingly switch_root of sys-apps/util-linux is documented to rescue/move /dev over, but switch_root of busybox does not do that.


(In reply to comment #5)
> So /etc/init.d/udev-mount survives if /dev is already mounted

If you mean not-quit-with-an-error by that, yes.
But if I interpret function mount_dev_directory correctly, a mounted /dev will prevent the execution of

  mount [..] udev /dev

and maybe leave us with the "plain devtmpfs/tmpfs" of before.
I do not expect to find the current

  # mount | fgrep udev
  udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)

without execution of the before-mentioned mount command.


> Because /etc/init.d/udev-mount will fail if devtmpfs is mounted anywhere else
> but /dev, we should make a umount per filesystem.

I fail to follow.  Please elaborate on this.


Btw in case you are wondering what

  fstabinfo --mount /dev

really does (like I were): From my experiments with "/lib/rc/bin/fstabinfo -m /dev" it seems to mount /dev using information from /etc/fstab or exit with code 1 (one) if it doesn't find an entry.
Comment 7 Xake 2011-02-01 18:53:37 UTC
Created attachment 261279 [details, diff]
Use the same options as in udev-mount

I was bout to write a long answer, but I come to the conclusion that a patch may be a better shot.;)

In this patch I use the same options as in udev-mount, giving a identical mount.
Comment 8 Xake 2011-02-01 18:57:23 UTC
Created attachment 261281 [details, diff]
Move devtmpfs from ramdisk to chroot

This patch is done so that if something goes wrong with the move it tries to remove any mount of devtmpfs. This filesystem seems to only be able to be mounted at one place at a time, so if devtmpfs is mounted anywhere, we fail to move it from /dev we can just try to unmount devtmpfs by filesystem so udev-mount does not break unnecessarily.
Comment 9 Sebastian Pipping gentoo-dev 2011-02-03 18:02:46 UTC
Have you tested <0001-Update-options-for-devtmpfs.patch>?
I wonder if that works with no udev running.
Comment 10 Xake 2011-02-03 22:16:04 UTC
(In reply to comment #9)
> Have you tested <0001-Update-options-for-devtmpfs.patch>?
> I wonder if that works with no udev running.
> 

works fine.

The devtmpfs/udev thing in mounting seems to be just cosmetic, you can seriously name it so your mounting line says:
bart-was-here on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=504997,mode=755)
And it will still work fine.

What I cannot vouch for is how a system totally udev-less (not even udev-on-real_root) works with these patches, but on the other side, someone who makes such a system will not even compile in supprt for devtmpfs unless they plan on using it I believe.
Comment 11 Sebastian Pipping gentoo-dev 2011-02-07 03:36:00 UTC
(In reply to comment #10)
> The devtmpfs/udev thing in mounting seems to be just cosmetic, you can
> seriously name it so your mounting line says:
> bart-was-here on /dev type devtmpfs
> (rw,nosuid,relatime,size=10240k,nr_inodes=504997,mode=755)
> And it will still work fine.

I see.

I have applied the other two patches now.  The "-a" in the call to umount looked like by mistake - I removed that.  Please make me re-add it if necessary.

I am wondering how to best solve the problem for users of non-devtmpfs kernels.
May we could mount tmpfs on ${CHROOT}/dev and copy things from /dev over.
Any ideas if that would work and how to best do it?

Also, please drop me a mail if you want addition to the gernkernel@g.o. mail alias and/or git access.
Comment 12 Xake 2011-02-07 08:02:38 UTC
(In reply to comment #11)
> I have applied the other two patches now.  The "-a" in the call to umount
> looked like by mistake - I removed that.  Please make me re-add it if
> necessary.
> 

There was a reason for that -a:
lillen ~ # umount -t devtmpfs
Usage: umount -h | -V
       umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
       umount [-d] [-f] [-r] [-n] [-v] special | node...
lillen ~ # umount -a -t devtmpfs
umount: /dev: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

This is on a normal system booted and done, but as you can see it does not even try to unmount /dev without the -a, but with the -a and -t together it only tries to unmount /dev.

> I am wondering how to best solve the problem for users of non-devtmpfs kernels.
> May we could mount tmpfs on ${CHROOT}/dev and copy things from /dev over.
> Any ideas if that would work and how to best do it?
> 
I do not actually know how mdev handels a tmpfs, and I start to ask myself what difference it would make to have mdev run if devtmpfs is mounted, maybe we should implement something like the udev-mount initscript does, mounting devtmpfs if available, tmpfs otherwise and run mdev ayway. Then if someone complains about it we may add kernelcmd nodevmount later so it can be turned off.

I think I will try this out... 
Comment 13 Xake 2011-02-07 18:32:48 UTC
Created attachment 261749 [details, diff]
0001-Use-tmpfs-if-devtmpfs-is-not-available.patch

Use tmpfs if devtmpfs is not available
Comment 14 Xake 2011-02-07 18:36:18 UTC
(In reply to comment #13)
> Created an attachment (id=261749) [details]
> 0001-Use-tmpfs-if-devtmpfs-is-not-available.patch
> 
> Use tmpfs if devtmpfs is not available
> 

This patch always mounts something, devtmpfs if available, tmpfs otherwise. Then it moves the mount to the real_root, and if that fails try to unmount /dev. Have tested this patch with both tmpfs and devtmpfs and both retains the nodes created during ramdisk, so for example LVM-devnodes survives the switch_root.
Comment 15 Sebastian Pipping gentoo-dev 2011-02-07 19:18:34 UTC
Good work.

I have added these bits from the busybox mdev primer

http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=c3165cd02f00a2e27656acb93df26e7b4276d8d2

and a bit of error detection

http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=2deeaba70b67b54f7bff26d74df35a6730ca047f

As genkernel is now using devtmpfs I am closing this bug.  Please re-open as needed or open new bugs as you see fits.
Comment 16 Sebastian Pipping gentoo-dev 2011-02-07 19:19:31 UTC
PS: All of your patches are applied by now.  Should have said that explicitly.