You are not logged in.

Pages: 1

#1 2024-01-28 19:10:28

dootfs
Member
Registered: 2024-01-27
Posts: 18

Failed to mount device on real root [Solved]

Edit: This issue was entirely the result of human error.

Fresh install on a new Dell Inspiron laptop with Windows 10 pre-installed. In order to keep the payware for compatibility reasons, a dual-boot partition configuration is set up, with separate partitions for root, home, boot, and efi. Partitions are formatted in ext4 except for the ESP, which was formatted FAT32 from the factory. Using a bootable .iso image, I was able to mount (in order) all block devices and build Arch onto the root mount point. Pacstrap builds without error, and the bootctl readout looks good {How to export log files from the live environment?}.

On reboot, the bootloader select page displays the boot entries and starts. Initramfs begins, but fails at filesystem mount:

…
:: running hook [keymap]
:: Loading keymap … done. 
ERROR: device ‘ ‘ not found. Skipping fsck.
:: mounting ‘ ‘ on real root
mount: /new_root: no valid filesystem type specified. 
ERROR: Failed to mount ‘ ‘ on real root. 
You are now being dropped into an emergency shell.
sh: can’t access tty; job control turned off
[rootfs~]#

Manual mount appears to work, if I run 

 mount /dev/nvme0n1px /new_root

but this doesn’t stick on reboot.

I have tried to designate the boot partition by uuid, partuuid, label, etc. in the arch.conf file. None seem to work, throw the same error.

Now, I don’t know what I’m missing here, but my understanding is that the bootloader is not picking up the correct partition and filesystem to execute boot.

Does it make better sense to compile a UKI?

Last edited by dootfs (2024-03-05 04:43:11)

Offline

#2 2024-01-28 19:25:36

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,732
Website

Re: Failed to mount device on real root [Solved]

dootfs wrote:

How to export log files from the live environment?

https://wiki.archlinux.org/title/List_o … ted_client

dootfs wrote:

I have tried to designate the boot partition by uuid, partuuid, label, etc. in the arch.conf file

Please share your attempts. Vague descriptions don't really help us spot any errors you may have made. Post the full configuration file.

Also include the output of

blkid

The problem is probably caused by passing the boot partition identifiers on the options line; you should be directing it to the root partition instead. Unless that was a typo.

Are you infected with Wetiko?

Offline

#3 2024-02-01 01:27:07

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Okay, thanks Head_on_a_Stick. I’ll post the outputs of each step in the install process. Maybe we can spot the error.

From the top; existing partitions will be kept in place, and reformatted via gdisk ‘zap’ function - except for the ESP partition.

Mount each partition to /mnt starting with the designated root, making directories for each branch of /root.

lsblk -f

 
NAME        FSTYPE    FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs  4.0                                                                     0   100% /run/archiso/airootfs
sda         iso9660   Joliet Extension ARCH_202401 2024-01-01-16-44-54-00                              
├─sda1      iso9660   Joliet Extension ARCH_202401 2024-01-01-16-44-54-00                              
└─sda2      vfat      FAT16            ARCHISO_EFI C49D-E756                                           
nvme0n1                                                                                                
├─nvme0n1p1 vfat      FAT32            ESP         FC89-FB2A                              54.8M    62% /mnt/efi
├─nvme0n1p2                                                                                            
├─nvme0n1p3 BitLocker 2                                                                                
├─nvme0n1p4 ext4      1.0                          b334903f-ef84-4c56-8da3-0a4b20f468e5  185.8G     0% /mnt/home
├─nvme0n1p5 ext4      1.0                          7c1650a3-e4c7-4efd-8bcb-6c1d344a247f   27.8G     0% /mnt
├─nvme0n1p6 ntfs                       DELLSUPPORT C230F34830F34249                                    
├─nvme0n1p7 swap      1                            f253c0e9-de56-428d-9088-7dc3ef6c9074                
└─nvme0n1p8 ext4      1.0                          2aa9ed0f-07d1-4384-bf7e-ab7aa707ca63    1.6G     8% /mnt/boot

Looks good.

