Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 678638 - sys-fs/udev-init-scripts-33 - system does not boot successfully with rc_parallel=YES
Summary: sys-fs/udev-init-scripts-33 - system does not boot successfully with rc_paral...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo systemd Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-23 17:24 UTC by Daniel Pielmeier
Modified: 2023-09-30 09:28 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pielmeier gentoo-dev 2019-02-23 17:24:22 UTC
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.
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2019-02-23 17:27:37 UTC
Do you have enabled rc_parallel? If yes, does the error go away after disabling it?
Comment 2 Daniel Pielmeier gentoo-dev 2019-02-23 18:12:50 UTC
(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!
Comment 3 William Hubbs gentoo-dev 2019-02-24 23:59:42 UTC
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
Comment 4 Emmanuel Anne 2019-03-01 22:09:02 UTC
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.
Comment 5 Daniel Pielmeier gentoo-dev 2019-03-02 12:25:44 UTC
(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.
Comment 6 bugs.gentoo 2019-03-04 20:34:46 UTC
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?".
Comment 7 j4Hu 2019-03-12 08:39:56 UTC
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
Comment 8 Mike Gilbert gentoo-dev 2023-09-18 01:18:47 UTC
Is this still an issue?
Comment 9 Daniel Pielmeier gentoo-dev 2023-09-19 17:51:27 UTC
Actually, I don't know, as I've disabled parallel execution since this happened. I will enable it again to check!
Comment 10 Mike Gilbert gentoo-dev 2023-09-19 18:55:46 UTC
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?
Comment 11 Daniel Pielmeier gentoo-dev 2023-09-30 09:28:05 UTC
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.