System boot stops at loading initial ramdisk [SOLVED]

ralvez · 2026-01-05 21:44:35

Hi guys.

After rebooting my system it started as usual but it took a long time on "Loading initial ramdisk ..."

Then after awhile the errors:
[TIME] Time out waiting for device /dev/.6d150d- ....
[DEPEND] Dependency fail for initrd Root Device
[DEPEND] Dependency failed for /sysroot
[DEPEND] Dependency failed for Initrd Root File System
[DEPEND] Dependency failed for File System .6d150- ...

Thereafter, I'm put in emergency mode and I get a prompt to "press Enter to continue".
After I do that I get:

Reloading system manager configuration.
Starting initrd.target

A few seconds later the about sequence of errors repeats itself, therefore, I never get to access the system any further.

What I have tried:

Since accessing the system the "regular" way seems futile I decided to use my Arch installation USB to boot from it and access the NVME (SSD) then mount and take a look ... but as soon as I run "lsblk" I get to see the installed hard drives and my external hard drive but not my NVME.(??!!!)

To be honest, I'm not too sure what to think but I feel that the problem could be a damaged NVME and only the boot partition is accessible therefore the boot issue and the file system not found.

Does anyone have any ideas to approach this issue?

Thanks in advance.

Last edited by ralvez (2026-01-08 21:04:46)

-thc · 2026-01-06 06:30:03

Take a look at your UEFI/BIOS - is the NVMe controller still active and does the UEFI/BIOS recognize the NVMe drive?

ralvez · 2026-01-06 17:58:11

@ -thc,

Thanks for your suggestion.
Since the system boots normally and tries to load the linux kernel I suspect that UEFI/BIOS is all normal. I'll take a look anyway, as it does not hurt.
My concern is that, may be, the NVME is damaged and even tough it can see the boot sector that's all it can see and therefore the error about loading the file system and issues to load the console.

-thc · 2026-01-06 18:47:47

Since you mentioned "internal hard drives" (plural) and the external hard drive - your initial "/boot" and or "/efi" partition may be on any non-NVMe disk.
You didn't mention your partitioning scheme (GPT/MBR), boot mode (BIOS/UEFI) and the boot manager.

ralvez · 2026-01-06 19:24:23

@ -thc,
Fair point.
Yes, the NVME is the boot device.
I have it as follows:

/dev/nvme0n1p3 to /mnt
/dev/nvme0n1p1 to /mnt/efi
/dev/nvme0n1p5 to /mnt/home

and the secondary HDD and external drive are mounted via /etc/fstab on boot.

That's the reason I have the bad feeling I may be looking at a bad NVME. The boot record is found but nothing else.

It's not the worst case scenario since I have backups of everything ... but it's the inconvenience of the situation.

Any other thoughts?

ralvez · 2026-01-06 19:25:22

Oh! BTW the external HDD is mounted in /home

-thc · 2026-01-06 19:43:07

O.K. - that's confusing.

If you have a working EFI partition, there is no "boot record" involved. UEFI works in a completely different way.
If you are unsure, follow the Wiki's "Installation guide" about determining your boot mode.

Why are those partitions mounted under "/mnt" - is this the scenario from an USB boot? Didn't you say, that the NVMe is not visible?
Why are there two "home" partitions?

ralvez · 2026-01-06 20:22:57

OMG! That's funny. Instead of posting my config I posted the order to boot from the recovery USB.
My bad. Sorry about that.

I just looked at my backups info and this is the current setup:

- /dev/sda 465.8G /backups
- /dev/sdb 931.5G /mnt/eHDD

- /dev/nvme0n1p1 512M /efi
- /dev/nvme0n1p2 16G [SWAP] (Not needed if using an SDD)
- /dev/nvme0n1p3 140G /root
- /dev/nvme0n1p4 1K
- /dev/nvme0n1p5 xxxG /home (remaining space)

In this particular machine /home is NOT from a secondary HDD (which is what I usually do). < -- that was also incorrect

Last edited by ralvez (2026-01-06 20:30:54)

-thc · 2026-01-07 06:21:58

O.K. - that makes more sense.

From the USB boot please post the output of

cat /sys/firmware/efi/fw_platform_size

efibootmgr

mount /dev/nvme0n1p1 /mnt
ls /mnt

lsblk

ralvez · 2026-01-07 21:49:23

Hi thc,

the fw_platform_size is 64
efibootmgr reports:

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001,0002
Boot0000* GRUB hd(1, mbr [ mbr params here ])/EFI\GRUB\grubx64.efi
Boot0001* UEFI: Corsair Flash Voyager PciRoot(0x14)/USB(0.0)/USB(0.0)/CDROM
Boot0002* UEFI: Corsair Flash Voyager PciRoot(0x14)/USB(0.0)/USB(0.0)/HD(2,MBR,0X698D5A3C,0X1FA800,0X56800)0000424F

The attempt to mount /dev/nvme0n1p1 fails with "cant lookup blockdev" and lsblk shows SDA, SDB and SDC (the Coursair boot usb device) but clearly the NVNe is absent.

This is the part that makes me feel something may be wrong with the NVME unit.,

I just ordered an NVME container to pluck the NVME into it and see it is found when plugged to my laptop. If it is not detected then my NVME may be damaged.

-thc · 2026-01-08 05:51:22

O.K. - just for clearing up things - you didn't mention the fourth disk (sdc) before.

This disk (probably an older Corsair SATA SSD) is MBR formatted and carries another EFI partition (which is referenced and used by your EFI boot manager) and probably also the "boot" partition. This is your boot drive. The NVMe disk is (probably) your root drive.

