Grub with /dev/sdX instead of UUID

Hey everybody,
I am administrating a german school with 150 machines, all running Linux Mint so far but I really wanna switch to manjaro.
We use a cloning tool to set up a "master machine" wich is cloned via pxe-boot. This is running great so far, but with grub and latest manjaro I am running into the following problem:
After I set up a machine (cloned it), it does not boot, it gives me these errors:

  • ERROR: resume: hibernation device "UUID=...:" not found
  • mount: /new_root: no filesystem type specified. You are now being dropped into an emergency shell

From what I have seen: The cloning does work, but the tool I use does not clone the UUIDs.
So what I need: Change grub menu from UUID to /dev/sda or hd(0,1) or whatever.
I tried to change that in /etc/default/grub (GRUB_DISABLE_LINUX_UUID=true) and did a "grub-mkconfig -o /boot/grub/grub.cfg", but it seems, grub still uses UUID. I changed fstab to sdaX instead of UUID.
I can not change the clonetool, I just need to change grub.

Thanks for any help!

Then post here:

  1. Grub.cfg from the old machine (Linux Mint)
  2. Grub.cfg of the new computer (Manjaro)

IMHO you have to first remove the resume=UUID= from GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub and replace it with resume=/dev/sdXY where sdXY is the partition ...
plus have the

and the fstab as you did
In case you don't use the resume=/dev/sdXY then you have to remove the resume from HOOKS line in /etc/mkinitcpio.conf
then run from terminal:
sudo mkinitcpio -P
sudo update-grub

Also, i think the command

will not work as expected and the result might be messy.

Once this is done, the clone should work on other systems.

You should better run a script that adds the correct UUID to fstab and grub instead of using sdx. Remember that /dev/sda is NOT a unique thing and might change.

1 Like

Wow, thanks for the reply! Will try that asap and report!

Thanks for your advice. In my environment however, these are unique and will not change.

We deploy and distribute our systems another way (It's Arch)

  1. Manually set the boot device - dynamically set the filesystems:
    • Partition1 Name: EFI, Size: 500MiB (fix)
    • Part 2 Name: ROOT, Size: 35GiB (fix)
    • Part 3 Name: HOME, Size: whats left on the device
  2. Start a rsync job to copy files 1:1 to the new system
  3. Create a fstab
  4. mount/bind-mount and chroot into that system
  5. run updates
  6. run systemd-boot to have a bootloader
  7. reboot to the final system

It's a simple script. from there on the admin can login and create another user if needed. total runtime is (without download times for updates) around <7 min.

There are certain things you really do not want to just copy, like hostname, fstab, machine-id.

I mean it's your environment, but I always think that once done right will help a lot, like right now where we transitioning to NVMe, so we do not have a sda at all (or its the USB drive).

That said, I dont bother you anymore in here :joy:

1 Like


# 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"

I totally get you. But I start the cloning via pxe-boot, the only time I touch a machine is to start it, from that point, the pxe-boot and cloning is completely automatic, /home comes via nfs, users via ldap. Time to set up a machine: far beyond 7 mins., more like 3. No script needed if done right. And if I use WOL I never ever touch the machine, I clone it via webinterface (this gives me the possibility to alter the pxe-boot of each machine individually), I am not even at school, I can do from home: Reboot and clone all machines just by some clicks....
So I guess you could say: It's done right. :slight_smile:

As mentioned in my first post: that's exactly what I did. :roll_eyes:

I ended up using Grub legacy on Mint, because I just couldn't get it to work with grub2. I was hoping we could change that.

Ok, tried it, same again.... it says now "hibernation device /dev/sda2 not found, even though it is perfectly there....

Hm. Then your setup is different or you didn't apply the change correctly.

I've just edited that line, then ran update-grub and:

$ diff grub.cfg.bak grub.cfg
< 	linux	/vmlinuz-5.1-x86_64 root=UUID=d24f9be8-5af1-4285-921e-4d12b4b9f6ba rw ...
> 	linux	/vmlinuz-5.1-x86_64 root=/dev/sda3 rw ...

which appears to have switched GRUB from UUIDs to device paths.

This is not working for me.... strange! Very strange. I am using a standard Manjaro installation, all up to date......

Wait..... I just tried it again: I get it now..... but still, the clone would not boot.... I have to think further.... I will get back and thanks so far everybody.....

1 Like

The standart boot loader is grub2 nowadays.

Yeah, I know. And I want to stick with it. I just had to switch to Grub (legacy) on my Mint installation because the cloning would not work otherwise. I hoped I could solve this and get it running with grub2.

Then do not setup hibernation (or even swap in favor of systemd zram) on the master machine.
As said, remove resume from mkinitcpio hooks and resume partition from /etc/default/grub.
UUID in grub shouldn't matter, but I don't think it's a sane idea to clone drives without later changing UUIDs on the cloned systems. You need to use a script that does that (or add it to your currently used script).
Even on windows, after cloning, changes are needed and applied before first normal boot.