ubuntuusers.de

Kernel 6.8 findet LUKS-Partition nicht beim Start

Status: Ungelöst | Ubuntu-Version: Xubuntu 22.04 (Jammy Jellyfish)
Antworten |

Dee Team-Icon

Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

Hallo,

ich habe nach langer Zeit tatsächlich mal wieder ein Problem mit meinem System. Ich nutze folgende Xubuntu-Version:

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"

Zusätzlich habe ich eine mit LUKS vollverschlüsseltes System, sodass ich zum Systemstart (nach der Kernelauswahl in Grub, wenn ich mal die Wahl haben will) ein Passwort eingeben muss.

In der Regel lass ich meinen Laptop für einige Tage an, fahre natürlich Updates, wenn nötig. Als ich den Rechner dann letztens (müsste am 25.8.2024 gewesen sein) aus- und danach einschaltete, hing das System beim Warten auf die verschlüsselte Partition (abgetippt):

  Volume group "vgxubuntu" not found
  Cannot process volume group vgxubuntu
  Volume group "vgxubuntu" not found
  Cannot process volume group vgxubuntu
[...] <- Der Output kommt gleich separat.
cryptsetup: Waiting for encrypted source device UUID=fe4be0a6-...
  Volume group "vgxubuntu" not found
  Cannot process volume group vgxubuntu
cryptsetup: Waiting for encrypted source device UUID=fe4be0a6-...
Gave up waiting for suspend/resume device
cryptsetup: Waiting for encrypted source device UUID=fe4be0a6-...
  Volume group "vgxubuntu" not found
  Cannot process volume group vgxubuntu
cryptsetup: Waiting for encrypted source device UUID=fe4be0a6-...
Gave up waiting for suspend/resume device
 - Boot args (cat proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modiles; ls /dev)
ALERT! /dev/mapper/vgxubuntu-root does not exist. Dropping to a shell!

BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3.1) built-in shell (ash)

(initramfs) _

Hier genutzte Kernelversion ist "6.8.0-40", mit der das Problem besteht. Ich weiß leider nicht mehr, ob es vor dem Problem ein Update des Kernels gab. Da ich nur eine Version des 6.8er-Kernels installiert habe, vermute ich aber mal nein.

Wenn ich in der BusyBox den Laptop aus- und einschalte, erscheint das Grub-Menü und kann ich glücklicherweise einen anderen Kernel "6.5.0-45" auswählen. Mit dem wird die Partition dann auch gefunden und startet normal.

Randnotiz zu der Auslassungsstelle oben. An der kommt folgender Fehleroutput:

