On 7 June 2017 at 16:13, <m.roth at 5-cent.us> wrote: > Matthew Miller wrote: >> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.roth at 5-cent.us wrote: >>> I just updated a system - as in minutes ago, and log back in after it >>> reboots, and this is in dmesg: >>> [ 88.202272] systemd-readahead[484]: >>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many >>> levels of symbolic links >>> [ 88.202515] systemd-readahead[484]: >>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/lib/systemd/system/dracut-emergency.service) >>> failed: Too many levels of symbolic links >>> Anyone know what this is - some weird bug, a garbage message? >> >> systemd-readahead is just trying to pre-cache stuff into memory so boot >> time is faster. I'm not sure eaxctly what's going on here but that >> message is typical of having a loop in your symbolic links (which can >> easily happen with relative links). >> >> I'm not quite sure what *exactly* is going on, but it looks like maybe >> dracut temp files didn't get cleaned up properly and that they contain >> such a loop. I bet you can just rm -rf /var/tmp/dracut.fP4yj1. >> > Thanks for the info. Now, why it shouldn't have cleaned itself up when I > gave it the reboot command... I see too many (that's defined as more than > zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things > to finish - sush as not getting the hostname from dhcp, and so having to > hardcode the name instead. > > Systemd, as I've said before, seems to be targeted towards laptops. Not > servers. Not workstations. *bleah* > Mark stop with the flame baiting please. This is nothing systemd specific - and keep in mind /var/tmp is a persistent temp area unlike /tmp which as it's tmpfs by default is of course emptie don boot.