Now to update pacman keys and run pacstrap to install base packages, the linux kernel, and linux firmware. Long output, but the build goes off without a hitch.

Now, to generate the filesystem table:

genfstab -U /mnt >> /mnt/etc/fstab

nano /mnt/etc/fstab

# /dev/nvme0n1p5
UUID=7c1650a3-e4c7-4efd-8bcb-6c1d344a247f	/         	ext4      	rw,relatime	0 1

# /dev/nvme0n1p4
UUID=b334903f-ef84-4c56-8da3-0a4b20f468e5	/home     	ext4      	rw,relatime	0 2

# /dev/nvme0n1p8
UUID=2aa9ed0f-07d1-4384-bf7e-ab7aa707ca63	/boot     	ext4      	rw,relatime	0 2

# /dev/nvme0n1p1 LABEL=ESP
UUID=FC89-FB2A      				/efi      	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

For some reason, the fstab file was written without the usual column labels. Anyway, looks good.

Now to chroot into the new system. Configure system clock, localization, hostname, etc. Because mkinitcpio was run as part of the pacstrap installation process, that step is skipped.

nano /boot/loader/entries/arch.conf

#Modified for install 
## Please edit the paths and kernel parameters according to your system.

title   Arch Linux
linux   /vmlinuz-linux
initrd	/amd-ucode.img
initrd  /initramfs-linux.img
options root=UUID=7c1650a3-e4c7-4efd-8bcb-6c1d344a247f rw

Note that the arch.conf root UUID matches the relevant blkid entry.

blkid

/dev/nvme0n1p7: UUID="f253c0e9-de56-428d-9088-7dc3ef6c9074" TYPE="swap" PARTLABEL="Linux swap" PARTUUID="c7f9e686-2263-4ab0-8bfd-97151936fb4d"
/dev/nvme0n1p5: UUID="7c1650a3-e4c7-4efd-8bcb-6c1d344a247f" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux x86-64 root (/)" PARTUUID="0becbc71-db1e-42b7-9205-f27169f51bd7"
/dev/nvme0n1p3: TYPE="BitLocker" PARTLABEL="Basic data partition" PARTUUID="2f70dccc-a372-4058-bdf1-89a24e41a4a4"
/dev/nvme0n1p1: LABEL="ESP" UUID="FC89-FB2A" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d823a740-d06b-4a8d-8f82-71ee6d1b67df"
/dev/nvme0n1p8: UUID="2aa9ed0f-07d1-4384-bf7e-ab7aa707ca63" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="XBOOTLDR partition" PARTUUID="4cedfbcb-e9cc-4e10-9262-f459a43c86f0"
/dev/nvme0n1p6: LABEL="DELLSUPPORT" BLOCK_SIZE="512" UUID="C230F34830F34249" TYPE="ntfs" PARTUUID="79107c66-e7cf-407e-81b6-dc230ffbf23f"
/dev/nvme0n1p4: UUID="b334903f-ef84-4c56-8da3-0a4b20f468e5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux /home" PARTUUID="32e9cea0-c1ab-4aa5-94dc-b07f5514ca37"
/dev/loop0: BLOCK_SIZE="1048576" TYPE="squashfs"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="C49D-E756" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="233ea223-02"
/dev/sda1: BLOCK_SIZE="2048" UUID="2024-01-01-16-44-54-00" LABEL="ARCH_202401" TYPE="iso9660" PARTUUID="233ea223-01"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="17eeb695-3772-46ad-b270-546b77db7aee"

Then bootctl check.

bootctl 