Sep 14 07:12:55 dexus2 kernel: [    9.928863] irq 9: nobody cared (try booting with the "irqpoll" option)
Sep 14 07:12:55 dexus2 kernel: [    9.928867] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.5.0-45-generic #45~22.04.1-Ubuntu
Sep 14 07:12:55 dexus2 kernel: [    9.928869] Hardware name: LENOVO 82GX/LNVNB161216, BIOS EMCN42WW 10/28/2020
Sep 14 07:12:55 dexus2 kernel: [    9.928871] Call Trace:
Sep 14 07:12:55 dexus2 kernel: [    9.928872]  <IRQ>
Sep 14 07:12:55 dexus2 kernel: [    9.928874]  dump_stack_lvl+0x48/0x70
Sep 14 07:12:55 dexus2 kernel: [    9.928880]  dump_stack+0x10/0x20
Sep 14 07:12:55 dexus2 kernel: [    9.928882]  __report_bad_irq+0x30/0xd0
Sep 14 07:12:55 dexus2 kernel: [    9.928886]  note_interrupt+0x2e1/0x320
Sep 14 07:12:55 dexus2 kernel: [    9.928888]  handle_irq_event+0x79/0x80
Sep 14 07:12:55 dexus2 kernel: [    9.928890]  handle_fasteoi_irq+0x7d/0x200
Sep 14 07:12:55 dexus2 kernel: [    9.928892]  __common_interrupt+0x53/0x110
Sep 14 07:12:55 dexus2 kernel: [    9.928895]  common_interrupt+0x9f/0xb0
Sep 14 07:12:55 dexus2 kernel: [    9.928898]  </IRQ>
Sep 14 07:12:55 dexus2 kernel: [    9.928898]  <TASK>
Sep 14 07:12:55 dexus2 kernel: [    9.928899]  asm_common_interrupt+0x27/0x40
Sep 14 07:12:55 dexus2 kernel: [    9.928902] RIP: 0010:cpuidle_enter_state+0xda/0x720
Sep 14 07:12:55 dexus2 kernel: [    9.928905] Code: d8 05 ff e8 a8 f5 ff ff 8b 53 04 49 89 c7 0f 1f 44 00 00 31 ff e8 a6 83 04 ff 80 7d d0 00 0f 85 61 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 f7 01 00 00 4d 63 ee 49 83 fd 09 0f 87 19 05 00 00
Sep 14 07:12:55 dexus2 kernel: [    9.928907] RSP: 0018:ffffadb08010fe18 EFLAGS: 00000246
Sep 14 07:12:55 dexus2 kernel: [    9.928908] RAX: 0000000000000000 RBX: ffffcdb07fc40000 RCX: 0000000000000000
Sep 14 07:12:55 dexus2 kernel: [    9.928909] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000
Sep 14 07:12:55 dexus2 kernel: [    9.928910] RBP: ffffadb08010fe68 R08: 0000000000000000 R09: 0000000000000000
Sep 14 07:12:55 dexus2 kernel: [    9.928911] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffbb8d2500
Sep 14 07:12:55 dexus2 kernel: [    9.928912] R13: 0000000000000001 R14: 0000000000000001 R15: 000000024fcd4481
Sep 14 07:12:55 dexus2 kernel: [    9.928913]  ? cpuidle_enter_state+0xca/0x720
Sep 14 07:12:55 dexus2 kernel: [    9.928916]  cpuidle_enter+0x2e/0x50
Sep 14 07:12:55 dexus2 kernel: [    9.928918]  call_cpuidle+0x23/0x60
Sep 14 07:12:55 dexus2 kernel: [    9.928921]  cpuidle_idle_call+0x11d/0x190
Sep 14 07:12:55 dexus2 kernel: [    9.928923]  do_idle+0x82/0xf0
Sep 14 07:12:55 dexus2 kernel: [    9.928924]  cpu_startup_entry+0x2a/0x30
Sep 14 07:12:55 dexus2 kernel: [    9.928926]  start_secondary+0x129/0x160
Sep 14 07:12:55 dexus2 kernel: [    9.928929]  secondary_startup_64_no_verify+0x190/0x19b
Sep 14 07:12:55 dexus2 kernel: [    9.928932]  </TASK>
Sep 14 07:12:55 dexus2 kernel: [    9.928932] handlers:
Sep 14 07:12:55 dexus2 kernel: [    9.928933] [<00000000d15956c1>] acpi_irq
Sep 14 07:12:55 dexus2 kernel: [    9.928937] Disabling IRQ #9

Aber: Das da oben ist der Output aus dem syslog mit Start von Kernel "6.5.0-45". Sprich, diese Meldung sehe ich auch mit dem Kernel, der meine Partition noch findet. Das ist also ein separates Problem, denke ich. (Sollte ich dazu einen separaten Thread aufmachen? Es scheint wohl nicht groß den Betrieb zu stören.)

Da das System mit "6.8.0-40" nicht startet, finde ich in den Logs in /var/log leider keine Information. Wie auch, wenn die Partition mit dem Verzeichnis nicht gefunden wird.

Hat jemand eine Ahnung, was ich sonst noch analysieren kann, wieso cryptsetup mit Kernel 6.8 nicht mehr mag? Suchen zu dem Thema im Netz bringen leider ganz wenige Treffer und irgendwie keine Lösung.

Viele Grüße und Danke für die Hilfe Dee

trollsportverein

Avatar von trollsportverein

Anmeldungsdatum:
21. Oktober 2010

Beiträge: 5646

Sind die Einträge in /etc/crypttab korrekt?

fleet_street

Top-Wikiautor
Avatar von fleet_street

Anmeldungsdatum:
30. August 2016

Beiträge: 2400

Wohnort: Hunsrück (dunkle Seite)

 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/vgxubuntu-root does not exist.  Dropping to a shell!



BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3.1) built-in shell (ash)

(initramfs) _

Wenn du bis zu der Stelle gebootet hast, könntest eintippen und abschicken:

