If you are using stable profiles, you might want to verify if you are already running a kernel with devtmpfs support enabled. Why? Well, currently you might not need it, but the upcoming openrc/udev packages require it and they currently do not fail at install time if you have it enabled or not. As a result, upgrading these packages might give you a system that might fail to boot (if you have no initramfs but separate /usr partition) or gives many errors (if you have an initramfs).
To verify if it is enabled, check your kernel configuration:
# zgrep DEVTMPFS /proc/config.gz
# CONFIG_DEVTMPFS is not set
If you get the output as described above, best update your kernel configuration to include it. The second devtmpfs-related option (to automatically mount it on /dev) is not needed afaik.
And for those that have been with Gentoo for a while – devtmpfs is not devfs. Well, it is. But it isn’t. Somewhat. Oh well, there’s discussion on that which I’m not going to elaborate on. Safe to say that we’re getting older if we start feeling “Been there, done that, got the t-shirt” ;-)
Edit: as Robin mentioned in the comments, the udev ebuild does check at it. However, it doesn’t fail an installation so you could miss the message. Apologies for the lies, Robin ;-) Post updated.
I’ve been here long enough to remember devfs indeed, and what was there before that. Now, where do I get the tshirt, seriously? :P
I enabled it on my stable gentoo some days ago. So I think the openrc build using it is already in stable, and it displays an error if the kernel does not have the right option.
(But you can easily miss the error because I think it’s not fatal, so it’s hidden in the output)
% zgrep DEVTMPFS /proc/config.gz
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
Does the second one matter?
Do I need to enable the CONFIG_DEVTMPFS_MOUNT option as well?
“Why? Well, currently you might not need it, but the upcoming openrc/udev packages require it and they currently do not check at install time if you have it enabled or not.”
That’s complete BS. It has been checked for more than 2 months at this point.
Current version:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-182-r2.ebuild?revision=1.3&view=markup#l83
Where it was introduced:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-180.ebuild?hideattic=0&revision=1.1&view=markup#l68
https://bugs.gentoo.org/show_bug.cgi?id=103878#c29
Yea, if you don’t have this option enabled into kernel, udev installs fine but fails o start during boot process…. Very annoying :/
This should have been a build failure, I wasted quite some time yesterday to fix my broken system.
Or you should make it easer for users to see these messages. Mine get lost in lots of useless output saying running autotools or applying patches…
obf, unless there’s some option to explicitly disable it (which certainly isn’t used by default), Portage does print all the important stuff after everything has been done, if you missed that or somehow disabled it, that’s your problem. Also I believe –quiet-build=y makes it not print build log of course, you are then expected to read logs on failure yourself, something which might be too hard for obf.
Well, I have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y in my live kernel, as indicated by zgrep’ing /proc/config.gz, but udev ebuild still claims it’s not enabled in the kernel, and udev fails. WTH? Something more need to be done? Is eudev ready for prime time yet because I’m REALLY sick of udev always breaking my system randomly for no good reason
If the ebuild fails, then check if your /usr/src/linux is pointing to the sources that contain the configuration (so /proc/config.gz and /usr/src/linux/.config should match). If udev itself fails however, you might need to give some more details (error and such).