Debian fails to boot on NVMe M.2 disk after UEFI install
Debian fails to boot on NVMe M.2 disk after UEFI install
The summary of this is that after installing Debian and trying to reboot into the installed system I'm getting "Gave up waiting for root file system device" and "ALERT! /dev/mapper/mypc-vg-root does not exist. Dropping to a shell!". I am then left at an "(initramfs)" prompt. More detail below:
I'm in the process of performing a complete hardware upgrade on a desktop system I initially built quite some time ago. Initially, I upgraded the MoBo, processor and memory, but kept the original SSD and HDD, which required me to enable CSM mode in UEFI/Bios. After running into some configuration issues with the old Debian install, I decided to buy a brand new M.2 drive (Samsung 990 Pro) and perform a fresh install off a Debian 12 install CD I burned. Initially, I left the old SSD and HDD connected the computer when I performed the install, only to realize later that a swap partition had been installed on one of them, and that I had left CSM mode enabled during that install. I decided to try again, so I unplugged the power and SATA cables from the SSD and HDD, and set about doing the install over again.
Now, it appears that with CSM mode off, the installer fails to detect the M.2 drive at all. I am able to perform the install in UEFI mode (I think) with CSM mode enabled, but then on reboot I am dumped to the aforementioned initramfs prompt. I haven't tried doing the install in legacy mode yet, as I would rather use full UEFI mode instead, if at all possible. Is there something I can do so that the M.2 will be detected by the installer with CSM disabled? At this point, I'm not sure if the issue is that this particular Samsung 990 Pro drive is not yet fully supported by a Linux driver, or if I somehow messed things up by doing the install with CSM enabled.
Any pointers would be appreciated.
I'm in the process of performing a complete hardware upgrade on a desktop system I initially built quite some time ago. Initially, I upgraded the MoBo, processor and memory, but kept the original SSD and HDD, which required me to enable CSM mode in UEFI/Bios. After running into some configuration issues with the old Debian install, I decided to buy a brand new M.2 drive (Samsung 990 Pro) and perform a fresh install off a Debian 12 install CD I burned. Initially, I left the old SSD and HDD connected the computer when I performed the install, only to realize later that a swap partition had been installed on one of them, and that I had left CSM mode enabled during that install. I decided to try again, so I unplugged the power and SATA cables from the SSD and HDD, and set about doing the install over again.
Now, it appears that with CSM mode off, the installer fails to detect the M.2 drive at all. I am able to perform the install in UEFI mode (I think) with CSM mode enabled, but then on reboot I am dumped to the aforementioned initramfs prompt. I haven't tried doing the install in legacy mode yet, as I would rather use full UEFI mode instead, if at all possible. Is there something I can do so that the M.2 will be detected by the installer with CSM disabled? At this point, I'm not sure if the issue is that this particular Samsung 990 Pro drive is not yet fully supported by a Linux driver, or if I somehow messed things up by doing the install with CSM enabled.
Any pointers would be appreciated.
- ruwolf
- Posts: 957
- Joined: 2008-02-18 05:04
- Location: Banovce nad Bebravou
- Has thanked: 96 times
- Been thanked: 76 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
The error message says, that there is probably problem with LVM.
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
If LVM is on NVME, and NVME can't be found, then neither can LVM. What messages do you see before "Gave up waiting"? When was "some time ago"? Where is the NVME installed? Are you sure your motherboard supports boot from NVME? Is the M.2 on the motherboard, or an adapter of some kind? "Some time ago" motherboards supported NVME, but BIOS and/or chipset didn't always.
- pbear
- Posts: 570
- Joined: 2023-08-27 15:05
- Location: San Francisco
- Has thanked: 2 times
- Been thanked: 93 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Sounds like you're using the standard installer. If so, consider downloading a live ISO. You will be able to run a much wider range of tests. And the ISO has both installers (standard and Calamares).
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
As as update, the installer started failing at random times during the install itself. When I switched to a terminal and checked dmesg, there were IO Errors and the disk would go into read-only mode. This seems to happen any time I try to install now. I also attempted a Fedora 40 install with their live CD, which also failed during install. It now sounds like a hardware issue to me. The M.2 SSD is brand new, so I'm waiting for a new PSU (the only component I haven't replaced in the computer) to arrive so I can test whether replacing it fixes the issue.
If that doesn't work, the only other things I can think of are that either the brand new SSD is somehow defective or I made a mistake while installing something. I'll update on whether the new PSU fixes the issue.
If that doesn't work, the only other things I can think of are that either the brand new SSD is somehow defective or I made a mistake while installing something. I'll update on whether the new PSU fixes the issue.
-
- Global Moderator
- Posts: 4342
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 127 times
- Been thanked: 584 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Hello,
The output will be in the log.txt file.
May you please report the output of the following command booting from a Debian Live ISO (root password required) ?
Code: Select all
su -l -c "apt update && apt install inxi"
script log.txt
inxi -Fxxxxz
exit
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
From live USB the output of this command will give to forum more info:
Code: Select all
sudo parted -l ; lsblk -f ; mokutil --sb-state ; inxi -Fxxxrz
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
-Fxxxxz isn't in the man page, where x is either x, xx or xxx. If you want more info, use -Faz:
Code: Select all
# inxi -Fxxxz | wc -ml
94 4859
# inxi -Fxxxxz | wc -ml
94 4870
> diff -u 3x 4x
--- 3x 2024-05-10 13:27:34.656233726 -0400
+++ 4x 2024-05-10 13:27:41.592268487 -0400
@@ -12,8 +12,8 @@
...
- Speed (MHz): avg: 1984 high: 3400 min/max: 800/3400 cores: 1: 800 2: 1036
- 3: 2702 4: 3400 bogomips: 27199
+ Speed (MHz): avg: 800 min/max: 800/3400 cores: 1: 800 2: 800 3: 800 4: 800
+ bogomips: 27199
...
- System Temperatures: cpu: 42.0 C mobo: N/A
+ System Temperatures: cpu: 38.0 C mobo: N/A
...
- Memory: total: 32 GiB note: est. available: 30.8 GiB used: 9.58 GiB (31.1%)
+ Memory: total: 32 GiB note: est. available: 30.8 GiB used: 9.56 GiB (31.1%)
...
# inxi -Faz | wc -ml
157 8234
#
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Is the suggestion to boot into the Debian Live image and run these commands from there? If so, is it possible to install packages on a live image and, if so, what is the password for running sudo? I found online that the default use is "user/live" but using "live" as the password for sudo doesn't work for me on the debian-live-12.5.0-amd64-gnome.iso live image. I also saw that just hitting enter at the password prompt is supposed to work, but that didn't work for me, either. Neither inxi nor parted seem to be available on the live image, out of the box. I do seem to see my M.2 drive under /dev, though, which is encouraging.
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Inxi is best run from any X session you can get to work without requiring disabling of KMS (done purposely by booting with nomodeset or equivalent appended to a bootloader's linu line). Since your problem is more general rather than the more common problem of X not working right, it should be fine to run it from anything you can get to boot, as long as it's not one of inxi's broken antiques found on older live media. Current inxi version 3.3.34 can be fetched directly from upstream from any type of live Linux boot, and thus available for use on that boot.
parted -l & lsblk -f can be run from whatever Linux you can make boot. About mokutil --sb-state: ???
If rescue activity includes chrooting, then the state of the installed system applies once in the chroot. New software can typically be installed, and updates installed, from within a properly working chroot.
Whatever you're trying to boot for rescue purposes is best done in the same mode as the installed or to-be-installed system, meaning either Legacy/BIOS, or UEFI. UEFI related commands typically are unavailable unless booted in UEFI mode.
Live boot images have differing purposes in mind. Those specifically intended with troubleshooting in mind, such as Knoppix and Ultimatebootcd, are more likely to have most or all of the needed tools ready to run.
What password may be required, if any, depends on the particular live image, and on some, on whether running a GUI session, or working only on a VT. The only Debian "live" I've ever booted is actually Knoppix, which is a Debian derivative and my goto live media for repair purposes.
parted -l & lsblk -f can be run from whatever Linux you can make boot. About mokutil --sb-state: ???
If rescue activity includes chrooting, then the state of the installed system applies once in the chroot. New software can typically be installed, and updates installed, from within a properly working chroot.
Whatever you're trying to boot for rescue purposes is best done in the same mode as the installed or to-be-installed system, meaning either Legacy/BIOS, or UEFI. UEFI related commands typically are unavailable unless booted in UEFI mode.
Live boot images have differing purposes in mind. Those specifically intended with troubleshooting in mind, such as Knoppix and Ultimatebootcd, are more likely to have most or all of the needed tools ready to run.
What password may be required, if any, depends on the particular live image, and on some, on whether running a GUI session, or working only on a VT. The only Debian "live" I've ever booted is actually Knoppix, which is a Debian derivative and my goto live media for repair purposes.
- pbear
- Posts: 570
- Joined: 2023-08-27 15:05
- Location: San Francisco
- Has thanked: 2 times
- Been thanked: 93 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
I use Debian live ISOs routinely and have never run into what you describe. Just now, confirmed inxi is installed out-of-the-box and sudo works without password (e.g., sudo nano ... ). Did you confirm the ISO's checksum?
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Apologies, you are correct. I was running the "su" command from a comment above and wasn't thinking that it is different than running a sudo command. I realized once I read your comment and took a second look.pbear wrote: 2024-05-13 02:39 I use Debian live ISOs routinely and have never run into what you describe. Just now, confirmed inxi is installed out-of-the-box and sudo works without password (e.g., sudo nano ... ). Did you confirm the ISO's checksum?
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Attaching the resulting log.txt file. Text coloring is on in the terminal, so the file isn't plain text. Let me know if that causes any issues and I will re-run without the highlighting.Aki wrote: 2024-05-10 16:50 Hello,May you please report the output of the following command booting from a Debian Live ISO (root password required) ?The output will be in the log.txt file.Code: Select all
su -l -c "apt update && apt install inxi" script log.txt inxi -Fxxxxz exit
- Attachments
-
log.txt
- (5.78 KiB) Downloaded 37 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Here is the output from that command.panpan wrote: 2024-05-10 16:54 From live USB the output of this command will give to forum more info:Code: Select all
sudo parted -l ; lsblk -f ; mokutil --sb-state ; inxi -Fxxxrz
- Attachments
-
log1.txt
- (7.91 KiB) Downloaded 39 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Output with -Faz, in case it's helpful.mrmazda wrote: 2024-05-10 17:33-Fxxxxz isn't in the man page, where x is either x, xx or xxx. If you want more info, use -Faz:Code: Select all
# inxi -Fxxxz | wc -ml 94 4859 # inxi -Fxxxxz | wc -ml 94 4870 > diff -u 3x 4x --- 3x 2024-05-10 13:27:34.656233726 -0400 +++ 4x 2024-05-10 13:27:41.592268487 -0400 @@ -12,8 +12,8 @@ ... - Speed (MHz): avg: 1984 high: 3400 min/max: 800/3400 cores: 1: 800 2: 1036 - 3: 2702 4: 3400 bogomips: 27199 + Speed (MHz): avg: 800 min/max: 800/3400 cores: 1: 800 2: 800 3: 800 4: 800 + bogomips: 27199 ... - System Temperatures: cpu: 42.0 C mobo: N/A + System Temperatures: cpu: 38.0 C mobo: N/A ... - Memory: total: 32 GiB note: est. available: 30.8 GiB used: 9.58 GiB (31.1%) + Memory: total: 32 GiB note: est. available: 30.8 GiB used: 9.56 GiB (31.1%) ... # inxi -Faz | wc -ml 157 8234 #
- Attachments
-
log2.txt
- (8.36 KiB) Downloaded 35 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
What you attached is not a plain text file, thus not useful as is. This is a common failure resulting from involving the script command. You may try again by redirecting inxi output to a file, then attaching that file. e.g.
Code: Select all
inxi -Faz > attachmentfile.txt
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
This works on the log file:
and makes it quite readable.
Code: Select all
cat log2.txt | more
- ruwolf
- Posts: 957
- Joined: 2008-02-18 05:04
- Location: Banovce nad Bebravou
- Has thanked: 96 times
- Been thanked: 76 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
You can do it by:NorthEast wrote: 2024-05-14 09:46 This works on the log file:and makes it quite readable.Code: Select all
cat log2.txt | more
Code: Select all
less -r log2.txt
- fabien
- Forum Helper
- Posts: 1158
- Joined: 2019-12-03 12:51
- Location: Anarres (Toulouse, France actually)
- Has thanked: 101 times
- Been thanked: 265 times
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
@Aki provided us with [Tips] How to remove control characters from terminal recording (i.e. by script command)mrmazda wrote: 2024-05-14 02:43What you attached is not a plain text file, thus not useful as is. This is a common failure resulting from involving the script command. You may try again by redirecting inxi output to a file, then attaching that file. e.g.Inxi is intelligently designed to write only plain text when redirection is involved.Code: Select all
inxi -Faz > attachmentfile.txt
I agree that a simple redirect is often sufficient, depending on what you want to achieve. Highlighted text also has its advantages (for human vision I mean).
But let's not forget the OP

There will be neither barrier nor walls, neither official nor guard, there will be no more desert and the entire world will become a garden. — Anacharsis Cloots
Re: Debian fails to boot on NVMe M.2 disk after UEFI install
Inxi's default rainbow effect isn't advantageous, but instead annoying, to some users. It can be disabled by adjusting its config file as I do:fabien wrote: 2024-05-14 12:00I agree that a simple redirect is often sufficient, depending on what you want to achieve. Highlighted text also has its advantages (for human vision I mean).
Code: Select all
> grep -i color /etc/inxi.conf
GLOBAL_COLOR_SCHEME=0
>
Code: Select all
# inxi -Mdpoaz
Machine:
Type: Desktop System: Gigabyte product: B250M-D3H v: N/A serial: N/A
Mobo: Gigabyte model: B250M-D3H-CF v: x.x serial: N/A
uuid: 031b021c-040d-0557-ad06-5d0700080009
UEFI-[Legacy]: American Megatrends v: F10 date: 12/14/2018
Drives:
Local Storage: total: raw: 1.94 TiB usable: 1.03 TiB
used: 795.14 GiB (75.0%)
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: ZTC model: PCIEG3-128G
size: 119.24 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: R0629A0 temp: 51.9 C
scheme: MBR
SMART: yes health: PASSED on: 4 hrs cycles: 526
read-units: 2,494,087 [1.27 TB] written-units: 1,669,622 [854 GB]
ID-2: /dev/sda maj-min: 8:0 vendor: Seagate model: ST1000NM0011
family: Constellation ES (SATA 6Gb/s) size: 931.51 GiB block-size:
physical: 512 B logical: 512 B sata: 3.0 speed: 6.0 Gb/s tech: HDD
rpm: 7202 serial: <filter> fw-rev: SN02 temp: 34 C scheme: GPT
SMART: yes state: enabled health: PASSED on: 1y 262d 2h cycles: 54
Pre-Fail: attribute: Spin_Retry_Count value: 100 worst: 100 threshold: 97
ID-3: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST1000DM003-1CH162
family: Barracuda 7200.14 (AF) size: 931.51 GiB block-size: physical: 4096 B
logical: 512 B sata: 3.1 speed: 6.0 Gb/s tech: HDD rpm: 7200
serial: <filter> fw-rev: CC49 temp: 33 C scheme: GPT
SMART: yes state: enabled health: PASSED on: 3y 38d 8h cycles: 74
read: 244.01 TiB written: 6.59 TiB Pre-Fail: attribute: Spin_Retry_Count
value: 100 worst: 100 threshold: 97
Optical-1: /dev/sr0 vendor: ASUS model: DRW-24B1ST j rev: 1.11
dev-links: cdrom,dvd
Features: speed: 125 multisession: yes audio: yes dvd: yes
rw: cd-r,cd-rw,dvd-r state: running
Partition:
ID-1: / raw-size: 17.58 GiB size: 17.27 GiB (98.25%) used: 4.79 GiB (27.7%)
fs: ext4 block-size: 4096 B dev: /dev/nvme0n1p10 maj-min: 259:10
ID-2: /disks/boot raw-size: 1.17 GiB size: 1.16 GiB (99.06%)
used: 694.5 MiB (58.4%) fs: ext2 block-size: 4096 B dev: /dev/nvme0n1p3
maj-min: 259:3
ID-3: /home raw-size: 70.31 GiB size: 69.7 GiB (99.14%)
used: 40.69 GiB (58.4%) fs: ext4 block-size: 1024 B dev: /dev/md3
maj-min: 9:3
ID-4: /isos raw-size: 625 GiB size: 619.88 GiB (99.18%)
used: 578.4 GiB (93.3%) fs: ext4 block-size: 4096 B dev: /dev/md5
maj-min: 9:5
ID-5: /pub raw-size: 207.03 GiB size: 205.31 GiB (99.17%)
used: 165.95 GiB (80.8%) fs: ext4 block-size: 1024 B dev: /dev/md4
maj-min: 9:4
ID-6: /<redact>/E raw-size: N/A size: 250.7 MiB
used: 208.2 MiB (83.1%) fs: cifs dev: /dev/E
ID-7: /<redact>/G raw-size: N/A size: 1.95 GiB used: 1.91 GiB (97.5%)
fs: cifs dev: /dev/G
ID-8: /<redact>/I raw-size: N/A size: 2.44 GiB used: 2.04 GiB (83.5%)
fs: cifs dev: /dev/I
ID-9: /<redact>/J raw-size: N/A size: 58.59 GiB
used: 44.23 GiB (75.5%) fs: cifs dev: /dev/J
ID-10: /srv raw-size: 7.81 GiB size: 7.71 GiB (98.74%)
used: 1.75 GiB (22.6%) fs: ext4 block-size: 1024 B dev: /dev/md2
maj-min: 9:2
ID-11: /usr/local raw-size: 3.91 GiB size: 3.84 GiB (98.31%)
used: 2.88 GiB (75.1%) fs: ext4 block-size: 1024 B dev: /dev/md1
maj-min: 9:1
Unmounted:
ID-1: /dev/nvme0n1p1 maj-min: 259:1 size: 251 MiB fs: vfat
ID-2: /dev/nvme0n1p11 maj-min: 259:11 size: 17.58 GiB fs: ext4
ID-3: /dev/nvme0n1p2 maj-min: 259:2 size: 2.34 GiB fs: hpfs
ID-4: /dev/nvme0n1p4 maj-min: 259:4 size: 1 KiB fs: N/A
ID-5: /dev/nvme0n1p5 maj-min: 259:5 size: 16.23 GiB fs: swap
ID-6: /dev/nvme0n1p6 maj-min: 259:6 size: 3.91 GiB fs: ext3
ID-7: /dev/nvme0n1p7 maj-min: 259:7 size: 17.58 GiB fs: ext4
ID-8: /dev/nvme0n1p8 maj-min: 259:8 size: 17.58 GiB fs: ext4
ID-9: /dev/nvme0n1p9 maj-min: 259:9 size: 17.58 GiB fs: ext4
ID-10: /dev/sda1 maj-min: 8:1 size: 400 MiB fs: N/A
ID-11: /dev/sda2 maj-min: 8:2 size: 320 MiB fs: N/A
ID-12: /dev/sda3 maj-min: 8:3 size: 320 MiB fs: N/A
ID-13: /dev/sda4 maj-min: 8:4 size: 8.01 GiB fs: N/A
ID-14: /dev/sdb1 maj-min: 8:17 size: 400 MiB fs: N/A
ID-15: /dev/sdb2 maj-min: 8:18 size: 320 MiB fs: N/A
ID-16: /dev/sdb3 maj-min: 8:19 size: 320 MiB fs: N/A
ID-17: /dev/sdb4 maj-min: 8:20 size: 8.01 GiB fs: N/A
#
Code: Select all
efibootmgr -v
parted -l
lsblk -f
cat /etc/fstab # (or wherever fstab may be temporarily mounted for troubleshooting)