After Fedora 43 dnf-upgrade default.target links to non-existent file

Ask Fedora
1

I did two dnf-upgrades to Fedora 43 yesterday (I’ve been doing dnf-upgrades for a long time). On a server VM (no graphical interface, boots to multi-user target) everything went well. On my laptop (Thinkpad T460) it booted to the recovery console.

Looking through journalctl -xb no obvious error messages pointed to the problem, also systemctl isolate <any>.target would fail with unit is not isolated or something like that.

After some digging I found out the /etc/systemd/system/default.target was a symbolic link to a non-existent target under /lib/systemd/system when it should be to the same named file under /usr/lib/systemd/system**.**

Fixing the link and isolating the default.target (or rebooting) made it work, and now /lib is a symbolic link to /usr/lib. Suspect something went wrong with the merging of /bin and /usr/bin, in this much older system than the VM.

2

Setting the default target should be done using systemctl set-default. For example

systemctl set-default graphical.target

or

systemctl set-default multi-user.target
3

I’m guessing it was a link to runlevel3.target or similar rather than something modern like multi-user.target or graphical.target?

I ran into the same thing on a few machines and it seems the old runlevelN target aliases have been removed so you need to make sure systems are using one of the modern equivalents.

1 Like
4

Yup, but once logged on to some level, isolate is used to switch. The default was already set to graphical.target before the update and I was just trying to use some other target from the recovery target.

5

Yes. I believe it was runlevel5.

Guessing that machines where the first install was long ago and only dnf-upgraded ever since will encounter this problem. I have two more machines to go, one has the link to runlevel5 the other doesn’t. I’ll fix the bad link before upgrading.

6

I had the same problem with a system that has been upgraded since the early Fedora Core days – default.target was linked to runlevel5.target which no longer exists.

7

I have another Fedora 42 system in the same situation pre-upgrade, and note that doing systemctl set-default multi-user.target on this system does not appear to set the target properly:

[root@darwin ~]# systemctl set-default multi-user.target
[root@darwin ~]# ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 Nov 27  2010 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target
8

Filed bugzilla bug

9

That target was set 15 years ago. Back then systemd was in /lib/systemd. Now /lib is a symbolic link to /usr/lib so /usr/lib/systemd and /lib/systemd refers to the same directory.

Try set the default to some other target or just remove /etc/systemd/system/default.target, and after that set the default target to multi-user.target.

The runlevel targets are no more in Fedora 43.

10

Yep, I know that and I also understood the resolution. My point was that 1) these files were removed only in Fedora 43, which breaks upgrades for some working systems (so maybe this should be in the release notes?), and 2) executing systemctl set-default multi-user.target on a Fedora 42 system does not solve the problem without manual intervention i.e.

rm /etc/systemd/system/default.target
# or multi-user.target
ln -s /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target
11

This is part of the changes going to systemd258, Release systemd v258 · systemd/systemd · GitHub

    * Support for System V style system state control has been removed:
      - The /dev/initctl device node has been removed.
      - The initctl, runlevel, and telinit commands have been removed.
      - Support for system state control via the init command (e.g.
        'init 3') has been removed.
      - The units runlevel[0-6].target have been removed.
      - The concept of runlevels has been removed, so runlevel transitions
        are no longer recorded in the utmp/wtmp databases.

Agree that it would’ve been nice for this to be mentioned somewhere in the :fedora: documentation.

1 Like
12

It would have been nicer if the update to systemd258, be it systemd’s or Fedora’s patched, fixed the links.

I had a link from /etc/systemd/system/default.target pointing to /lib/systemd/system/runlevel5.target, this one being a local link to graphical.target. Not too hard to fix in a script.

2 Likes