Created attachment 301373 [details, diff] patch to allow proper remounting the DEVTMPFS if already mounted i OK, first of all sys-fs/udev-init-scripts is a gentoo hosted project, but there's no entry for it in the dropdown, so I had to pick the best match I could, openrc. But that seems pretty reasonable given that it appears to be the pretty much the same folks involved with both. Second, while I list -8, I also unpacked and checked -9999, doing a git whatchanged, but it seems that there have been no commits in git since -8's release, so as of a few minutes ago anyway, this should be current against either one. To the issue... As I'm running pretty much everything portage installs to on my rootfs, I'm not affected by the separate /usr issue that's the given reason for masking current udev, and I've unmasked it. I've run udev-175, 180 and just now merged 181. Of course udev-180+ pulls in udev-init-scripts as well, so I have it unmasked now as well, thus this bug. Of course current udev now requires CONFIG_DEVTMPFS and that's checked for in the udev ebuild and in udev-init-scripts' udev-mount script, but there's no mention of CONFIG_DEVTMPFS_MOUNT, which is where my problems began. The udev-mount script in its current form doesn't properly check for a kernel-premounted (due to CONFIG_DEVTMPFS_MOUNT=y) DEVTMPFS. The attached patch changes four lines to: (1) Correct a typo/thinko: fstabinfo -f should be -t (no -f, that's mountinfo). (2) Check for an already mounted devtmpfs and remount it with the proper options from fstab if appropriate. Without that, it keeps the default kernel-mount options as it's never remounted.
Duncan, what exactly was the issue you experienced with this version of udev? The idea here is that if /dev is mounted by the kernel we probably want to skip remounting it. William
(In reply to comment #1) > what exactly was the issue you experienced with this version of udev? > The idea here is that if /dev is mounted by the kernel we probably want > to skip remounting it. Two issues: 1) With CONFIG_DEVTMPFS_MOUNT=n, fstabinfo -q -f (the third line changed in the patch) resulted in an error, because -f is an unrecognized option for fstabinfo. I believe it should be -t (type) instead of -f, -t being the fstabinfo type option, parallel to -f for mountinfo (it was a simple mixup, using the type option for mountinfo instead of the one for fstabinfo). Because of that error, fstabinfo exits with an error code, which is false, which due to the ! logic, prints the eerror saying the fstab entry isn't correct, that it should be devtmpfs, even when it *IS* devtmpfs. Of course it then returns 1, skipping the devtmpfs mount, and since it wasn't mounted already (CONFIG_DEVTMPFS_MOUNT=n), the devtmpfs never gets mounted so udev fails to start, and pretty much the entire rest of the init sequence then fails due to lack of udev. That's a simple bug with a simple fix, a one letter change on that line, -f -> -t. With that fix, the test is correct and the warning and return 1 only happen if the entry exists and is NOT devtmpfs, which is clearly the intent. 2) With CONFIG_DEVTMPFS_MOUNT=y, the whole function returns early, leaving the kernel default mount options. Since nothing else in the initscripts remounts it with the fstab options, they're ignored. That's wrong. Something somewhere needs to remount the devtmpfs with the options configured for it in fstab, which may well be stricter than the kernel's default options, and this is the most logical place to do it. Here, for instance, I have the fstab options for devtmpfs set to mode=0755,size=2m,noexec,nosuid,noauto,nr_inodes=8k. That's rather stricter than the default kernel options, for sure, and I want those options applied, so a remount with them needs to happen at some point during the boot process, and given this is where the mount would normally happen if the kernel option isn't set, and it's the udev-mount script, it's the logical place to handle the remount as well, particularly as doing so only takes three changed lines, beyond the one to fix the above bug. Does that answer your question?
Created attachment 301969 [details] udev-mount-fstab.patch Duncan, check out this patch. It is more than a couple of lines change, but I think it clarifies what is happening in the script a lot more. Let me know what you think.
(In reply to comment #3) > check out [patch attachment 301969 [details]]. It is more than a couple > of lines change, but I think it clarifies what is happening > in the script a lot more. It does and I like it, but... 1) There's still an fstabinfo -f line in there. That's broken as fstabinfo doesn't HAVE a -f option! It's mountinfo that uses -f. For fstabinfo, it's -t. So change all usage of fstabinfo -f to fstabinfo -t. (It'd help if there were manpages for these things. I ended up having to equery belongs fstabinfo to find the path, then actually run /lib64/rc/bin/fstabinfo --help to get what it does, and compare that against <path>/mountinfo --help.) 2) General openrc changes have overtaken the need for udev-init-scripts/udev-mount to handle the remount itself. openrc git commit 0fcc6251 added fstabinfo --remount, and 497ff7ee used the new fstabinfo --remount feature to support remounting already mounted filesystems in the root script. I tested that and it works with a pre-mounted devtmpfs as well, remounting it as it should, so udev-mount doesn't need to (thus coming into line with your comment #1), but the fstabinfo -f still needs to change to fstabinfo -t in the remaining logic, whether it stays more or less as is, or changes similar to this patch, but probably without the remount bit, now, since that's handled by the root script.
(In reply to comment #4) > So change all usage of fstabinfo -f to fstabinfo -t. This has been fixed in the patch I am about to commit. > (It'd help if there were manpages for these things. I ended up having to > equery belongs fstabinfo to find the path, then actually run > /lib64/rc/bin/fstabinfo --help to get what it does, and compare that against > <path>/mountinfo --help.) There won't be separate man pages for these because they are meant to be internal helpers for openrc scripts and not for general use. This is also why these are not in a directory in $PATH. I agree that documenting them on the runscript man page may be a good idea, and I'll look into that later. > 2) General openrc changes have overtaken the need for > udev-init-scripts/udev-mount to handle the remount itself. openrc git commit > 0fcc6251 added fstabinfo --remount, and 497ff7ee used the new fstabinfo > --remount feature to support remounting already mounted filesystems in the root > script. I tested that and it works with a pre-mounted devtmpfs as well, > remounting it as it should, so udev-mount doesn't need to (thus coming into > line with your comment #1), but the fstabinfo -f still needs to change to > fstabinfo -t in the remaining logic, whether it stays more or less as is, or > changes similar to this patch, but probably without the remount bit, now, since > that's handled by the root script. If I made udev-mount rely on the root script to remount /dev, I would have to move udev itself to run much later in the boot sequence than it does since /dev must be writable before udev starts. I'm currently not interested in going there because I don't know what complications it would cause.
This is fixed in commit 0ed42d3. Thsnks for the report.
