This seems to be quite similar to https://bugs.gentoo.org/show_bug.cgi?id=454456 which looks to have had the same thing happen. The symlinks for udev and udev-mount are missing from /etc/runlevels/sysinit on the hardened stage3 tarballs, but still appear in the standard stage3: $ grep etc/runlevels/sysinit stage3-amd64-20140227.tar.bz2.CONTENTS drwxr-xr-x root/root 0 2014-02-27 04:52 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2014-02-27 04:50 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2014-02-27 04:52 ./etc/runlevels/sysinit/udev -> /etc/init.d/udev lrwxrwxrwx root/root 0 2014-02-27 04:50 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2014-02-27 04:50 ./etc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev lrwxrwxrwx root/root 0 2014-02-27 04:50 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg lrwxrwxrwx root/root 0 2014-02-27 04:52 ./etc/runlevels/sysinit/udev-mount -> /etc/init.d/udev-mount $ grep etc/runlevels/sysinit stage3-amd64-hardened-20140227.tar.bz2.CONTENTS drwxr-xr-x root/root 0 2014-02-27 14:38 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2014-02-27 14:38 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2014-02-27 14:38 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2014-02-27 14:38 ./etc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev lrwxrwxrwx root/root 0 2014-02-27 14:38 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg I went through some older tarballs that I could find and it seems to have been removed sometime between 20130620 and 20140130. Verified on x86 and amd64, didn't test any other archs. Reproducible: Always Steps to Reproduce: 1. Boot from install-amd64-minimal-20140227.iso 2. Follow the handbook/quick install guide using stage3-amd64-hardened-20140227.tar.bz2 3. Reboot your system Actual Results: Verify that /dev/fd, /dev/stdin, /dev/stdout, and /dev/stderr do not exist. Expected Results: Above files/links should be present on a booted system.
Ladies and Gentlemen: I want to confirm that udev is missing and/or completely broken in sysinit following installation of the 27 Feb 2014 hardened stage3, originally reported by Jack Suter, is, in fact, correct. I have installed Gentoo Hardened a number of times, and I happen to use an encrypted root and swap on /dev/sda3. However, if you can even get Gentoo to boot after installing the 27 Feb 2014 stage3, udev is broken, apparently beyond repair. Furthermore, it is important to note that installing the current stage3 installs udev-208. However, if you read the 25 Feb 2014 eselect news item #7, regarding the upgrade to udev-210 and then follow all the instructions, all subsequent attempts to emerge ANY package resulted in failure on my rig. These emerge failures always pointed to a broken/missing symlink. Sorry I cannot get you the exact failure language, because at the moment I cannot even get my Gentoo Hardened rig to boot! My plan, as it seems I have no other choice, is to 'mklabel gpt' and install again, but this time using the 31 Oct 2013 stage3, because IIRC, that stage3 does install Gentoo Hardened correctly. If it does not, I will follow-up here. In any event, this appears to be a quite serious installation issue. I hope the Gentoo Release Engineering Team finds the root cause, and immediately releases an updated, known-to-work hardened stage3. In closing, I love Gentoo, and do very much appreciate ALL the hard work our devs do! Best regards, EncryptedPhreak
Just to clarify, a workaround for this bug seems to be to simply recreate the sysinit runlevel for udev (and optionally udev-mount) which can be done as so: rc-config add udev sysinit rc-config add udev-mount sysinit Doing this from inside of a chroot environment, or otherwise linking /etc/runlevels/sysinit/udev to /etc/init.d/udev, seems to allow udev to start up properly on boot. From an already running system, `/etc/init.d/udev start` should create the necessary devices in /dev to fix the broken-ness. There doesn't seem to be anything preventing udev from starting, just nothing that is actually causing udev to start in the first place.
$ for i in $(find /home/release/buildroot/amd64-dev/builds/hardened/ -maxdepth 1 -iname "stage3-amd64-hardened-2013*.bz2"); do echo "stage: ${i}"; tar tjvf ${i} | grep /etc/runlevels/sysinit; done stage: /home/release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened-20131118.tar.bz2 drwxr-xr-x root/root 0 2013-11-19 04:19 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2013-11-19 04:16 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2013-11-19 04:16 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2013-11-19 04:19 ./etc/runlevels/sysinit/udev-mount -> /etc/init.d/udev-mount lrwxrwxrwx root/root 0 2013-11-19 04:19 ./etc/runlevels/sysinit/udev -> /etc/init.d/udev lrwxrwxrwx root/root 0 2013-11-19 04:16 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg stage: /home/release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened-20131204.tar.bz2 drwxr-xr-x root/root 0 2013-12-05 10:41 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2013-12-05 10:41 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2013-12-05 10:41 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2013-12-05 10:41 ./etc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev lrwxrwxrwx root/root 0 2013-12-05 10:41 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg From the above run on my build box, whatever happened, happened between 2013/11/19 and 2013/15/05.
(In reply to Jorge Manuel B. S. Vicetto from comment #3) > stage: > /home/release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened- > 20131204.tar.bz2 <snip> > From the above run on my build box, whatever happened, happened between > 2013/11/19 and 2013/15/05. Sorry, I meant between 2013/11/18 and 2013/12/04.
$ for i in $(find /release/buildroot/amd64-dev/builds/hardened/ -maxdepth 1 -iname "stage3-amd64-hardened-2013*.bz2" | sort -n); do echo "stage: ${i}"; tar tjvf ${i} | grep /etc/runlevels/sysinit; done stage: /release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened-20130103.tar.bz2 stage: /release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened-20131024.tar.bz2 drwxr-xr-x root/root 0 2013-10-24 16:19 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2013-10-24 16:15 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2013-10-24 16:19 ./etc/runlevels/sysinit/udev -> /etc/init.d/udev lrwxrwxrwx root/root 0 2013-10-24 16:15 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2013-10-24 16:15 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg lrwxrwxrwx root/root 0 2013-10-24 16:19 ./etc/runlevels/sysinit/udev-mount -> /etc/init.d/udev-mount stage: /release/buildroot/amd64-dev/builds/hardened/stage3-amd64-hardened-20131205.tar.bz2 drwxr-xr-x root/root 0 2013-12-05 16:29 ./etc/runlevels/sysinit/ lrwxrwxrwx root/root 0 2013-12-05 16:29 ./etc/runlevels/sysinit/sysfs -> /etc/init.d/sysfs lrwxrwxrwx root/root 0 2013-12-05 16:29 ./etc/runlevels/sysinit/devfs -> /etc/init.d/devfs lrwxrwxrwx root/root 0 2013-12-05 16:29 ./etc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev lrwxrwxrwx root/root 0 2013-12-05 16:29 ./etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg So on skimmer the change happened between 20131024 and 20131205.
The problem for me when i build the stage3 is that udev-init-scripts just get install when udev still geting installed so the checks fail silently. and the symlinks never get added. If some package get installed petvine udev and udev-init-scripts it works fine.
02 Apr 2014; Samuli Suominen <ssuominen@gentoo.org> udev-init-scripts-26-r1.ebuild, udev-init-scripts-26.ebuild, udev-init-scripts-9999.ebuild: Make virtual/udev also a DEPEND to fix race with emerge order wrt #503174 by Jack Suter. Thanks to Jorge Manuel B. S. Vicetto and Magnus Granberg for tracking this down. The fix is in Portage, leaving open for releng to close ->
It wasn't enough; 03 Apr 2014; Samuli Suominen <ssuominen@gentoo.org> udev-init-scripts-26-r1.ebuild, udev-init-scripts-26.ebuild, udev-init-scripts-9999.ebuild: Continue with bug 503174 and make sys-apps/openrc a dependency too.
bug 487080 may have make this stage3 build failing, see comment 19 remove of openrc dep that needed for the runlevels/sysinit dir so the udev-init-scripts can run the checks if [[ -x "${ROOT}"etc/init.d/udev \ && -d "${ROOT}"etc/runlevels/sysinit ]] if no sysinit dir the cehck will fail and it don't make the needed syslinks.
*udev-init-scripts-26-r2 (03 Apr 2014) 03 Apr 2014; Samuli Suominen <ssuominen@gentoo.org> +udev-init-scripts-26-r2.ebuild, udev-init-scripts-9999.ebuild: If /etc/runlevels/sysinit is missing when we are installing for the first time, create the directory. This way we don't have to pull in sys-apps/openrc as a dependency, and sys-apps/systemd can continue to depend on this package unconditionally wrt #487080 Left sys-apps/openrc dependency to 26 (deprecated current stable version) and 26-r1 (deprecated ~arch version). For 26-r2 to stabilize, we need >=net-misc/netifrc-0.2.1 stable first, I've just poked robbat2 if we can proceed with stabilization of =net-misc/netifrc-0.2.2.
(In reply to Samuli Suominen from comment #10) > For 26-r2 to stabilize, we need >=net-misc/netifrc-0.2.1 stable first, I've > just poked robbat2 if we can proceed with stabilization of > =net-misc/netifrc-0.2.2. See bug 507070.
Created attachment 374574 [details] EncryptedPhreak's Follow-Up udev-208 Comments and Recommendations
Created attachment 374576 [details] EncryptedPhreak's Public Key Gentlemen: As promised within my 9 April 2014 udev-208 Comments and Recommendations, I am attaching my Public Key. Kindest regards, EncryptedPhreak
(In reply to EncryptedPhreak from comment #12) > Created attachment 374574 [details] > EncryptedPhreak's Follow-Up udev-208 Comments and Recommendations how is any of that related to udev-208? this bug is related to udev-init-scripts-26, shared among udev, eudev, and systemd (for openrc boot), and has been there is multiple versions so it wasn't a regressions that happened even at the same time with 208 couldn't find anything useful from the rant, not sure what you are trying to say, if the intention was to waste time, then you succeeded
Dear Samuli, My standard operating procedure includes two important tools: 1. I am hard on the problems, and soft on the people. 2. Despite #1, above, when people choose to attack me, publicly, I typically write them off as common teenage AssClowns...and move on. However, in YOUR case, I cannot proceed, per normal, for the following reasons: 1. Among the first things I told you in my most recent message is that I am NOT a coder, nor did I understand the technical underpinnings of the udev 'issues'. Yet, despite THIS knowledge YOU went out of YOUR way to attack ME for my lack of understanding. 2. The rationale for my 'rant,' as you characterized it, is simple: YOU, and perhaps others, caused the udev problem, which resulted in me ending up with a COMPLETELY BROKEN and UNUSABLE Gentoo Hardenened OS for more than two weeks. 3. What stoked my anger is that YOU, Samuli, and perhaps others, responsible for udev-related code, UTTERLY FAILED TO COMMUNICATE either the EXISTENCE of the PROBLEM, OR HOW TO FIX IT, despite notification MORE THAN ONE MONTH EARLIER!! 4. As a DIRECT RESULT OF YOUR FAILURE TO COMMUNICATE, Samuli, I was left on my own to identify my own solution to a problem I DID NOT CAUSE, NOR CONTRIBUTE TO. 5. If English is NOT your first language, Samuli, perhaps that may be a somewhat probable, perhaps, even understandable, defense against your unfounded, and baseless allegations toward me. That being said, try to keep in the forefront of your mind: there is NEVER an excuse for behaving like an ASSHOLE! 6. However, in any event, to maximize your own chances of life success, I HIGHLY RECOMMEND YOU, Samuli, adopt my initial #1 strategy above! In closing, if your objective, through YOUR COMMENTS, was to INFURIATE a reasonably skilled Gentoo Hardened user, YOU, Samuli, SUCCEEDED...WILDLY!!! EncryptedPhreak
Despite my OUTRAGE, as I expressed in #15 toward Samuli's comments in #14 above, for those following the udev-related bug, I am happy to report the following: 1. My most recent Gentoo Hardened installation (with an encrypted root and swap on /dev/sda2) occured using a hardened stage3 fileset dated 10 April 2014. 2. udev worked, as expected: 'Out of the Box' following initial boot. 3. Below is a report of my current udev system status: emerge -s udev Searching... [ Results for search key : udev ] [ Applications found : 12 ] * app-text/uudeview Latest version available: 0.5.20-r1 Latest version installed: [ Not Installed ] Size of files: 255 kB Homepage: http://www.fpx.de/fp/Software/UUDeview/ Description: uu, xx, base64, binhex decoder License: GPL-2 * app-vim/udev-syntax Latest version available: 20051016-r1 Latest version installed: [ Not Installed ] Size of files: 1 kB Homepage: http://www.vim.org/scripts/script.php?script_id=1381 Description: vim plugin: syntax highlighting for udev rules files License: vim * dev-dotnet/gudev-sharp Latest version available: 0.1 Latest version installed: [ Not Installed ] Size of files: 100 kB Homepage: http://launchpad.net/gudev-sharp Description: GUDEV API C# binding License: LGPL-2.1 * dev-python/python-gudev Latest version available: 147.2 Latest version installed: [ Not Installed ] Size of files: 9 kB Homepage: http://github.com/nzjrs/python-gudev Description: Python binding to the GUDev udev helper library License: LGPL-3 * dev-python/pyudev Latest version available: 0.16.1 Latest version installed: [ Not Installed ] Size of files: 73 kB Homepage: http://packages.python.org/pyudev/ http://pypi.python.org/pypi/pyudev Description: Python binding to libudev License: LGPL-2.1 * sys-apps/udevil Latest version available: 0.4.3 Latest version installed: [ Not Installed ] Size of files: 463 kB Homepage: http://ignorantguru.github.com/udevil/ Description: mount and unmount removable devices without a password License: GPL-3 * sys-fs/eudev Latest version available: 1.3 Latest version installed: [ Not Installed ] Size of files: 1,640 kB Homepage: https://github.com/gentoo/eudev Description: Linux dynamic and persistent device naming support (aka userspace devfs) License: LGPL-2.1 MIT GPL-2 * sys-fs/udev Latest version available: 208 Latest version installed: 208 Size of files: 2,327 kB Homepage: http://www.freedesktop.org/wiki/Software/systemd Description: Linux dynamic and persistent device naming support (aka userspace devfs) License: LGPL-2.1 MIT GPL-2 * sys-fs/udev-init-scripts Latest version available: 26 Latest version installed: 26 Size of files: 4 kB Homepage: http://www.gentoo.org Description: udev startup scripts for openrc License: GPL-2 * virtual/libgudev [ Masked ] Latest version available: 208 Latest version installed: [ Not Installed ] Size of files: 0 kB Homepage: Description: Virtual for libgudev providers License: * virtual/libudev [ Masked ] Latest version available: 208 Latest version installed: [ Not Installed ] Size of files: 0 kB Homepage: Description: Virtual for libudev providers License: * virtual/udev Latest version available: 208-r1 Latest version installed: 208-r1 Size of files: 0 kB Homepage: Description: Virtual to select between sys-fs/udev and sys-fs/eudev License: In any event, thank you to all who worked to correct the very serious udev new installion issue(s)! PLEASE: Next time, choose to COMMUNICATE!!! It is IMPOSSIBLE TO BE EMBARRASSED (EITHER NOW, OR LATER) WHEN YOU TELL THE TRUTH!!! Best regards, EncryptedPhreak
(In reply to EncryptedPhreak from comment #16) > Despite my OUTRAGE, as I expressed in #15 toward Samuli's comments in #14 > above, for those following the udev-related bug, I am happy to report the > following: Still no idea what you are talking about, read the rant twice now, still useless. CC comrel@ for futher issues -> > 1. My most recent Gentoo Hardened installation (with an encrypted root and > swap on /dev/sda2) occured using a hardened stage3 fileset dated 10 April > 2014. Thanks. This is what was required for closing the bug (a final test result) ->
Samuli, Your code, and user input, quality standards, are apparently, far lower than mine. Closing 'a bug' requires, from my POV: a. coders UNDERSTANDING what caused the behavior b. communicating to users why the problem(s) occurred, and c. how to address known issues(s), and then, wait for more user feedback... I have installed Gentoo Hardened more than 20 times. Do YOU believe I think it is a 'good idea' to change the procedure each time? udev WAS broken...I've given you the hardened stage3 fileset date. If you don't believe me, why don't you install it for yourself on a non-critical system? Oh...and just for the record, instead of dismissing critism of YOUR insufficient, non-transparent, completely unhelpful bug-closure 'process,' it IS FAR MORE HELPFUL to the rest of us 'stupid-people' if YOU (super, superlative-one), could actually bring yourself to just bow down long enough to explain, in detail, how udev became broken, and what was done to fix it. That is, of course, ASSUMING YOU ARE NOT GOING TO INSIST ON CLAIMING that udev was NEVER broken...which would NOT, even begin, to surprise ME...in the least. EncryptedPhreak
(In reply to EncryptedPhreak from comment #18) <snip> > udev WAS broken...I've given you the hardened stage3 fileset date. If you > don't believe me, why don't you install it for yourself on a non-critical > system? Just to clear any misunderstanding regarding this issue, udev itself wasn't broken. The issue that showed up for anyone using the affected stages, was caused by not having the udev init scripts in the sysinit run-level, which would cause systems to fail to boot for not running udev as users were expecting it. Although technically there was an issue with the dependencies of the udev-init-scripts package, this was only an issue for new stages as during the stage building some packages were missing that caused portage not to add the init scripts to the correct runlevel. We (releng, udev maintainers and docs team) had a discussion sometime ago about whether we should add those symlinks or document in the handbook that users should do it - we opted to do it ourselves to facilitate users life. As others commented in this bug report, to "fix" the issue in the stages, one only needed to add udev / udev-mount to the sysinit runlevel. In the meantime, we were able to fix the underlying issue in large part due to Magnus "detective work" and Samuli's quick reactions. This issue has now been fixed, so I'd like to ask the community to leave this bug alone and to move forward. If anyone is unable to do that, please email me or comrel directly instead of continuing the discussion here.
Dear Jorge Manuel, Thank you very much for your clear, highly informative explanation of the history, and resolution, of this issue. I agree, let's ALL move forward. Best regards, EncryptedPhreak