grep crypt /proc/modules

Ist die Ausgabe leer, dann ist die Wahrscheinlichkeit groß, dass das Paket cryptsetup-initramfs nicht installiert ist und daher das initram nicht mit der Verschlüsselung umgehen kann.

Dee Team-Icon

(Themenstarter)
Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

Sind die Einträge in /etc/crypttab korrekt?

$ cat /etc/crypttab 
nvme0n1p3_crypt UUID=fe4be0a6-b7cc-4988-8c51-55875723ef9e none luks,discard

Sieht zumindest korrekt aus. Die UUID ist auch die, die in der Fehlermeldung angegeben wird (habe ich ja weggekürzt).

Gruß Dee

Dee Team-Icon

(Themenstarter)
Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

Wenn du bis zu der Stelle gebootet hast, könntest eintippen und abschicken:

grep crypt /proc/modules
dm_crypt 65536 0 - Live 0xffffffffc0676000
crypto_simd 16384 1 aesni_intel, Live 0xffffffffc0448000
crypt 24576 2 ghash_clmulni_intel,crypto_simd, Live 0xffffffffc0439000

Ist die Ausgabe leer, dann ist die Wahrscheinlichkeit groß, dass das Paket cryptsetup-initramfs nicht installiert ist und daher das initram nicht mit der Verschlüsselung umgehen kann.

Sollte es dann mit dem Kernel 6.5 aber nicht auch ein Problem geben? Das Paket "cryptsetup-initramfs" ist ja nicht kernelspezifisch installiert. Zur Prüfung:

dpkg -l cryptsetup-initramfs
ii  cryptsetup-initramfs 2:2.4.3-1ubuntu1.2 all          disk encryption support - initramfs integration

Das Paket ist also installiert.

Gruß Dee

fleet_street

Top-Wikiautor
Avatar von fleet_street

Anmeldungsdatum:
30. August 2016

Beiträge: 2400

Wohnort: Hunsrück (dunkle Seite)

Dee schrieb:

… Das Paket "cryptsetup-initramfs" ist ja nicht kernelspezifisch installiert. …

Es hätte ja zwischenzeitlich versehentlich deinstalliert worden sein. Jedenfalls ist die Meldung identisch mit einem System, bei dem ich das Paket absichtlich deinstalliert hatte, damit ich mir den Fehler notieren konnte. War ein Versuch.

dingsbums

Anmeldungsdatum:
13. November 2010

Beiträge: 3815

Sep 14 07:12:55 dexus2 kernel: [    9.928869] Hardware name: LENOVO 82GX/LNVNB161216, BIOS EMCN42WW 10/28/2020

Aktuell ist laut Lenovo BIOS Update 8.79 MB EMCN60WW 28 May 2024. Aktuelle Kernel mögen manchmal alte BIOS/UEFI-Versionen nicht so.

Alternativ die Reinstallation des 6.8er Kernels probieren, vielleicht ist da ja was schiefgegangen. Vorher die installierte 6.8er Version nochmal prüfen, ggf. anpassen.

dpkg --list | grep linux-image
sudo apt-get install --reinstall --install-recommends linux-image-6.8.0-40-generic

Ist alles fehlerfrei durchgelaufen, Initramfs noch einmal aktualisieren (falls das nicht gleich automatisch mit gelaufen sein sollte).

sudo update-initramfs -u   # -u  Update an existing initramfs

Dee Team-Icon

(Themenstarter)
Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

Alternativ die Reinstallation des 6.8er Kernels probieren

Das hab ich gemacht. Hat aber keine Verbesserung gebracht.

Aktuelle Kernel mögen manchmal alte BIOS/UEFI-Versionen nicht so.

Natürlich mache ich ein BIOS-Update nur, wenn es gar nicht anders möglich ist. Mein Problem ist aber, dass Lenovo nur eine exe-Datei für Windows 10/11 für das Update zur Verfügung stellt. Alle Anleitungen im Netz für "BIOS-Update unter Linux für Lenovo" reden aber von einer "Bootabable BIOS-Update CD", die es aber wohl nur für ThinkPads zu geben scheint, nicht für IdeaPads.

Wenn ich es richtig sehe, funktioniert auch keine der unter https://wiki.ubuntuusers.de/BIOS_bzw._UEFI_aktualisieren/#Moeglichkeiten genannten Methoden.