seth · 2026-01-08 09:27:30

Boot the install iso and post the output of:

(lsblk -f; journalctl -b) | curl -F 'file=@-' 0x0.st

See whether your nvme shows up in "lsblk -f", try to mount the root partition of the installed system into /mnt

mount /dev/nvme0n1p3 /mnt

Then post a journal from there

journalctl -D /mnt/var/log/journal -b -1 | curl -F 'file=@-' 0x0.st

ralvez · 2026-01-08 18:42:27

@ thc,
The SDC is the archlinux install medium in my USB drive. That's the reason you see it when I run lsblk.

@seth,
Sure I'll give that a try and post. Thanks for your reply.

ralvez · 2026-01-08 19:49:09

Hi guys,

The requested file is at http://0x0.st/PH63.txt
running "lsblk -f" returns: sda, sdb (drives I have in the system) and sdc ( the installation medium). There is no reference to NVMe

There is indeed a reference to the NVMe in the PH63.txt file:

ahci 0000:00:17.0: version 3.0
Jan 08 19:11:52 archiso kernel: ahci 0000:00:17.0: Found 1 remapped NVMe devices.
Jan 08 19:11:52 archiso kernel: ahci 0000:00:17.0: Switch your BIOS from RAID to AHCI mode to use them.
Jan 08 19:11:52 archiso kernel: ahci 0000:00:17.0: controller can't do SNTF, turning off CAP_SNTF

the message seems to imply there is a misconfiguration in the BIOS although, I have not made any changes myself.

seth · 2026-01-08 20:00:30

BIOS update? Windows? Have you tried to make the suggested change?

ralvez · 2026-01-08 20:05:15

@ seth,
Well ... that the thing I do not get. My system is ONLY Linux. I do not use Windows at all since about 19 years back.
May be something is confusing the software analysis?

I just got an external NMVe enclosure and will pluck the NVMe into it and test to see if my other Linux box can read it.
Then I'll post again.

seth · 2026-01-08 20:27:42

https://wiki.archlinux.org/title/Fwupd ?
Did you try to change the BIOS to ahci mode?

ralvez · 2026-01-08 20:32:51

@seth,

I just finished testing if the NVMe unit is readable in the external NVMe enclosure and everything is OK. I can see the file system /etc/,boot my /home directory. So, the conclusion is that the NVMe integrity is OK.

I'll try to see what happens now if I implement the suggestion, although, I got a warning stating that if I change to use AHCI I may brick my current installation and would have to re-install the OS.

I hope it does not come to that

seth · 2026-01-08 20:44:26

I was under the impression your system currently *is* bricked - likely for this reason

ralvez · 2026-01-08 20:45:49

LOL. Yea ... it cannot get any worst. Can it?
Unless it catches fire upon reboot

ralvez · 2026-01-08 20:59:03

@seth and thc

Well ... what do you know?
I'm back in business!! Everything is OK after making the change.

The odd thing is that the way it was setup a some years back was with RAID on.
I wonder if this was something to do with a kernel upgrade that set in motion the weirdness we've been looking at

Thank you guys for your help.
Much appreciated.

I've been using Linux for 19+ years and about 15 of those with Arch.
I have to say, the community has NEVER let me down. I love my ArchLinux boxes.

Once again a big thank you to you both!!!

Arch Linux

#1 2026-01-05 21:44:35

System boot stops at loading initial ramdisk [SOLVED]

#2 2026-01-06 06:30:03

Re: System boot stops at loading initial ramdisk [SOLVED]

#3 2026-01-06 17:58:11

Re: System boot stops at loading initial ramdisk [SOLVED]

#4 2026-01-06 18:47:47

Re: System boot stops at loading initial ramdisk [SOLVED]

#5 2026-01-06 19:24:23

Re: System boot stops at loading initial ramdisk [SOLVED]

#6 2026-01-06 19:25:22

Re: System boot stops at loading initial ramdisk [SOLVED]

#7 2026-01-06 19:43:07

Re: System boot stops at loading initial ramdisk [SOLVED]

#8 2026-01-06 20:22:57

Re: System boot stops at loading initial ramdisk [SOLVED]

#9 2026-01-07 06:21:58

Re: System boot stops at loading initial ramdisk [SOLVED]

#10 2026-01-07 21:49:23

Re: System boot stops at loading initial ramdisk [SOLVED]

#11 2026-01-08 05:51:22

Re: System boot stops at loading initial ramdisk [SOLVED]

#12 2026-01-08 09:27:30

Re: System boot stops at loading initial ramdisk [SOLVED]

#13 2026-01-08 18:42:27

Re: System boot stops at loading initial ramdisk [SOLVED]

#14 2026-01-08 19:49:09

Re: System boot stops at loading initial ramdisk [SOLVED]

#15 2026-01-08 20:00:30

Re: System boot stops at loading initial ramdisk [SOLVED]

#16 2026-01-08 20:05:15

Re: System boot stops at loading initial ramdisk [SOLVED]

#17 2026-01-08 20:27:42

Re: System boot stops at loading initial ramdisk [SOLVED]

#18 2026-01-08 20:32:51

Re: System boot stops at loading initial ramdisk [SOLVED]

#19 2026-01-08 20:44:26

Re: System boot stops at loading initial ramdisk [SOLVED]

#20 2026-01-08 20:45:49

Re: System boot stops at loading initial ramdisk [SOLVED]

#21 2026-01-08 20:59:03

Re: System boot stops at loading initial ramdisk [SOLVED]

Board footer