ubuntuusers.de

Hallo liebes Forum,

ich habe gesterm das Update von 22.04 auf 24.04 angestoßen. Ich nutze verschlüsselte Partitionen (luks) mit LVM. Ich vermute, dass hierbei etwas bzgl. initramfs schief gelaufen ist (versehentlich etwas überschrieben o.ä.?). Das System bootet nicht mehr. Fehlermeldung:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Gave up waiting for root file system device. Common problems:
  - Boot args (cat /proc/cmdline)
    - Check rootdelay= (did the system wait long enough?)
  - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/vgubuntu-root does not exist. Dropping to a shell!

BusyBox v1.36.1 (Ubuntu 1:1.36.1-6ubuntu3.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Aus der shell (initramfs) komme ich auch nicht mit exit heraus. cryptsetup luksOpen kann ich von hier aus nicht nutzen.

Über ls konnte ich herausfinden, dass /dev/mapper/vgubuntu-root tatsächlich nicht vorhanden ist.

Ich kann ein Live-System starten und die verschlüsselten Partitionen einhängen und hoffe daher, dass ich mittels Live System und chroot das aktualisierte System wieder "retten" kann (ich nehme an über update-initramfs, ähnlich wie hier: https://askubuntu.com/questions/286284/system-no-longer-boots-gave-up-waiting-for-root-device-initramfs-dev-mappe). Das hatte ich auch versucht (konkret im Wesentlichen nach dieser Anweisung: https://unix.stackexchange.com/a/647863) - leider erfolglos.

Ich habe ein Clonezilla Backup der gesamten SSD des betroffenen Systems. Notfalls kann ich also zu dem lauffähigen 22.04-Stand zurück.

Ich bitte hier um eure Unterstützung dabei das System wieder in einen bootfähigen Zustand zu bringen.

Infos zu meinem System

lsblk (Ausschnitt interne SSD des betroffenen Systems)

1
2
3
4
5

NAME         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1      259:0    0   1.8T  0 disk  
├─nvme0n1p1  259:1    0   200M  0 part  
├─nvme0n1p2  259:2    0     2G  0 part  
└─nvme0n1p3  259:3    0   1.8T  0 part  

lsblk -fs (Ausschnitt interne SSD des betroffenen Systems)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

NAME FSTYPE FSVER LABEL                    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1p1
     vfat   FAT32 EFI                      FD6C-D98B                                           
└─nvme0n1
                                                                                               
nvme0n1p2
     ext4   1.0                            eff16e91-2089-4fc6-afcb-ba837b835eb0                
└─nvme0n1
                                                                                               
nvme0n1p3
     crypto 2                              a0b3f136-eece-4fae-bdb2-4dfa8fa401d0                
└─nvme0n1

/etc/crypttab

1

lukslvm UUID=a0b3f136-eece-4fae-bdb2-4dfa8fa401d0 none luks

fstab

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vgubuntu-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/nvme0n1p2 during installation
UUID=eff16e91-2089-4fc6-afcb-ba837b835eb0 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=FD6C-D98B  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/vgubuntu-home /home           ext4    defaults        0       2
/swapfile                                 none            swap    sw              0       0

/etc/default/grub

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash kopt=root=/dev/mapper/vgubuntu-root"
GRUB_CMDLINE_LINUX=""

# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

etc/cryptsetup-initramfs/conf-hook

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

#
# Configuration file for the cryptroot initramfs hook.
#

#
# KEYFILE_PATTERN: ...
#
# The value of this variable is interpreted as a shell pattern.
# Matching key files from the crypttab(5) are included in the initramfs
# image.  The associated devices can then be unlocked without manual
# intervention.  (For instance if /etc/crypttab lists two key files
# /etc/keys/{root,swap}.key, you can set KEYFILE_PATTERN="/etc/keys/*.key"
# to add them to the initrd.)
#
# If KEYFILE_PATTERN if null or unset (default) then no key file is
# copied to the initramfs image.
#
# Note that the glob(7) is not expanded for crypttab(5) entries with a
# 'keyscript=' option.  In that case, the field is not treated as a file
# name but given as argument to the keyscript.
#
# WARNING:
# * If the initramfs image is to include private key material, you'll
#   want to create it with a restrictive umask in order to keep
#   non-privileged users at bay.  For instance, set UMASK=0077 in
#   /etc/initramfs-tools/initramfs.conf
# * If you use cryptsetup-suspend, private key material inside the
#   initramfs will be in memory during suspend period, defeating the
#   purpose of cryptsetup-suspend.
#

#KEYFILE_PATTERN=

#
# ASKPASS: [ y | n ]
#
# Whether to include the askpass binary to the initramfs image.  askpass
# is required for interactive passphrase prompts, and ASKPASS=y (the
# default) is implied when the hook detects that same device needs to be
# unlocked interactively (i.e., not via keyfile nor keyscript) at
# initramfs stage.  Setting ASKPASS=n also skips `cryptroot-unlock`
# inclusion as it requires the askpass executable.

#ASKPASS=y

Was ich versucht habe (in Anlehnung an https://unix.stackexchange.com/a/647863)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1pe_crypt
sudo mkdir /mnt/vgubuntu-root
sudo vgscan
  Found volume group "vgubuntu" using metadata type lvm2
sudo vgchange -ay
  2 logical volume(s) in volume group "vgubuntu" now active
sudo mount /dev/mapper/vgubuntu-root /mnt/vgubuntu-root
sudo mount /dev/nvme0n1p2 /mnt/vgubuntu-root/boot/
sudo mount -o rbind /dev/ /mnt/vgubuntu-root/dev/
sudo mount -t proc proc /mnt/vgubuntu-root/proc/
sudo mount -t sysfs sys /mnt/vgubuntu-root/sys/
sudo cp /etc/resolv.conf /mnt/vgubuntu-root/resolv.conf
sudo chroot /mnt/vgubuntu-root/ /bin/bash
apt install cryptsetup
   [...]
   cryptsetup is already the newest version (2:2.7.0-1ubuntu4.2)
apt install lvm2
   [...]
   lvm2 is already the newest version (2.03.16-3ubuntu3.2).
update-initramfs -u -k all
   update-initramfs: Generating /boot/initrd.img-6.8.0-54-generic
   update-initramfs: Generating /boot/initrd.img-5.19.0-41-generic
update-grub
   Sourcing file `/etc/default/grub'
   Generating grub configuration file ...
   Found linux image: /boot/vmlinuz-6.8.0-54-generic
   Found initrd image: /boot/initrd.img-6.8.0-54-generic
   Found linux image: /boot/vmlinuz-5.19.0-41-generic
   Found initrd image: /boot/initrd.img-5.19.0-41-generic
   Found memtest86+ 64bit EFI image: /memtest86+x64.efi
   Warning: os-prober will not be executed to detect other bootable partitions.
   Systems on them will not be added to the GRUB boot configuration.
   Check GRUB_DISABLE_OS_PROBER documentation entry.
   Adding boot menu entry for UEFI Firmware Settings ...
done
exit
sudo sync
sudo umount /mnt/vgubuntu-root/sys
sudo umount /mnt/vgubuntu-root/proc
sudo umount /mnt/vgubuntu-root/boot

Ich hoffe, dass hier jemandem noch etwas dazu einfällt. Sollte etwas fehlen, gerne melden und ich liefere nach.

Danke! Max

TheEYE schrieb:

ich habe gesterm das Update von 22.04 auf 24.04 angestoßen.

Hast du nicht, sondern es war ein upgrade

Bitte mal codeblock lesen. Da steht was unter:

3. Rohtext wählen.

Stimmen die jeweilige UUID in

/etc/crypttab

... und die Ausgabe von:

sudo cryptsetup luksDump /dev/<DEVICE_NODE>

... überein?

Berlin_1946 schrieb:

TheEYE schrieb:

ich habe gesterm das Update von 22.04 auf 24.04 angestoßen.

Hast du nicht, sondern es war ein upgrade

Stimmt, danke! Das vertüdele ich immer noch gerne... 😬

Berlin_1946 schrieb:

Bitte mal codeblock lesen. Da steht was unter:

3. Rohtext wählen.

Danke! Ich kann meinen ersten Beitrag leider nicht mehr bearbeiten, um das zu ändern.

trollsportverein schrieb:

Stimmen die jeweilige UUID in

/etc/crypttab

... und die Ausgabe von:

sudo cryptsetup luksDump /dev/<DEVICE_NODE>

... überein?

Ja, tun sie.

sudo cryptsetup luksDump /dev/nvme0n1p3
LUKS header information
Version:       	2
Epoch:         	4
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	a0b3f136-eece-4fae-bdb2-4dfa8fa401d0
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Ich konnte nirgendwo Fehler bzgl. UUIDs etc. finden. Geänderte UUIDs würden mich auch wundern, ich habe nichts an der Hardware geändert, lediglich das Upgrade aus dem laufenden System heraus gestartet / durchgeführt. Ich bin mir ehrlich gesagt aktuell gar nicht sicher, ob das hätte funktionieren müssen oder ob ich noch besondere Vorkehrungen aufgrund der Verschlüsselung hätte treffen müssen. Letzteres ist für mich auch sehr interessant, hier wartet noch ein Rechner mit sehr ähnlichem Setup auf sein Upgrade. Wenn ich das aktuell betroffene System wieder zum Laufen bekommen würde, wäre mir allerdings schon sehr geholfen.

Bitte unterlasse Fullquote. Lies dazu Zitate.

Da steht eindeutig:

Hier wird ausdrücklich von "Teile eines vorherigen Beitrags" gesprochen, gesamte -also komplette- Beitragen zu zitieren ist unerwünscht.

Hallo TheEYE

bitte noch mal lesen: codeblock

1.Text einschließlich eingegebenem Befehl und dem Ende-Prompt/Endezeichen, ...

Ein Beispiel mit dem Befehl date: mit 1. Befehl – 2. Ausgabe – 3. Prompt/Endezeichen

~$ date                        # 1. Befehl
So 2. Mär 11:42:21 CET 2025    # 2. Ausgabe
~$                             # 3. Prompt/Endezeichen zeigt, dass alles gepostet ist.

Probier mal in /etc/crypttab:

nvme0n1p3_crypt UUID=a0b3f136-eece-4fae-bdb2-4dfa8fa401d0 none luks,discard

discard aber weg lassen, falls das SSD-Trim nicht direkt an das verschlüsselte Laufwerk durchgereicht werden soll.

Damit nvme0n1p3_crypt funktioniert, sollte:

/dev/mapper/nvme0n1p3_crypt

... unter /dev/mapper zu finden sein, etwa als Link zu → ../dm-<NUMMER>

Gegebenenfalls müssen auch die initrd in /boot neu gebaut werden und die GRUB Konfiguration aktuallsiert werden.

sudo update-initramfs -c -k all && sudo update-grub

😇

leichtes OT

Hallo trollsportverein,

was hälst du von der Überlegung, vor einem "Upgrade"

• entschlüsseln

• upgrade

• verschlüsseln

nur mal so gefragt.

Ist jetzt hier gelaufen, könnte jedoch ggf ins Wiki.

@Berlin_1946: LUKS-Verschlüsselung wegmachen, ohne die gespeicherten Daten in verschlüsselten Partitionen zu zerstören?

Praktikabel wäre wohl System frisch aufsetzen, auf ein anderes (neues?) Laufwerk, und dann die Nutzdaten vom alten System ins neue System rein holen. Wäre mir aber zu aufwändig, so lange ich nicht auf neue Hardware umziehen will.

Ein normales Ubuntu Upgrade findet mit aufgeschlossener LUKS-Verschlüsselung, also im Normalbetrieb statt, wie auch jedes Update, etwa wenn es eine frische Firefox Version gibt. Normalweise sollte das gut gehen. Bei mir hat das jedenfalls schon viele Male geklappt. Hin und wieder habe ich aber auch schon mal was verpeilt und/oder zerbastelt, und dann gibt es was zu frickeln und dazu zu lernen. 😎

Hallo trollsportverein

ich arbeite "nur" mit verschlüsselten Sticks.

Mir ist nur das in Erinnerung geblieben und ...

Home umziehen (Abschnitt „Zusatz-bei-verschluesseltem-Nutzerverzeichnis“)

☺ Fällt in die Rubrik: frickeln 😎

Jetzt haben wir TheEYE verschreckt. Sry

Keine Sorge, ich bin nicht verschreckt!

OT

Die Info, dass es eigentlich klappen sollte, freut mich. SSD tauschen nur um ein Upgrade zu fahren kann es ja irgendwie auch nicht sein. Wird ja auch immer unbequemer Notebooks zu öffnen.

zum Thema

Ich habe hier noch ein sehr ähnliches System. Dort sieht die /etc/crypttab so aus, wie von dir vorgeschlagen (UUID mal nicht abgetippt):

sda4_crypt UUID=***** none luks,discard

Ich habe dann mal weiter geguckt und entdeckt, dass dort passende Einträge unter /dev/mapper/ vorhanden sind:

k_user@k-Thinkpad-X200:~$ ls /dev/mapper
control sda4_crypt vgubuntu-root vgubuntu-swap_1
k_user@k-Thinkpad-X200:~$ 

Unter /dev/ finde ich auch dm-0 bis dm-2.

Das betroffene System hat in dem manuell unter /mnt/vgubuntu-root/dev/ gar keinen Unterordner mapper. Und unter /dev/ finde ich auch keine dm-*.

Gucke ich am falschen Ort oder ist da doch deutlich mehr kaputt gegangen als befürchtet? Wobei das Entschlüsseln im Live-System ja wunderbar funktioniert...

Ich würde das hier gerne auflösen und bei der Gelegenheit noch mehr zu den Zusammenhängen etc. lernen. Sollte das System mir allerdings (warum auch immer) viel mehr um die Ohren geflogen sein, als erwartet, kann ich auch mein Backup einspielen und das Upgrade noch einmal versuchen.

trollsportverein Ich habe jetzt noch nichts weiter angepasst, da ich so überrascht über das Fehlen von dm-* etc. bin.

Falls das aus einem Live-System angeschaut wird, kann man möglicherweise die Device-Mapper Einträge nicht sehen, oder man müsste mal schauen, ob unter dem Mountpoint was zu sehen ist, in den das havarierte System eingehängt wurde.

Ah, okay.

Ja, ist von einem Live-System aus auf die eingehängte root-Partition des havarierten Systems geguckt (/mnt/vgubuntu-root). Im Live-System selbst sehe ich die Einträge die ich auch sonst gerne sehen würde:

ubuntu@ubuntu:~$ ls /dev/mapper
control  nvme0n1pe_crypt  vgubuntu-home  vgubuntu-root
ubuntu@ubuntu:~$ 

Wenn ich beim Bootversuch in die initramfs-Shell zurückfalle, finde ich unter /dev/mapper lediglich control.

Ich weiß ehrlich gesagt gerade nicht, wie ich mit den "fehlenden" dm-* Einträgen umgehen soll. Also was wohin zeigen / auf was verweisen sollte ...

Grübel.

Das sieht eigenartig aus:

nvme0n1pe_crypt

vs.

/dev/nvme0n1p3

Kann das "e" aufgrund eines Tippfehlers da rein geraten sein?

Ich habe kein nvme Laufwerk, aber ich würde mich wundern, wenn etwa aus einem /dev/sda3 Serial-ATA Device-Node ein /dev/sdae werden würde. Da würde ich mich fragen, ob ich irgendwo einen Tippfehler rein gehauen hätte. Das "e" sitzt ja unterhalb von der "3"

Ja, das ist ein Tippfehler. Ich hatte die verschlüsselte Partition so im Live-System geöffnet (Befehl aus der "Historie", daher ohne Ende-Prompt):

sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1pe_crypt

Die Bezeichnung für das Mapping ist hier frei wählbar (https://linuxwiki.de/cryptsetup / LUKS/Partitionen verschlüsseln). Wurde im Live-System also alles richtig angelegt (inkl. meines Tippfehlers).