A working Manjaro-0.8.9, distro A, with systemd-280-10, hangs while booting, and goes into "Welcome to Emergency mode!" but will not allow any corrections, only Ctrl-Alt-Delete. Caused, repeatably, by installing distro B on to a partition which is already listed in the fstab of distro A. The new UUID apparently causes systemd to choke. Remember how with SysV, when you installed a new distro and then booted your old distro, you used to see: . . . You are about to enter maintenance mode, . . . (Press Control-d to continue): and then, as root, you would have to update fstab in your old distro with the UUID & mountpoint of the new one? Well, it doesn't/ didn't work that way for me. The solutions I've found are these: 1. Always keep a SysV distro, like Debian installed, to allow getting something to boot. 2. Boot into the new install and modify/correct the new UUID for the old distro A. Hopefully, this is already being addressed. Thanks for your time.
"but will not allow any corrections"? What does that mean?
> but will not allow any corrections this means that I was unable to make any keyboard input. A few days after the first occurrence, Emergency Mode will allow input in the form of the 3-finger salute --Ctrl-Alt-Del which starts a reboot, after about a considerable delay. It is possible that I idn't wait long enough. Apologies for any misunderstanding. ------------- After my last update on that system 5 days ago, still, the only input allowed by Emergency Mode is the same, Ctrl-Alt-Del, and wait for it to start rebooting. Emergency Mode does not allow me to login, or perform any other input, such as, run mc and edit the fstab of the existing Manjaro install, in order to actualize it's fstab to reflect the new UUID created by formatting another install. I recreated this same senario by executing Emergency Mode from a normal Xfce4 session, reaching the same end as before --Ctrl-Alt-Del. I believe it would help systemd acceptance by other distros, if Emergency Mode allowed logging in as root to undertake editing of the fstab of the distro with the old UUID. Other than this, systemd seems a considerable improvement over SysV.
I doubt that systemd is involved with the kdb input problem. If you boot with "emergency" on the kernel cmdline, does input then work?
Not yet. I started Emergency Mode from the CLI, but only Ctrl-Alt-Del would respond. Travelling until Saturday night. I will try your suggestion then on the Manjaro-0.8.9rc3 that has the problem. Until then, ISP permitting, I will install the updated Manjaro-0.8.9-xfce-i686 on a netbook to see if Emergency Mode works on it.
Any update?
in Manjaro-0.8.9 with systemd-212-3 here are 2 scenarios: Config1: broke fstab by mangling a UUID by removing some digits 1-Reboot Manjaro ..a-systemd stops and offers several commands for after login, but also offers Ctrl-D to fix the problem; however, it did not respond to Ctrl-D after 5 minutes. ..b-entered root password and logged in. ..c-entered systemctl reboot which rebooted 2-Reboot Manjaro ..a-systemd stops and offers several commands for after login, but also offers Ctrl-D to fix the problem ..b-Applied Ctrl-Alt-Del and the system rebooted. Config2: broke fstab by reformatting the swap file when installing another distro 1-Reboot Manjaro ..a-systemd stops with a message that a start script is running: it starts a countdown of (x of 1.5 minutes). This seems an excessive time to wait for the UUID to fix its self? Perhaps it is waiting for some other action to complete. ..b-after 1.5 minutes it continues booting but there is no indication of what the problem might have been. All in all, systemd works as expected. I have learned to not automount other partitions for automounting in Manjaro with systemd. I was not using automount. That may be the problem that fstab configuration is different from sysv?
OK, closing, since systemd appears to work correctly? If there's still an issue to fix, please file a new issueon github systemd. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.