I have a very old machine (15 years old) that I am still updating and using.
After today’s update of Tumbleweed, it doesn’t boot but goes into rescue mode with:
Failed to start default.target: Unit may not be isolated.
After loggin in with root password, and digging through the logs with journalctl I find these:
fév 12 10:09:05 argo.dxprod.sympato.ch systemd[1]: Unit default.target not found.
fév 12 10:09:05 argo.dxprod.sympato.ch systemd[1]: Falling back to rescue.target.
Long story short: /etc/systemd/system/default.target was pointing to /lib/systemd/system/runlevel5.service (instead of something like, e.g., /lib/systemd/system/graphical.target)
Turns out my continously updated install of Opensuse from 15 years ago predates SystemD.
Some years ago, while a package update did switch from SysVInit to SystemD, it used pseudo traget “runlevel5” to mimic SysVInit’s rc5.
The latest SystemD update in Tumbleweed finally dropped those backward compatibility targets.
But no postinst code ever checked that this target was still used to put a big fat warning, or at least by default switch to the most likely actual target (classical runlevel5 was used for boot with GUI, so if the users hadn’t tweaked the run levels, graphical.target would be a good replacement) .
I am leaving this post just to make it searchable so the other 2 or 3 users that have continuously update Tumbleweed for more than a decade can find an answer.
…I think I need a"vintagesystems" tag for this post…
I still have access to a VPS that was installed with TW in 2013, which actually was before TW officially became a thing. That VPS ( not mine ) already came with systemd, and the announcement by GregKH re. TW is from late 2011, even after making systemd the default init system ( openSUSE 12.1 ). So, somewhere along the road your system must have moved from either old openSUSE, or from Factory.
The VPS is useless as a comparison; it has not been updated since new management decided the € 100 they paid me per month for small maintenance should be pro deo and could be done by anybody ( ~5 years ago ). They called me yesterday about having no passwords for root and ssh ( LOL, it’s key only ) which of course I don’t have anymore. From what their troubleshooter said, they may actually have been hit by the issue you describe. She said it happened after she saw that the machine had been up for > 1700 days and decided to reboot the VPS. Which has default.target most likely pointing at runlevel3 instead of multi-user.target.
Heheheheh, did not want to give my personal brain algorithm for work passwords, so she let me try. Second attempt at the 21char root password worked. Gave her the rest of the info, rest is up to her. From what I got she understood the issue, and how to fix it. She also asked if I would like to be the other paid IT volunteer. Current management never wants something like this to happen again.
