http://bugzilla.opensuse.org/show_bug.cgi?id=1094762 http://bugzilla.opensuse.org/show_bug.cgi?id=1094762#c83 --- Comment #83 from Franck Bui <fbui@suse.com> --- (In reply to andreas bittner from comment #82)
yes it is a testing system.
side note: my other production system that was in the unrebooted state, i had the idea to reboot it eventually via reboot -f (reboot alone did nothing) but it never came back since :( so I need to visit on site and see where it hangs or what went wrong.
Possibly some services weren't enabled/disabled during the upgrade... it would help if you could get the logs.
my other production site has some mdraid and data that i dont dare yet to reboot maybe until we find out more about this bug.
At least let's see what the status of your other system that doesn't boot anymore. That said for production systems I wouldn't recommend to make such major upgrade "online" but use the ISO instead. Isn't that the official way to do such upgrades BTW ?
or would it be safe to manually fire up the systemd main (which exactly?) process somehow and re-execute all the processes from the zypper dup stage that wanted to interact with systemd?
Unfortunately I can't think of a way to restart systemd when it exited or crashed. Maybe some people on the systemd mailing list might have some idea...
it is totally unclear to me what I can do about my hanging pending production system where this bug happened during dup.
what is a possible workaround even now that the situation happened?
I'm afraid there're no workarounds at that points :( -- You are receiving this mail because: You are on the CC list for the bug.