failed to mount PARTUUID on real root [SOLVED]

jsalk · 2024-07-15 01:31:10

I have cloned my Arch linux disk many times to create a new device without any issues. This time around, I cannot get it to boot successfully. I get an error message saying that PARTUUID failed to mount. The PARTUUID refers to /dev/sda1 which is a FAT32 format with boot and esp set.

loader.conf and arch.conf appear to be correct as I compared them to any number of online set-up tutorials.

I have used dd to clone my existing drive many times and have never had this issue. It times out when trying to mount reporting "fail to mount PARTUUID(partuuid number) on real root" and then drops into the emergency shell and is locked up.

Any ideas?

Last edited by jsalk (2024-07-17 13:13:29)

Scimmia · 2024-07-15 01:35:54

That's in your bootloader config. Did you fix or regenerate it?

jsalk · 2024-07-15 17:39:13

I edited my comments above to reflect the current status. Seems there is an issue trying to mount /dev/sda1, but I don't know why.

I checked the drive using GParted and it shows that /dev/sda1 is formatted with FAT32 and boot and esp are set.

jsalk · 2024-07-15 18:05:36

During boot process, the screen reports that the UUID or PARTUUID for /dev/sda2 cannot be found. But it's obviously there.

Head_on_a_Stick · 2024-07-15 19:03:05

It would probably be helpful if you shared the exact dd command used to clone the system along with the actual contents of arch.conf and the output of `blkid`, just in case you've made a mistake. Follow https://wiki.archlinux.org/title/List_o … ted_client to share command output from the Arch live ISO. Also use the `file` command on the kernel image (/boot/vmlinuz*) and check the version matches the contents of /usr/lib/modules/.

I presume this is systemd-boot with the ESP mounted under /boot/? You really should have included more information in the OP.

jsalk · 2024-07-15 20:06:43

By the way, the drive boots just fine if I use a USB adapter and boot as if it were a USB drive.

seth · 2024-07-15 20:57:33

HoaS wrote:

It would probably be helpful if you shared the exact

error message (next to the bootloader config and lsblk)
In doubt link a photo (of the kernel messages, not the data you can handily obtain as actual text - and remove the "quiet" parameter)

jsalk · 2024-07-15 22:02:31

Sorry for the lack of detail. Here are some specifics.

To clone the original drive, I used dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror

The cloned drive boots fine if I use a USB adapter on the drive and boot as a USB device.

blkid:
/dev/sda2: UUID="87d0cb74-974e-4faa-8185-cd23bc815f6d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9559d5f6-fdbf-44da-8383-8f88d216b3ad"
/dev/sda1: UUID="545C-B608" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b8eb84a0-9b3d-46c9-ab5b-e07b2c86235d"
/dev/sdb1: UUID="e6c3924f-fcf7-4866-b9ed-3b1f23a8ee3f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="000858d6-01"

Contents of loader.conf
default arch
timeout 3
editor 0

Contents of arch.conf:
title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd initramfs-linux.img
options root=PARTUUID=9559d5f6-fdbf-44da-8383-8f88d216b3ad rw

Output of lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdb 8:0 0 1.8T 0 disk
mqsdb1 8:1 0 1.8T 0 part /music
sda 8:16 0 232.9G 0 disk
tqsda1 8:17 0 2.3G 0 part /boot
mqsd22 8:18 0 230.6G 0 part /

When I try to boot the drive, it says waiting for PARTUUID=9559d5f6-fdbf-44da-8383-8f88d216b3ad and finally reports it can't find the partition and drops into an emergency shell.

Since the drive boots just fine as a USB device, I'm thinking it is perhaps hardware related. I am using an older Asus board with the most recent BIOS installed.

Scimmia · 2024-07-16 03:26:48

Boot the fallback initramfs

jsalk · 2024-07-16 13:56:16

Scimmia wrote:

Boot the fallback initramfs

Would I just modify the arch.conf to point to the fallback initramfs?

seth · 2024-07-16 14:06:39