Ggf. gibt es ja aber noch andere Ideen, was ich machen kann, um Kernel 6.8 zum Laufen zu bekommen.

Gruß Dee

trollsportverein

Avatar von trollsportverein

Anmeldungsdatum:
21. Oktober 2010

Beiträge: 5646

Habe mal ein bisschen experimentiert. "BIOS Update 8.79 MB EMCN60WW 28 May 2024" herunter geladen.

innoextract emcn60ww.exe

Das ergibt dann ein Verzeichnis:

ls -1h 'code$GetExtractPath'

EMCN60WW.exe
install.bat

Diese aus dem Innosetup ausgepackte EMCN60WW.exe ist mit 8,3 Megabyte kleiner als die herunter geladene Innosetup exe Datei mit 8,8 Megabyte. Die lässt sich mit 7z auspacken:

7z x EMCN60WW.exe 

Das schüttet einiges an Klimbim aus, darunter aber wohl auch das wesentliche, ein Floppy Disk Abbild:

ls -1

BIOS.fd # <- Das ist ein 18 Megabyte großes Floppydisk Abbild.
BiosImageProc.dll
Ding.wav
EMCN60WW.exe
FlsHook.exe
FWUpdLcl.exe # <- Das ist die 8,3 Megabyte große Datei, die von innoextract ausgepackt wurde
H2OFFT32.sys
H2OFFT64.sys
H2OFFT.cat
H2OFFT.inf
H2OFFT-W.exe
mfc90u.dll
Microsoft.VC90.CRT.manifest
Microsoft.VC90.MFC.manifest
msvcp90.dll
msvcr90.dll
platform.ini
WDFInst.exe

Was nun irgendjemand mit diesen Informationen anfängt, bleibt jedem selbst überlassen. ¯\_(ツ)_/¯

Was würde ich machen, wenn ich solch eine Kiste hätte? Ich glaube, ich würde wohl trotzdem lieber provisorisch ein MS-Windows installieren, um dieses maximal umständliche BIOS, bzw. UEFI Update hinter mich zu bringen, auch um die Hoffnung zu erhöhen, dass die Kiste hinterher nicht zum Briefbeschwerer wird.

Dee Team-Icon

(Themenstarter)
Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

trollsportverein schrieb:

Was würde ich machen, wenn ich solch eine Kiste hätte? Ich glaube, ich würde wohl trotzdem lieber provisorisch ein MS-Windows installieren, um dieses maximal umständliche BIOS, bzw. UEFI Update hinter mich zu bringen, auch um die Hoffnung zu erhöhen, dass die Kiste hinterher nicht zum Briefbeschwerer wird.

Danke für das Experiment. Und ja, ich glaube, das ist mir zu heikel, aus den Dateien was draus zu stricken, nur weil Kernel 6.8 nicht will. Dann bleibe ich lieber erst einmal bei Kernel 6.5. Interessant wird es wohl mit dem „Zwangsupdate“ auf die nächste LTS-Version im April nächsten Jahres. Soweit ich sehe, ist in Version 24.04 nämlich Kernel 6.8 verbaut.

Gruß Dee

Mylin

Avatar von Mylin

Anmeldungsdatum:
23. Juli 2024

Beiträge: 454

trollsportverein schrieb:

Was nun irgendjemand mit diesen Informationen anfängt, bleibt jedem selbst überlassen. ¯\_(ツ)_/¯

Eine Doktorarbeit scheint es nict zu sein, vielleicht etwas für das sonntägliche Kaffee & Kuchen.

https://www.cyberciti.biz/faq/update-lenovo-bios-from-linux-usb-stick-pen/

trollsportverein

Avatar von trollsportverein

Anmeldungsdatum:
21. Oktober 2010

Beiträge: 5646

Ich bin aber wohl nicht der Einzige, der auf die Idee mit innoextract und 7z gekommen ist, wie ich nun noch entdeckt habe. Sogar MS-Windows Frickler nutzen so was.
Um dann das Bildchen im BIOS, bzw. UEFI zu ändern. Diese Wilden. 😎

trollsportverein

Avatar von trollsportverein

Anmeldungsdatum:
21. Oktober 2010

Beiträge: 5646

