Mount: /new_root: can't find UUID=... but the UUID definitely exists

My motherboard went out on me, so I got a brand new, identical one. I moved everything over including the two NVMe drives I had in the old one. One for Manjaro, the other for Windows. I’ve been using this computer and Manjaro installation for well over a year (guess I got a bad motherboard)

When I power it on everything comes up just like it used to - I get the grub menu, and I can select either Manjaro or Windows. Windows will come right up, but when I select Manjaro, I get the following:

mount: /new_root: can’t find UUID=99…58
You are now being dropped into an emergency shell
sh: can’t access tty: job controller turned off
[rootfs] #

And I am dropped in that shell, and my keyboard doesn’t work at all.

What I have tried
Other have had this problem, and I have tried the suggestions in there:

  • Boot from USB
  • run sudo su -
  • run manjaro-chroot -a,
  • run blkid
  • get the UUID of the drive with the Manjaro partition
  • run nano /etc/fstab
  • compare UUIDs

They match. And they also match the several found in /boot/grub/grub.cfg.


  • run
mkinitcpio -P
  • Make sure I’m in ACHI mode
  • Make sure RAID is turned off

No effect.

If I open the file explorer I can see the drive as well and explore it. If I look at the mount point of the drive, it has the UUID at the end that the error says can’t be found.

Any other things I can try?

Are you using encryption?

Did this immediately start happening with the new motherboard?

What are the contents of the file /etc/default/grub

You probably need to reinstall Grub2.


Not using encryption.

Yes. Immediately after. Everything was working, then the motherboard stopped working, so I swapped it, and could not boot into the drive.

Here are the contents (does it matter that I ran manjaro-chroot -a before running this command?)

[manjaro /]$ cat /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet udev.log_priority=3 pci=nomsi,noaer"

# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices

# Uncomment to use basic console

# Uncomment to disable graphical terminal

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'

# Uncomment to allow the kernel use the same resolution used by grub

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"

# Uncomment to disable generation of recovery mode menu entries

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.

# Uncomment one of them for the gfx desired, a image background or a gfxtheme

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically

# Uncomment this option to enable os-prober execution in the grub-mkconfig command

Just did that. 2 things now:

In my BIOS I can boot from a GRUB partition of my NVMe, or the root partition (something like that). If I boot from the GRUB one, I get the exact same results as before. No change. If I boot from the other, I instantly get an error complaining about how grub_debug_malloc cannot be found. I’ve followed a few other threads on how to rectify this new issue, but none work or apply. Some mention how I have to mount the correct partition to /boot/efi before I install or update grub, but when I check that is already done.

Can you elaborate? I’m not sure what you mean with those terms.

Let’s try to redo the steps again, but with some additional steps:

  1. Boot into a live USB and chroot (manjaro-chroot) into your Manjaro system

  2. Make sure that within this chroot, /boot/ and /boot/efi/ are both available

  3. Re-install Grub to the EFI partition using the grub-install tool
    3a. Normally, you can just run grub-install without any additional parameters, as it will automatically detect everything

  4. Modify the HOOKS array of your /etc/mkinitcpio.conf so that block is placed before autodetect
    4a. Rebuild the initramfs with mkinitcpio -P

  5. Modify the GRUB_CMDLINE_LINUX_DEFAULT entry in your /etc/default/grub to add the option nvme_load=YES
    5a. Update Grub’s menus with update-grub

  6. Exit the chroot and reboot.

Of course. I didn’t have it up when I typed it and I wasn’t confident that I was making much sense.

When I hit DEL as it boots up and I get into the BIOS I can choose what drive I can boot from. After doing the steps suggested above, I see the following:

UEFI OS (M.2_1: GIGABYTE...) (1000.2GB)
GRUB (M.2_1: GIGABYTE...) (1000.2GB)

What I was saying is that if I choose the GRUB one, I get the same behavior that I got from my original post. If I try the UEFI one, I get the grub_debug_malloc error. The GRUB one didn’t show up until I reinstalled grub.

I just did your suggested steps, and now I have a 3rd option in my boot selection menu:
manjaro (M.2_1: GIGABYTE...) (1000.2GB)

Selecting it yields the same results as selecting the GRUB option, where it gives the same original can't find UUID error (and no grub menu is ever shown).

Another other ideas I can try?

I’m wondering if at this point I just throw in the towel and do a fresh re-install. If I use manjaro-chroot, will that allow me to get a list of all the things I have installed so I can install them again after I start over? Also, is there any danger in making a backup of my /home/<user> folder and just copying it to the new installation?

I have the same problem after updating 2 days ago - I have had to revert to a backup I made last week. I am thinking of re-installing Manjaro since this seems to be the simplest solution. Did you find any problem in copying your /home/ folder to the new installation ?

Having the same issue today after a fresh install. Tried re-installing but I’m getting the same issue.

I can see the partition exists indeed by using blkid.

PS: Entering grub and changing the kernel parameter to root=/dev/mmcblkXpY works fine so it just doesn’t work with the UUID.

1 Like

I have the same problem after updating, cann’t boot by linux cmd with param root=UUID=…, but boot normal after changing the param to root=/dev/sda1 in grub.

1 Like