Comment # 83 on bug 1094762 from Franck Bui

(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 :(