Auch bei Ubuntu selbst gibt es noch etwas geschriebenes zu diesen Lenovo BIOS, bzw. UEFI Updates, die Linux Usern offensichtlich das Leben maximal schwer machen sollen:

Wikipedia über diesen Firmware Hersteller:

Dee Team-Icon

(Themenstarter)
Avatar von Dee

Anmeldungsdatum:
9. Februar 2006

Beiträge: 20095

Wohnort: Schwabenländle

So, ich bin ein bisschen weiter. Es liegt nicht am Kernel 6.8 per se. Ich habe per Zufall mal mit den "Recovery Mode" im Boot-Menü ausgewählt. Dann fragt er brav nach dem Passwort für meine LUKS-Partition. Danach kann ich im Menü einfach auf "Resume" klicken und habe ein lauffähiges System.

Ich vermute also, dass irgendein Boot-Parameter dafür verantwortlich ist. Mein Grub sieht so aus:

 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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
	if [ "${1}" = "keep" ]; then
		set vt_handoff=vt.handoff=7
	else
		set vt_handoff=
	fi
}
if [ "${recordfail}" != 1 ]; then
  if [ -e ${prefix}/gfxblacklist.txt ]; then
    if [ ${grub_platform} != pc ]; then
      set linux_gfx_mode=keep
    elif hwmatch ${prefix}/gfxblacklist.txt 3; then
      if [ ${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
export linux_gfx_mode
Found linux image: /boot/vmlinuz-6.8.0-51-generic
Found initrd image: /boot/initrd.img-6.8.0-51-generic
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-025b246a-d9d1-4522-8697-821571e350c2' {
	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root 416abfd7-852b-4ae1-b440-d5ba9c775cd0
	linux	/vmlinuz-6.8.0-51-generic root=/dev/mapper/vgxubuntu-root ro  i8042.nopnp=1 pci=nocrs quiet splash initcall_blacklist=elants_i2c_driver_init $vt_handoff
	initrd	/initrd.img-6.8.0-51-generic
}
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-025b246a-d9d1-4522-8697-821571e350c2' {
	menuentry 'Ubuntu, with Linux 6.8.0-51-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.0-51-generic-advanced-025b246a-d9d1-4522-8697-821571e350c2' {
		recordfail
		load_video
		gfxmode $linux_gfx_mode
		insmod gzio
		if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
		insmod part_gpt
		insmod ext2
		search --no-floppy --fs-uuid --set=root 416abfd7-852b-4ae1-b440-d5ba9c775cd0
		echo	'Loading Linux 6.8.0-51-generic ...'
		linux	/vmlinuz-6.8.0-51-generic root=/dev/mapper/vgxubuntu-root ro  i8042.nopnp=1 pci=nocrs quiet splash initcall_blacklist=elants_i2c_driver_init $vt_handoff
		echo	'Loading initial ramdisk ...'
		initrd	/initrd.img-6.8.0-51-generic
	}
	menuentry 'Ubuntu, with Linux 6.8.0-51-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.0-51-generic-recovery-025b246a-d9d1-4522-8697-821571e350c2' {
		recordfail
		load_video
		insmod gzio
		if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
		insmod part_gpt
		insmod ext2
		search --no-floppy --fs-uuid --set=root 416abfd7-852b-4ae1-b440-d5ba9c775cd0
		echo	'Loading Linux 6.8.0-51-generic ...'
		linux	/vmlinuz-6.8.0-51-generic root=/dev/mapper/vgxubuntu-root ro recovery nomodeset dis_ucode_ldr 
		echo	'Loading initial ramdisk ...'
		initrd	/initrd.img-6.8.0-51-generic
	}

Das einzige, was mir auffällt, ist gfxmode $linux_gfx_mode. Ich habe aber noch nicht raus, was das macht. Ggf. kann jemand hiermit schon was anfangen und Tipps geben.

Gruß Dee

trollsportverein

Avatar von trollsportverein

Anmeldungsdatum:
21. Oktober 2010

Beiträge: 5646

Schau doch mal in die Datei:

/etc/default//grub

Damit stellt man den GRUB ein. Und in dieser Datei kann man auch den GRUB_GFXMODE einstellen.

Aber nicht vergessen, wenn man was daran ändert, dann auch noch ein:

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

... zu machen.

Antworten |