http://bugzilla.opensuse.org/show_bug.cgi?id=1020327
http://bugzilla.opensuse.org/show_bug.cgi?id=1020327#c17
--- Comment #17 from Fabian Vogt
Ok let's try to make some progress...
systemd-setup-console.service is started several times during the early boot.
This was actually already the case with v228 where the service was started 3 times I think:
- 1 time started by plymouth-start.service due to a dependency Wants=systemd-setup-console.service used in the service file.
This is before plymouth.
- 2 times started by 90-vconsole.rules. I don't really understand why the rule is called a second time here but it seems that one of the vtconsole device is removed (after being added the first time) and then added back again right after. This happens during udev coldplug all devices (systemd-udev-trigger.service).
AFAIK this only configures the newly added devices, so this is always ok as well. This means that none of those invocations by v228 can affect plymouth, which is the correct behaviour.
Now with v232, systemd-setup-console.service has RemainsAfterExit=false. I don't know if this change is correct or not but it has the downside to start one more time systemd-setup-console.service lately during the early boot.
This is incorrect and needs to be changed back (or the service must not be started at all) AFAICS. Once a console got configured, it stays configured.
And this new console configuration seems to confuse plymouth for some reason and makes it crash.
Even if configuring the console several times is not nice, I don't think plymouth is supposed to crash in anyways (BTW I think there is already a bug open for the crash of plymouth) and this bug should be fixed.
@Fabian, in comment #11, you reported that plymouth git master (and also the version in Base:System) has a fix for preventing plymouth from crahsing.
So my suggestion here is to fix plymouth by either upgrading Base:System to git master or by identifying the fix and backport it to Factory.
I already requested that, zaitor had an update already prepared and now submitted it as sr#451329.
In the meantime I think we could also drop the Wants=systemd-setup-console.service from plymouth-start.service because setup-console is supposed to be done via a udev rule (which shouldhappen before plymouth is started).
@Fabian, WDYT ?
udev alone is not enough, otherwise the .service wouldn't be needed at all. When the service fails, bugs like 927250 and its three dups happen. (Or the udev behaviour is buggy, in which case the .service should be removed entirely, I guess) I'd proceed this way for now: - Change back RemainAfterExit in systemd - Update plymouth to sr#451329 - Submit both to factory And wait for the first few test runs to come back. If that works reliably, we can look into optimizing it further. -- You are receiving this mail because: You are on the CC list for the bug.