[0mSystem:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (unknown)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

[0mCurrent Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

[0mRandom Seed:
 System Token: set
       Exists: yes

[0mAvailable Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.3-1-arch)
               └─/EFI/BOOT/bootx64.efi (systemd-boot 255.3-1-arch)

[0mBoot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Windows Boot Manager
           ID: 0x0005
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

[0mBoot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/4cedfbcb-e9cc-4e10-9262-f459a43c86f0)
        token: arch

[0mDefault Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux
           id: arch.conf
       source: /boot//loader/entries/arch.conf
        linux: /boot//vmlinuz-linux
       initrd: /boot//amd-ucode.img
               /boot//initramfs-linux.img
      options: root=UUID=7c1650a3-e4c7-4efd-8bcb-6c1d344a247f rw

Looks fine; exit and reboot. Same error as last time.

It may be that I’m only making things worse by running gdisk to reformat the partition. Because the arch.conf file retains the previous configuration, I suspect that the ‘zap’ function doesn’t zero out the partition, but leaves the data intact, and that the rebuilt kernel picks up old files.

I will try again after repartitioning.

Offline

#4 2024-02-01 08:10:56

d.ALT
Member
Registered: 2019-05-10
Posts: 920

Re: Failed to mount device on real root [Solved]

Could be related to this?


Did you try if rEFInd capable of good-booting?



dootfs wrote:

Does it make better sense to compile a UKI?

Then your separated $BOOT mountpoint "would" became redundant at this point... At this point (you'd need it in order to eliminate an intermediate BootLoader?) I'd rather suggest direct EFISTUB booting.
You don't need SecureBoot, right? I don't see too much sense into getting through the extra steps of (re)generating UKIs and chainloading 'em via a BootLoader. No?

<49,17,III,I>    Fama di loro il mondo esser non lassa;
<50,17,III,I>    misericordia e giustizia li sdegna:
<51,17,III,I>    non ragioniam di lor, ma guarda e passa.

Offline

#5 2024-02-01 16:40:03

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,732
Website

Re: Failed to mount device on real root [Solved]

dootfs wrote:

existing partitions will be kept in place, and reformatted via gdisk ‘zap’ function

gdisk cannot "reformat" anything, the zap function just deletes the partition table entries, the filesystem data is untouched. If you want to reformat partitions use the appropriate filesystem tools instead (ie, mkfs.whatever).

dootfs wrote:

nano /boot/loader/entries/arch.conf

Did you install the ext4 EFI drivers to the EFI system partition so that systemd-boot can read the XBOOTLDR partition?

EDIT: unified kernel images are EFI_STUB capable but they only make sense if SecureBoot is enabled. Not much point using them otherwise.

Last edited by Head_on_a_Stick (2024-02-01 17:18:58)

Are you infected with Wetiko?

Offline

#6 2024-02-01 22:05:42

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

d.ALT wrote:

Could be related to this?

That is similar to this issue, but I don’t see the same error message.

Did you try if rEFInd capable of good-booting?

I’ve only tried and failed with systemd-boot


dootfs wrote:

Does it make better sense to compile a UKI?

Then your separated $BOOT mountpoint "would" became redundant at this point... At this point (you'd need it in order to eliminate an intermediate BootLoader?) I'd rather suggest direct EFISTUB booting.
You don't need SecureBoot, right? I don't see too much sense into getting through the extra steps of (re)generating UKIs and chainloading 'em via a BootLoader. No?

Yeah, I don’t need SecureBoot. If and when I need to tighten security, then I’ll go through with it. At this point I’m trying to get up and running.

I guess my question is: exactly how must the /boot and /efi files be arranged so that systemd-boot can pick up the xboot_64.efi files and then run initramfs from boot? Or, would rEFInd do so automatically?

The thing is, I’ve fully reinstalled to clear up the previous problem, but I can’t test to replicate the original problem, because now I’m not seeing the bootloader page.

Thanks for your help so far.

Offline

#7 2024-02-02 23:13:09

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Thanks for the help so far. It’s kind of absurd how long I’ve been trying to get this system up and running, failing repeatedly. But maybe with a little help it’ll work.

On reinstalling with a fresh partition, the problems associated with overwriting the same address space were solved. The problem now is that I do not see Arch Linux as an option in the bootloader.

That is, the relevant configuration files [/efi/loader/loader.conf && /boot/loader/entries/arch.conf] that persisted when failing to make a fresh reinstall are gone. Rewriting those two .config files is somehow not sufficient to get the boot loader running. I’m assuming something is out of place. The relevant contents of /efi && /boot are as follows:

tree /efi/loader

/efi/loader
├── entries
├── entries.srel
├── loader.conf
└── random-seed

2 directories, 3 files

nano /efi/loader/loader.conf

default /arch.conf
timeout 10
console-mode max
editor no

tree /boot

 
/boot
├── EFI
│   └── Linux
├── amd-ucode.img
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│   ├── entries
│   │   └── arch.conf
│   └── entries.srel
├── lost+found
└── vmlinuz-linux

6 directories, 6 files

nano /boot/loader/entries/arch.conf

title Arch Linux
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options root=UUID=XnotXtheXUUID rootfstype=ext4 rw add_efi_memmap

I had guessed that the issue was that the pointers were aimed wrong. However, if I set the absolute path of any of the arch.conf parameters - i.e. /boot/vmlinuz-linux instead of /vmlinuz-linux - the bootctl readout throws errors.

bootctl

[0mSystem:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (unknown)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

[0mCurrent Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

[0mRandom Seed:
 System Token: set
       Exists: yes

[0mAvailable Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.3-1-arch)
               └─/EFI/BOOT/bootx64.efi (systemd-boot 255.3-1-arch)

[0mBoot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/efi/boot/bootx64.efi

        Title: Windows Boot Manager
           ID: 0x0005
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

[0mBoot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/e9f179ab-dbb2-42ad-85da-d26c5ae66bc0)
        token: arch

[0mDefault Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux
           id: arch.conf
       source: /boot//loader/entries/arch.conf
        linux: /boot//vmlinuz-linux
       initrd: /boot//amd-ucode.img
               /boot//initramfs-linux.img
      options: root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a rootfstype=ext4 rw add_efi_memmap

As the bootctl setup looks fine, I can only guess what the problem might be. Did I put the /efi/loader.conf file in the wrong location? Should it be @ /efi/loader/loader.conf?

Anyway, I understand that a UKI file would streamline this whole setup. Even though I don’t need to use secureboot, I intend to go the UKI route if this issue persists.

Offline

#8 2024-02-03 00:01:01

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,771

Re: Failed to mount device on real root [Solved]

systemd-boot can't just read off of a /boot partition did you set this up as an XBOOTLDR and put the drivers for ext4 onto the ESP? The outputs look like "no". See https://wiki.archlinux.org/title/System … g_XBOOTLDR

I suggest you simplify this and make /boot  your ESP and setup things there if you want to use systemd-boot.

Offline

#9 2024-02-05 20:36:23

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Another try.

V1del wrote:

systemd-boot can't just read off of a /boot partition did you set this up as an XBOOTLDR and put the drivers for ext4 onto the ESP? The outputs look like "no". See https://wiki.archlinux.org/title/System … g_XBOOTLDR

I suggest you simplify this and make /boot  your ESP and setup things there if you want to use systemd-boot.

Ok, so the ESP requires a driver to convert from FAT to ext. The solution may be to reformat XBOOTLDR to FAT32.

Considering that systemd cannot read [tab] characters as spaces, I went in a checked the .conf files for regular spacing. It all looks fine, but I can’t tell if the bootctl readout is good to go; the first line - ‘Current Boot Loader’ - reads n/a.

[0mSystem:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (unknown)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

[0mCurrent Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

[0mRandom Seed:
 System Token: set
       Exists: yes

[0mAvailable Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.3-1-arch)
               └─/EFI/BOOT/bootx64.efi (systemd-boot 255.3-1-arch)

[0mBoot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Windows Boot Manager
           ID: 0x0005
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

        Title: Arch
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─efi/systemd/systemd-bootx64.efi

[0mBoot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/e9f179ab-dbb2-42ad-85da-d26c5ae66bc0)
        token: arch

[0mDefault Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux
           id: arch.conf
       source: /boot//loader/entries/arch.conf
        linux: /boot//vmlinuz-linux
       initrd: /boot//amd-ucode.img
               /boot//initramfs-linux.img
      options: root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a rw

To summarize:
ESP and XBOOTLDR are appropriately tagged and formatted to FAT32.
systemd-boot is able to read /efi/loader/loader.conf and /boot/loader/entries/arch.conf
bootctl install runs
mkinicpio -P runs

And, the bootmenu entry shows up!
The problem with the bootloader was that the /efi and /boot partitions were formatted differently.

The original problem comes up again, this time with the correct root UUID.
On boot, the following error throws the process:

ERROR: device ’UUID=XrootX’ not found. Skipping fsck.
: : mounting ‘UUID=XrootX’ on real root
mount: /new_root: can’t find UUID=XrootX.
ERROR: Failed to mount ‘UUID=XrootX’ on real root
You are now being dropped into an emergency shell.
sh: can’t access tty; job control turned off
[rootfs~]#

Maybe regenerate the fstab? Or simply drop in a UKI?

Offline

#10 2024-02-05 21:06:27

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,598

Re: Failed to mount device on real root [Solved]

What, exactly, is root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a supposed to be pointing to?

Edit: Also, get off of this UKI kick. They are more complicated, not simpler, and will not fix configuration issues.

Last edited by Scimmia (2024-02-06 00:47:54)

Offline

#11 2024-02-07 01:56:42

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Scimmia wrote:

What, exactly, is root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a supposed to be pointing to?

Edit: Also, get off of this UKI kick. They are more complicated, not simpler, and will not fix configuration issues.

Thanks for asking. The root=UUID=5c2e9… points to the device UUID that the root partition sits on. Once the initial ram sequence is complete and the kernel is running, then the root filesystem gets loaded into userspace.

I can confirm that the root=UUID=5c2e9… parameter matches the listed device UUID.

Fair enough about the UKI option. I didn’t see a cmdline.d directory when trying to build using ukify, so I didn’t pursue it. Though I saw there are signed UKI files hosted on some independent sites - it’d be a security risk.

Thanks for the input.

I’m still facing the same issue as originally posted - ERROR: Failed to mount device to /real_root

Offline

#12 2024-02-07 02:29:37

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,598

Re: Failed to mount device on real root [Solved]

And yet:

dootfs wrote:

lsblk -f

 
NAME        FSTYPE    FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs  4.0                                                                     0   100% /run/archiso/airootfs
sda         iso9660   Joliet Extension ARCH_202401 2024-01-01-16-44-54-00                              
├─sda1      iso9660   Joliet Extension ARCH_202401 2024-01-01-16-44-54-00                              
└─sda2      vfat      FAT16            ARCHISO_EFI C49D-E756                                           
nvme0n1                                                                                                
├─nvme0n1p1 vfat      FAT32            ESP         FC89-FB2A                              54.8M    62% /mnt/efi
├─nvme0n1p2                                                                                            
├─nvme0n1p3 BitLocker 2                                                                                
├─nvme0n1p4 ext4      1.0                          b334903f-ef84-4c56-8da3-0a4b20f468e5  185.8G     0% /mnt/home
├─nvme0n1p5 ext4      1.0                          7c1650a3-e4c7-4efd-8bcb-6c1d344a247f   27.8G     0% /mnt
├─nvme0n1p6 ntfs                       DELLSUPPORT C230F34830F34249                                    
├─nvme0n1p7 swap      1                            f253c0e9-de56-428d-9088-7dc3ef6c9074                
└─nvme0n1p8 ext4      1.0                          2aa9ed0f-07d1-4384-bf7e-ab7aa707ca63    1.6G     8% /mnt/boot

It's not there. If this information is no longer accurate, post the new output.

Offline

#13 2024-02-08 21:10:23

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Right, new UUIDs were generated after repartition.

The system is configured for dual boot with /efi and /boot filesystems mounted on different partitions on the same drive using the XBOOTLDR partition type. XBOOTLDR and the ESP are formatted FAT32. /home and /root are formatted ext4. pacstrap built without error, and configuration is as follows:

tree /efi/loader

/efi/loader
├── entries
├── entries.srel
├── loader.conf
└── random-seed

2 directories, 3 files

nano /efi/loader/loader.conf

default /boot/loader/entries/arch.conf
timeout 3
console-mode max
editor no

tree /boot

/boot
├── EFI
│   └── Linux
├── amd-ucode.img
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│   ├── entries
│   │   └── arch.conf
│   └── entries.srel
├── lost+found
└── vmlinuz-linux

6 directories, 6 files

nano /boot/loader/entries/arch.conf

title Arch Linux
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a rw

bootctl

[0mSystem:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (unknown)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

[0mCurrent Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

[0mRandom Seed:
 System Token: set
       Exists: yes

[0mAvailable Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.3-1-arch)
               └─/EFI/BOOT/bootx64.efi (systemd-boot 255.3-1-arch)

[0mBoot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Windows Boot Manager
           ID: 0x0005
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/d823a740-d06b-4a8d-8f82-71ee6d1b67df
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

[0mBoot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/e9f179ab-dbb2-42ad-85da-d26c5ae66bc0)
        token: arch

[0mDefault Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux
           id: arch.conf
       source: /boot//loader/entries/arch.conf
        linux: /boot//vmlinuz-linux
       initrd: /boot//amd-ucode.img
               /boot//initramfs-linux.img
      options: root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a rw

lsblk #run from .iso image

NAME        FSTYPE    FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs  4.0                                                                     0   100% /run/archiso/airootfs
sda         iso9660   Joliet Extension ARCH_202402 2024-02-01-12-07-52-00                              
├─sda1      iso9660   Joliet Extension ARCH_202402 2024-02-01-12-07-52-00                              
└─sda2      vfat      FAT16            ARCHISO_EFI 9C7A-9A67                                           
nvme0n1                                                                                                
├─nvme0n1p1 vfat      FAT32            ESP         FC89-FB2A                              54.8M    62% /mnt/efi
├─nvme0n1p2                                                                                            
├─nvme0n1p3 BitLocker 2                                                                                
├─nvme0n1p4 ntfs                       DELLSUPPORT C230F34830F34249                                    
├─nvme0n1p5 ext4      1.0                          5c2e9cc7-6bf4-4883-aa72-d413f69a60ba   26.1G     6% /mnt
├─nvme0n1p6 ext4      1.0                          30f973b1-b460-45ee-b93a-6ebb88bb9dbd  187.7G     0% /mnt/home
├─nvme0n1p7 vfat      FAT32                        762E-0CB9                               1.8G     7% /mnt/boot
└─nvme0n1p8 swap      1                            ff81af25-7963-42a8-8470-574a49ea00ab                [SWAP]

error @ runtime

…
ERROR: device ’UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60ba’ not found. Skipping fsck.
: : mounting ‘UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60ba’ on real root
mount: /new_root: can’t find UUID= 5c2e9cc7-6bf4-4883-aa72-d413f69a60ba.
ERROR: Failed to mount ‘UUID= 5c2e9cc7-6bf4-4883-aa72-d413f69a60ba’ on real root
You are now being dropped into an emergency shell.
sh: can’t access tty; job control turned off
[rootfs~]#

Offline

#14 2024-02-09 02:18:45

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,598

Re: Failed to mount device on real root [Solved]

Can you boot the fallback initramfs?

Offline

#15 2024-02-09 20:11:53

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Went back and changed the /boot/loader/entries/arch.conf file to load the fallback image. No dice, same ‘device not found, failed to mount /real_root’ error.

Unless there’s a different way to queue the fallback initramfs, I’d consider that a fail.

curl is acting up on me, so I can’t print out the output of fdisk -l, but I can confirm that each partition has the correct type ID. systemd-boot is apparently able to detect the XBOOTLDR partition, but for some reason cannot find the disk volume that /root is mounted on.

Again, all partitions have the correct type ID. /root fails to mount.

Offline

#16 2024-02-10 13:03:24

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,598

Re: Failed to mount device on real root [Solved]

What's the HOOKS array in /etc/mkinitcpio.conf look like?

Offline

#17 2024-02-10 17:32:30

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

cat /etc/mkinitcpio.d/linux.conf

 # mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"
ALL_microcode=(/boot/*-ucode.img)

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"

The uncommented HOOKS line in /etc/mkinicpio.conf

HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

Notable that the error at runtime reads “ERROR: device X not found. Skipping fsck.”

Offline

#18 2024-02-10 18:01:22

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,598

Re: Failed to mount device on real root [Solved]

That looks fine. At that prompt in the initramfs, can you post the output of

uname -r
ls /lib/modules/
blkid
ls -l /dev/disk/by-uuid

That last one is about the UUIDs and where they're symlinked to, don't need permissions, times, etc. All of this MUST be at that prompt, not from an install disk or anything.

Offline

#19 2024-02-11 00:24:46

dootfs
Member
Registered: 2024-01-27
Posts: 18

Re: Failed to mount device on real root [Solved]

Ok.

uname -r

 6.7.3-arch1-2

ls /lib/modules/

 6.7.3-arch1-2

blkid #excuse the typos

/dev/nvme0n1p7: UUID="762E-OCB9" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="XBOOTLDR" PARTUUID="e9f179ab-dbb2-42ad-85da-d26c5ae66bcO"
/dev/nvme0n1p5: UUID="5c2e9cc7-6bf4-4883-aa72-d413f69a60ba" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7a96dabb-c40d-40d0-b871-7fde82a0a512"
/dev/nvme0n1p3: TYPE="BitLocker” PARTLABEL="Basic data partition" PARTUUID="2f70dccc-a372-4058-bdf1-89a24e41a4a4"
/dev/nvme0n1p1: LABEL ="ESP" UUID="FC89-FB2A" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL=“EFI system partition" PARTUUID="a823a740-d06b-4a8d-8f82-71ec6d1b67df”
/dev/nume0n1p8: UUID="ff81af25-7963-42a8-8470-574a49ea00ab' TYPE="swap" PARTUUID="c11048e2-3cab-4fdf-a391-a42a9c326539"
/dev/nume0n1p6: UUID= "30f973b1-b460-45ee-b93a-6ebb88bb9dbd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b96497f4-4da9-4ac0-842e-e6f272eb4d7b"
/dev/nvme0n1p4: LABEL="DELLSUPPORT" BLOCK_SIZE="512" UUID="C230F34830F34249" TYPE="ntfs" FARTUUID="79107c66-e7cf-407e-81b6-dc230ffbf235"
/dev/nume0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID='17eeb695-3772-46ad-6270-546677db7ace"

ls -l /dev/disk/by-uuid #excuse the typos

lrwxrwxrwx	1 0		0		15 Feb 10 23:30     30f973b1-6460-45ee-693a-бе88bb94bd -> ../../nvme0n1p6

lrwxrwxrwx      1 0		0		15 Feb 10 23:30      5c2e9cc7-6bf4-4883-aa72-d413f69a60ba -> ../../nvme0n1p5

lrwxrwxrwx	1 0		0		15 Feb 10 23:30	762E-0CB9 -> ../../nvme0n1p7

lrwxrwxrwx	1 0		0		15 Feb 10 23:30	C230F34830F34249 -> ../../nvme0n1p4

lrwxrwxrwx	1 0		0		15 Feb 10 23:30	FC89-FBZA -> ../../nvme0n1p1

lrwxrwxrwx	1 0		0		15 Feb 10 23:30	ff81af25-7963-42a8-8470-574a49ea00ab -> ../../nvme0n1p8

Looking closely at the original error message, I think I’ve spotted the problem! The device name in the error message and the device name in /dev/disk/by-uuid are different by a single character?!

The error reads:

…
ERROR: device ’UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a’ not found. Skipping fsck.
: : mounting ‘UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a’ on real root
mount: /new_root: can’t find UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a.
ERROR: Failed to mount ‘UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a’ on real root
You are now being dropped into an emergency shell.
sh: can’t access tty; job control turned off
[rootfs~]#

I had actually copied that error by hand, previously, and had inserted what was the correct UUID without noticing the discrepancy.

I went back into the iso image to edit the /boot/loader/entries/arch.conf file and insert the correct root device UUID. 

title Arch Linux
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60a rw

Changed to:

title Arch Linux
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options root=UUID=5c2e9cc7-6bf4-4883-aa72-d413f69a60ba rw

Notice the second-to-last character difference? What a single difference makes.

Ok. Now to boot.

And presto! It works!

Offline

Pages: 1

Board footer

Powered by FluxBB