Yes. If that doesn't work, try to add "rootwait" to the kernel parameters and in doubt reference the device by UUID or device name (/dev/sda2, which is usually not oa good idea at all but maybe gets us along)

Head_on_a_Stick · 2024-07-16 18:47:26

If the fallback works then you need to regenerate the initramfs to include the modules for your new hardware:

# mkinitcpio -P

jsalk · 2024-07-16 21:50:37

OK. I changed all the mentions of UUID and/or PARTUUID in arch.conf and fstab to /dev/sda1 , /dev/sda2 and /dev/sdb1 and it now boots up fine. I know this is not the ideal way of doing it, but at least it works.

I can only speculate on this, but perhaps the BOIS can't handle UUDI and PARTUUID and can only address the /dev/#. Does this seem a reasonable assumption?

Head_on_a_Stick · 2024-07-17 05:48:02

jsalk wrote:

I changed all the mentions of UUID and/or PARTUUID in arch.conf and fstab to /dev/sda1 , /dev/sda2 and /dev/sdb1

That is not reliable. The block device identifiers can change from one boot to the next.

Replace the PARTUUIDs and regenerate the initramfs.

Please don't ignore suggestions or questions from people trying to help, it is grossly disrespectful and discourages further assistance.

seth · 2024-07-17 06:03:53

I can only speculate on this, but perhaps the BOIS can't handle UUDI and PARTUUID and can only address the /dev/#. Does this seem a reasonable assumption?

No. But the hardware shows up in time.
The most likely scenarios are
1. you screwed up the numbers
2. some GPT issue around the PARTUUID (hence the suggestion to use UUIDs)

As hinted before and stressed by HoaS, using the device nodes isn't a good idea at all - the purpose was to figure whether there's any issue w/ the device drivers or the HW actually being late during the boot and -ideally- allow you to boot the desired system configuration so we can get the data from there.

If referencing by UUID and regenerating the initramfs doesn't work:

fdisk -l /dev/sda
lsblk -f
sudo lsinitcpio /boot/initramfs-linux-lts.img | grep -iE '(modules|blk)'

Post the output of that verbatim and in code tags, in doubt pipe it into 0x0.st

… | curl -F 'file=@-' 0x0.st

jsalk · 2024-07-17 13:11:55

No disrespect intended. I was merely reporting the results I was able to obtain.

I modified the arch.conf and fstab files using UUID for all the drives. I then ran mkinitcpio -P. All works fine now.

Thanks for all the help. Much appreciated!

Arch Linux

#1 2024-07-15 01:31:10

failed to mount PARTUUID on real root [SOLVED]

#2 2024-07-15 01:35:54

Re: failed to mount PARTUUID on real root [SOLVED]

#3 2024-07-15 17:39:13

Re: failed to mount PARTUUID on real root [SOLVED]

#4 2024-07-15 18:05:36

Re: failed to mount PARTUUID on real root [SOLVED]

#5 2024-07-15 19:03:05

Re: failed to mount PARTUUID on real root [SOLVED]

#6 2024-07-15 20:06:43

Re: failed to mount PARTUUID on real root [SOLVED]

#7 2024-07-15 20:57:33

Re: failed to mount PARTUUID on real root [SOLVED]

#8 2024-07-15 22:02:31

Re: failed to mount PARTUUID on real root [SOLVED]

#9 2024-07-16 03:26:48

Re: failed to mount PARTUUID on real root [SOLVED]

#10 2024-07-16 13:56:16

Re: failed to mount PARTUUID on real root [SOLVED]

#11 2024-07-16 14:06:39

Re: failed to mount PARTUUID on real root [SOLVED]

#12 2024-07-16 18:47:26

Re: failed to mount PARTUUID on real root [SOLVED]

#13 2024-07-16 21:50:37

Re: failed to mount PARTUUID on real root [SOLVED]

#14 2024-07-17 05:48:02

Re: failed to mount PARTUUID on real root [SOLVED]

#15 2024-07-17 06:03:53

Re: failed to mount PARTUUID on real root [SOLVED]

#16 2024-07-17 13:11:55

Re: failed to mount PARTUUID on real root [SOLVED]

Board footer