Debian User Forums

Posted: **2024-05-08 02:42**

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.

Posted: **2024-05-08 23:47**

The error message says, that there is probably problem with LVM.

Posted: **2024-05-09 00:09**

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.

Posted: **2024-05-09 02:52**

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).

Posted: **2024-05-10 15:38**

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.

Posted: **2024-05-10 16:50**

Hello,

SirEdward wrote: 2024-05-10 15:38 [..] It now sounds like a hardware issue to me.[..]

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

The output will be in the log.txt file.

Posted: **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

Posted: **2024-05-10 17:33**

Aki wrote: 2024-05-10 16:50inxi -Fxxxxz[/code]

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

Posted: **2024-05-12 21:41**

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.

Posted: **2024-05-12 22:48**

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.

Posted: **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?

Posted: **2024-05-14 02:10**

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?

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.

Posted: **2024-05-14 02:16**

Aki wrote: 2024-05-10 16:50 Hello,
SirEdward wrote: 2024-05-10 15:38 [..] It now sounds like a hardware issue to me.[..]
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
The output will be in the log.txt file.

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.

Posted: **2024-05-14 02:20**

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

Here is the output from that command.

Posted: **2024-05-14 02:25**

mrmazda wrote: 2024-05-10 17:33

Aki wrote: 2024-05-10 16:50inxi -Fxxxxz[/code]

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

Output with -Faz, in case it's helpful.

Posted: **2024-05-14 02:43**

SirEdward wrote: 2024-05-14 02:25 Output with -Faz, in case it's helpful.

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

Inxi is intelligently designed to write only plain text when redirection is involved.

Posted: **2024-05-14 09:46**

This works on the log file:

Code: Select all

cat log2.txt | more

and makes it quite readable.

Posted: **2024-05-14 09:59**

NorthEast wrote: 2024-05-14 09:46 This works on the log file:
Code: Select all
cat log2.txt | more
and makes it quite readable.

You can do it by:

Code: Select all

less -r log2.txt

(Which will not terminate at the end.)

Posted: **2024-05-14 12:00**

mrmazda wrote: 2024-05-14 02:43
SirEdward wrote: 2024-05-14 02:25 Output with -Faz, in case it's helpful.
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
Inxi is intelligently designed to write only plain text when redirection is involved.

@Aki provided us with [Tips] How to remove control characters from terminal recording (i.e. by script command)
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

Posted: **2024-05-14 15:11**

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).

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:

Code: Select all

> grep -i color /etc/inxi.conf
GLOBAL_COLOR_SCHEME=0
>

-Faz dumps pretty much everything about hardware and much about software, so includes a lot of noise WRT can't find root filesystem issues. It's man page offers more specific, less noisy options, e.g.:

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
#

For this OP's problem, the following might be useful, possibly more so:

Code: Select all

efibootmgr -v
parted -l
lsblk -f
cat /etc/fstab # (or wherever fstab may be temporarily mounted for troubleshooting)

Debian User Forums

Debian fails to boot on NVMe M.2 disk after UEFI install

Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install

Re: Debian fails to boot on NVMe M.2 disk after UEFI install