After upgrading to sys-fs/udev-init-scripts-33 the boot process does not finish properly. Logging into a terminal shows a lot of services as starting but they never start. The root files system is still mounted read-only. It is possible to recover the system by manually starting the services. It takes some time to get keymaps started to be able to type properly. Before you need to log in again and again because you are thrown out of the terminal when trying to start certain services. Downgrading to sys-fs/udev-init-scripts-32 serves as a workaround.
Do you have enabled rc_parallel? If yes, does the error go away after disabling it?
(In reply to Lars Wendler (Polynomial-C) from comment #1) > Do you have enabled rc_parallel? If yes, does the error go away after > disabling it? Disabling rc_parallel seems to fix it!
I tested this on my system by enabling rc_parallel. When I did, I was able to boot successfully. One thing you can do is have agetty not clear the screen when you boot and see what errors you actually get. I got an email from someone who did this and saw some error about a thread assertion when a module was being loaded, but I don't know much more than that. William
Glad to see I was not alone with this problem... ! This is in relation with this : https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=6f98cf89f54a9ad1c9625577d100f6ca8b8a2b0b After investigating this for some time, it appears something probably in udev, or very close to udev in the boot order is blocking threads creation for a very short delay. Normally it gets unnoticed except if the boot is in parallel at the same time of course ! As a 1st workaround I went back to rc_parallel=no of course, but finally I returned to rc_parallel=yes with in /etc/init.d/udev : command_args="--daemon ${udev_opts}" # command_background=yes # pidfile=/run/udev.pid which is what there was to start udev in udev-init-scripts-32. By the way with this rc-status -a|grep udev shows started and not crashed, so I don't understand the bug report about the use of --daemon to start udev. Apparently when the --daemon switch is passed to udev, it does a lot of initialisations before forking, maybe it reads its rules at this time, I didn't check. When starting it this way openrc has to wait that it has forked to continue, and this way the thread creation problem is unnoticed, and everything is fine again.
(In reply to William Hubbs from comment #3) > I tested this on my system by enabling rc_parallel. > When I did, I was able to boot successfully. > > One thing you can do is have agetty not clear the screen when you boot > and see what errors you actually get. I got an email from someone who > did this and saw some error about a thread assertion when a module was > being loaded, but I don't know much more than that. No explicit error messages are shown when doing so, just some services not starting probably due to dependency problems.
So I can confirm these issues with rc_parrallel. Here I have random behaviour, sometimes I reach my lxdm login without being able to type anything, other times I end up at the console. However laptop_mode init script shows messages "Failed. Udev not active?".
i can also confirm this bug: openrc + =sys-fs/udev-init-scripts-32 + rc_parallel="yes" it was hard to find. random behavior. system not booting into default runlevel, only sometimes to boot runlevel, and only sometimes with working tty1 console... ouch
Is this still an issue?
Actually, I don't know, as I've disabled parallel execution since this happened. I will enable it again to check!
This is the only change between version 32 and 33: https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=6f98cf89f54a9ad1c9625577d100f6ca8b8a2b0b commit 6f98cf89f54a9ad1c9625577d100f6ca8b8a2b0b (HEAD, tag: 33) Author: William Hubbs <williamh@gentoo.org> Date: Wed Feb 20 10:53:59 2019 -0600 Do not use the --daemon option in the udev service script Using this option does not allow OpenRC to show the status correctly since udevd doesn't write a pid file. We need to create the pidfile ourselves. This changed the udev init script to call start-stop-daemon --background. That means the init script does not wait for udevd to become "ready" before continuing execution. Assuming this is the cause of the issue, a possible workaround would be to call a command like "udevadm control --ping" in stop_post() to synchronize things. However, I'm unsure of a couple of things: 1. How does "udevadm control --ping" behave when the control socket does not exist? 2. Does openrc wait for start_post() to complete before starting subsequent services and completing the runlevel?
After enabling parallel service startup again I did not experience this issue. Maybe it is related to services themselves or anything else changed which provoked the error before.
