after several months I booted up my Manjaro system that is running on a Fujitsu Esprimo Q920. Linux is installed on external SSD that is connected with a SATA-to-USB-Adapter with a USB 3.0 port.
The system boots with UEFI mode. Secure Boot is disabled.
Until yesterday there were no problems regarding booting. But then I had to install hundreds of updates. And after the update I now get the following error message when choosing to boot from the external SSD:
mount: /new_root: can't find UUID=xxx-xxx-xxx-xxx-xxxx.
Your are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
There were exactly no changes to the hardware or the partitioning.
Nothing has changed in the BIOS/UEFI.
I can boot with a USB stick containing the Manjaro Live system. manjaro-chroot -a lets me do a change root. There I could reinstall the efi entries and reinstall and update grub. Also I ran the manjaro-rescue tool. But nothing helped to fix this annoying boot error.
I also compared with the lsblk command the UUID of the drive with /etc/fstab. It hasn’t been changed.
Please help me to get my Manjaro system up and running again.
thanks for you answer. I did the steps you described but I get the same error message.
manjaro-chroot -a gives the following warning twice:
grub-probe: error: cannot find a GRUB drive for /dev/sbd1. Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sbd1. Check your device.map.
==> Mounting (ManjaroLinux) [/dev/sdc2]
--> mount: [/mnt]
--> mount: [/mnt/boot/efi]
This is the output of lsblk:
/dev/sdc1 is the boot partition. When I normally booted without the Manjaro installation USB stick it was recognized as /dev/sdb1. The root partition is normally /dev/sdb2. When using the Manjaro installation USB stick it becomes /dev/sdc2.
sdc 8:33 0 111.8G 0 disk
|-sdc1 8:33 0 300M 0 part /boot/efi
'-sdc2 8:34 0 111.G5 0 part /
blkid shows me the UUIDs of the boot and root device. It matches the UUID in /etc/fstab and /boot/grub/grub.cfg.
I could run mkinitcpio -P without errors.
But after restart I get exactly the same error.
I did not change anything on the hardware side and on Manjaro side. I just upgraded all packages with the normal update procedure. After restart the problem occured.
If I should provide additional information just let me know.
This is why we use UUIDs instead of the names device special files. No, seriously, it is. The order of the drives as discovered by the kernel at boot time can get thrown around due to parallelism and electrical glitches, making the /dev/sdXN designations unreliable.
@Aragorn, you’re of course right. I understand the concept of using the UUID compared to the device IDs. But for some strange reasons this seems not to work anymore. No devices have been changed, removed or added. I also did not change anything at the Manjaro configuration (partitions, other flavor etc.). It was just upgrading all packages which got an update.
Belive it or not: I did not change anything beside the package updates.
I’m computer scientist so I of course know from my job the normal answers of end users if something is not working: “I haven’t done anything”. But in this case it is true.
No, it’s not persistent — it was an ad hoc way of testing whether your system can boot. The problem will persist until we find out what’s causing it.
Recreate initramfses with mkinitcpio -P and try again. If same thing happens show /etc/fstab when in initramfs shell. You can also try booting fallback one.
… or something similar to that, replace the udev hook by systemd and keymap by sd-vconsole. When you then recreate the initcpios, systemd will detect your actual runtime configuration and include all the necessary modules.
Also check which compression algorithm is being used — it’s at the bottom of the file. Older kernels do not support zstd compression for the initcpios yet, but I’m not sure of the kernel version where zstd support was introduced. I think it was in 5.10, but I could be wrong about that.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=1F64-1623 /boot/efi vfat umask=0077 0 2
UUID=b2a82deb-209d-4e12-bbc1-50daf6bb08fd / ext4 defaults,noatime,discard 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
That file should be there. It’s the configuration file for the mkinitcpio utility. The /etc/mkinitcpio.d directory contains the presets for the kernels you’ve got installed.
No, seriously, it is. The order of the drives as discovered by the kernel at boot time can get thrown around due to parallelism and electrical glitches, making the 
