After installation of autofs-5.1.3 autofs does not work anymore. I have a broken link /etc/systemd/system/multiuser-usr.target.wants/autofs to /usr/lib/systemd/system/autofs.service. With autofs-5.1.2 this file is installed with autofs: root@cheetahnew:/usr/src/linux(71)# qfile -v /usr/lib/systemd/system/autofs.service net-fs/autofs-5.1.2 (/usr/lib/systemd/system/autofs.service) root@cheetahnew:/usr/src/linux(72)# qlist autofs | grep service /usr/lib/systemd/system/autofs.service root@cheetahnew:/usr/src/linux(73)# qlist -Iv systemd sys-apps/gentoo-systemd-integration-7 sys-apps/systemd-233-r4 With autofs-5.1.3 and systemd-234-r1 /lib/systemd/system/autofs.service is installed and some links under etc/systemd/system/multiuser-usr.target.wants are broken. (BTW. /usr/lib/systemd/system/systemd-networkd.service is missing too.)
Please define "does not work". What do you expect to happen, and what actually happens? Unit files are moved to /lib/systemd/system as a result of rebuilds after upgrading to systemd-234. The broken symlinks should not be a problem; systemd actually ignores the symlink target for links in foo.target.wants/.
(In reply to Mike Gilbert from comment #1) > Please define "does not work". What do you expect to happen, and what > actually happens? > > Unit files are moved to /lib/systemd/system as a result of rebuilds after > upgrading to systemd-234. The broken symlinks should not be a problem; > systemd actually ignores the symlink target for links in foo.target.wants/. I wanted to switch the network without rebooting. I.e. I switched several configuration files or directories /etc/host, /etc/systemd/network, /etc/pine.conf, /etc/samba/smb.conf, /etc/ntp.conf, ... . Then I tried to run my network switch script, which restarts several services like systemd-resoolved, systemd-networkd, wpa_supplicant@wlan0, rpcbind, nfs-idmapd, nfs-mountd, rpc-gssd, smbd, nfs-server, ntp, cups, sshd, ... This script fails now, I do not have any network connection. Furthermore the reboot/shutdown button of gnome disappeared. Then I tried to isolate the errors. The first thing a found, were the broken links under /etc/systemd/system/multiuser-usr.target.wants. I will remove the broken links, reboot and continue to investigate.
Removing the broken symlinks should be unnecessary, and will likely not resolve any problems. Rebooting sounds like a good idea.
(In reply to Mike Gilbert from comment #3) > Removing the broken symlinks should be unnecessary, and will likely not > resolve any problems. > > Rebooting sounds like a good idea. Seems likely. After upgrading the units would have all moved, but the systemd that is running is probably looking in the old location for them, since it wasn't built otherwise.
'systemctl reboot' fails as well: root@lynx:/root(18)# systemctl reboot Failed to set wall message, ignoring: Unit dbus-org.freedesktop.login1.service not found. Failed to reboot system via logind: Unit dbus-org.freedesktop.login1.service not found. Failed to start reboot.target: Unit reboot.target not found. 'shutdown -h now' fails with: The system is going down for system halt NOW! shudown: timeout opening/writing control channel /dev/initctl init: timeout opening/writing control channel /dev/initctl
After hard reset booting fails with: >> Initializing root device... >> Detecting root: /dev/sdb6 >> Mounting /dev/sdb6 as root... >> Detected fstype: ext4 >> Using mount fstype: ext4 >> Using mount opts: -o ro EXT4-fs (sdb6): INFO: recovery required on readonly filesystem EXT4-fs (sdb6): write access will be enabled during recovery EXT4-fs (sdb6): orphan cleanup on reaonly fs EXT4-fs (sdb6): 197 orphan inodes deleted EXT4-fs (sdb6): recovery complete EXT4-fs (sdb6): mounted filesystem with ordered data mode. Opts: (null) !! The filesystem /dev/sdb6, mounted at /newroot does not contain a valid init=/usr/lib/systemd/systemd !! Could not find the root block device in /dev/sdb6 ... If I enter 'shell', I see two files under /lib/systemd/ libsystemd-shared-234.so and systemd-udev. Should I replace the real_init=/usr/lib/systemd/systemd by /lib/systemd/systemd-udev in /boot/grub/grub.cfg?
Try "systemctl daemon-reexec" instead. That will load the new version into memory, along with the updated paths. I think you tried to do too much with systemd without having restarted it.
(In reply to Juergen Rose from comment #6) > Should I replace the real_init=/usr/lib/systemd/systemd by > /lib/systemd/systemd-udev in /boot/grub/grub.cfg? Looks similar to bug 625462, only with genkernel instead of dracut. Updating the boot config to init=/lib/systemd/systemd should resolve the issue. I will revbump systemd soon with relative symlinks since those tend to work better for path checking.
Booting with real_init=/lib/systemd/systemd-udev fails as well.
(In reply to Juergen Rose from comment #10) > Booting with real_init=/lib/systemd/systemd-udev fails as well. Of course; udev is not an init system. Get rid of the "-udev".
(In reply to Mike Gilbert from comment #9) > (In reply to Juergen Rose from comment #6) > > Should I replace the real_init=/usr/lib/systemd/systemd by > > /lib/systemd/systemd-udev in /boot/grub/grub.cfg? > > Looks similar to bug 625462, only with genkernel instead of dracut. Updating > the boot config to init=/lib/systemd/systemd should resolve the issue. > > I will revbump systemd soon with relative symlinks since those tend to work > better for path checking. Booting with init=/lib/systemd/systemd worked. After booting and cleaning /etc/systemd/system/multiuser-usr.target.wants/ (systemctl disable systemd-networkd; systemctl enable systemd-networkd; systemctl disable autofs; systemctl eable autofs; ...) I see that there is now again a /usr/lib/systemd/systemd which is a link to lib/systemd/systemd. Do I have to modify GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/usr/lib/systemd/systemd rootfstype=ext4" in /etc/default/grub to GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/lib/systemd/systemd rootfstype=ext4" and recreate /boot/grub/grub.cfg or is this not necessary?
(In reply to Juergen Rose from comment #12) > Do I have to modify > GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/usr/lib/systemd/systemd > rootfstype=ext4" > in /etc/default/grub to > > GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/lib/systemd/systemd > rootfstype=ext4" > > and recreate /boot/grub/grub.cfg or is this not necessary? Yes, I would suggest making the change you have proposed above.
(In reply to Juergen Rose from comment #12) ... > autofs; systemctl eable autofs; ...) I see that there is now again a > /usr/lib/systemd/systemd which is a link to lib/systemd/systemd. > > Do I have to modify > GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/usr/lib/systemd/systemd > rootfstype=ext4" > in /etc/default/grub to > > GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm real_init=/lib/systemd/systemd > rootfstype=ext4" > > and recreate /boot/grub/grub.cfg or is this not necessary? Booting with an unmodified /etc/default/grub failed with the same error as before.
Booting with the modified /etc/default/grub works.
I don't think there's any bug in autofs here, so I'm closing this.
