You are not logged in.
I recently restored one of my machines from a backup from July 4th. I updated the system before creating the backup so all packages were the latest versions at that time. After restoring from the backup (a full clone of the main drive created using dd) and fixing some problems with the EFI bootloader not working for unknown reasons and upgrading the packages again from the live USB stick that I used to restore the system, I was able to successfully boot the kernel.
However, systemd failed with the following error and I had to enter my root password to access a terminal in emergency mode:
Jul 22 09:10:40 hostname systemd[1]: Reached target Local File Systems (Pre).
Jul 22 09:10:40 hostname systemd[1]: etc-resolv.conf.mount: Failed to check directory /etc/resolv.conf: Not a directory
Jul 22 09:10:40 hostname systemd[1]: Mounting /etc/resolv.conf...
Jul 22 09:10:40 hostname systemd[1]: etc-resolv.conf.mount: Mount process exited, code=exited status=32
Jul 22 09:10:40 hostname systemd[1]: Failed to mount /etc/resolv.conf.
Jul 22 09:10:40 hostname kernel: usb 4-1.1: new high-speed USB device number 3 using ehci-pci
Jul 22 09:10:40 hostname systemd[1]: Dependency failed for Local File Systems.
Jul 22 09:10:40 hostname systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Jul 22 09:10:40 hostname systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Jul 22 09:10:40 hostname systemd[1]: etc-resolv.conf.mount: Unit entered failed state.
Jul 22 09:10:40 hostname systemd[1]: Reached target Login Prompts.
...
After a number of other messages that succeeded without incident, the following occurs:
Jul 22 09:10:40 hostname systemd[314]: emergency.service: Failed at step EXEC spawning /bin/plymouth: No such file or directory
Since the first error seemed to be due to resolv.conf not being a directory, I tried renaming it and creating a directory named /etc/resolv.conf. After this change, the machine booted without incident. However, DNS resolution (for example in my web browser and using drill and dig failed with an error message indicating that no nameservers were available. It is possible to restore DNS resolution after each boot by umounting /etc/resolv.conf and replacing it with my original resolv.conf file. However, this is far from a satisfactory solution...
I am rather confused as to why /etc/resolv.conf is expected to be a directory in the first place. It certainly was not before I upgraded and I have been unable to find any useful information on this.
I thought that this problem was perhaps related to the dnsmasq, libvirtd and openvpn packages so I tried uninstalling them and rebooting with the original resolv.conf file. However, the exact same errors occurred. I have also tried downgrading from systemd 230 to systemd 229 but this also resulted in the same errors.
The contents of my resolv.conf file (not directory is as follows):
nameserver 192.168.0.1
(The machine is a desktop with an ethernet connection and the above IP is that of my router.)
The kernel version is 4.6.4-1.
Last edited by Superposition (2016-07-24 21:51:12)
Offline
What does systemctl say about etc-resolv.conf.mount?
Not a Networking issue, moving to NC...
Offline
The output of systemctl status -l etc-resolv.conf.mount is
● etc-resolv.conf.mount - /etc/resolv.conf
Loaded: loaded (/etc/fstab; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2016-07-24 14:24:42 PDT; 2min 2s ago
Where: /etc/resolv.conf
What: /etc/resolv.conf/etc/resolv.conf
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 308 ExecMount=/usr/bin/mount /etc/resolv.conf/etc/resolv.conf /etc/resolv.conf -t none -o rw,relatime,lowerdir=/run/archiso/sfs/airootfs,upperdir=/run/archiso/cowspace/persistent_ARCH_201606/x86_64/upperdir,workdir=/run/archiso/cowspace/persistent_ARCH_201606/x86_64/workdir,bind (code=exited, status=32)
Jul 24 14:24:42 hostname mount[308]: mount: mount point /etc/resolv.conf is not a directory
There are paths to the archiso image. Perhaps I used chroot instead of arch-chroot before running mkinitcpio again. Rerunning mkinitcpio from the emergency mode shell had no effect however...
Offline
What's in your /etc/fstab? It shouldn't have anything about resolv.conf
Offline
/etc/fstab did have a line involving resolv.conf and deleting it fixed the problem.
Presumably, it somehow got added when I ran genftab again since I formatted some of the auxiliary disks which caused the UUIDs to change...
Thanks very much for the replies!
Offline
Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.
Offline