Debian Kernel Update 4.19.0-10 zu 5.8.3 "Volume group not found"

[_anonymous0815_]

Hallo liebe Computerbase-Gemeinde,

dies ist mein erster Beitrag auf dieser Plattform, bisher war ich nur stiller Mitleser. Ich bin dabei, mir die Grundlagen von Linux mithilfe eines Buches anzueignen und nahm mir bereits vor einer knappen Woche eine Aufgabe vor, die ich bis jetzt nicht lösen konnte. In dem aktuellen Kapitel ging es darum, wie man einen Custom-Kernel kompiliert und installiert. (

make menuconfig; make -j$(nproc); make install modules_install; update-grub

). In etwa so wurden die Schritte im Buch beschrieben, für mich las sich das recht simpel, also wollte ich es einfach mal probieren und da Debian sehr konservativ beim Kernel vorgeht, sollte es gleich das aktuelle Release sein.

Soweit so gut, nachdem ich via apt alle nötigen Tools zur Menükonfiguration (libncurses5-dev/stable), sowie zur Kompilation (bc, bison, flex, gcc, libelf-dev, libssl-dev und make) bezogen hatte, machte ich mich an die Kernelkonfiguration ran, dafür übernahm ich die aktuelle Kernel-Config aus /boot von Kernel 4.19.0-10.
Dort habe ich lediglich GPU-Treiber, Soundtreiber, Input-Treiber (Touchscreen), sowie WLAN und Bluetooth aus der Konfiguration rausgeschmissen.
Es handelt sich hierbei um eine Hyper-V VM.
Nachdem ich den kompilierten Kernel mit

make install modules_install

installiere, habe ich im Bootverzeichnis folgende neue Dateien liegen: vmlinuz-5.8.3, initrd.img-5.8.3, config-5.8.3 und System.map-5.8.3. Soweit so gut, im Buch wurde dies gar nicht derart ausführlich thematisiert, außer dass Grub ebenfalls über die Installation informiert werden muss, indem man

update-grub

ausführt. Wenn ich nun einen Reboot vornehme, steht im Bootloader die Option "Linux 5.8.3" zur Verfügung, er fängt damit an, die init-RAM-Disk zu laden, danach wirft er lediglich aus: "Volume group "debian-vm-vg" not found".

Im Internet konnte ich vereinzelt ähnliche Berichte finden, bei denen die Thread-Ersteller damit abgespeist wurden, dass Debian trotz aller Stabiliät nun einmal nicht fehlerfrei sei und man es sich nicht anders erklären könnte. Dies ist nicht hilfreich für mich, daher die Frage an die CB-Community, hat jemand noch eine Idee, woran es liegen könnte, dass beim Start die vorhandene Volume-Group nicht gefunden wird?

 

[snaxilian]

Ernst gemeinter Rat: Überspring das Kapitel und beschäftige dich eher mit dem OS und den Tools anstatt mit der Erstellung des OS.
In den allerseltensten Fällen ist es notwendig einen eigenen Kernel zu kompilieren.
Ansonsten finde ich die jeweiligen Tutorials von dieser Seite recht brauchbar: https://www.cyberciti.biz/tips/compiling-linux-kernel-26.html

Für dein konkretes Problem würde ich vermuten, dass dein selbst kompilierter Kernel kein Modul für LVM hat. Ja, LVM ist toll und bietet eine Menge guter Möglichkeiten aber bei den ersten Schritten empfehle ich klein anzufangen und es so simpel wie möglich zu halten. Kein Raid, kein LVM, kein LUKS sondern 3 Partitionen, jeweils für /, /home und swap), der Rest kommt dann Stück für Stück dazu. Ansonsten hast du zu viele Baustellen parallel die deine Zeit beanspruchen oder die Fehlersuche unnötig verkomplizieren.

 

[Alexander2]

Kernel selber kompilieren braucht man normalerweise nicht zu machen, es sei denn villeicht man hat seltene ausnahmefälle. Einen patch für bestimmte geräte oder sowas?
Unter Arch linux/Manjaro jedenfalls habe ich ab und an mal, dass ich einen kernel Kompilieren lasse, das ist aber aus dem User Repository (AUR) mit fertiger konfiguration - alles vollautomatisch.

Wenn es um Anleitungen für Kernel Kompilierungen geht fand ich damals als ich Gentoo genutzt hatte deren Anleitung sehr gut und im Arch Linux Wiki (was für viele Anleitungen eine gute anlaufstelle ist - auch für andere Distributionen durchaus) dürfte auch eine sehr ausführliche Anleitung sein.

https://wiki.archlinux.org/index.php/Kernel/Traditional_compilation

Einzelne befehle sofern diese Arch spezifisch sind können variieren, im großen und ganzen ist das aber in der Regel überall nutzbar als Infoquelle.

 

[_anonymous0815_]

Ansonsten finde ich die jeweiligen Tutorials von dieser Seite recht brauchbar: https://www.cyberciti.biz/tips/compiling-linux-kernel-26.html

Ich bin jeden Schritt des Tutorials durchgegangen, der beschriebene Prozess ist nahezu deckungsgleich. Da ich die bestehende Kernel-Konfiguration als Ausgangsposition verwendet habe, bin ich mir sicher, dass die nötigen LVM-Treiber eingebunden sind, da die ursprüngliche Installation mit LVM erfolgte.

 

[snaxilian]

Ich rate mal ins Blaue hinein da du keinerlei Infos lieferst zum Partitionierungsschema deines Systems:
Du hast komplett LVM verwendet? "Problem" was du hast ist folgendes: Dein Grub wartet nicht lang genug bis er das Root-Dateisystem gefunden hat was innerhalb des LVMs liegt.
Bemüht man eine Suchmaschine mit "debian volume group not found" sollte dies einer der ersten Treffer sein der eine Lösung bietet: https://www.thomas-krenn.com/de/wiki/GRUB_Bootloader_bootet_nicht_von_LVM_Volume

 

[Y-Chromosome]

Wenn Du einen aktuellen Kernel bei Debian haben möchtest, wieso installierst Du nicht einfach den Backport-Kernel?
Ist im Augenblick 5.7.10
https://tracker.debian.org/pkg/linux

Der sollte ja für alles reichen ...

Wenn Du selbst einen Kernel bauen möchtest, dann wäre eventuell folgende Variable gut:
statt make menuconfig würde ich make localmodconfig wählen.
(Aber bitte mit dem aktuellen Debian-Kernel booten und nicht dem von Dir gebauten)
Das erstellt Dir eine Kernel-Config, die genau auf Dein System angepasst ist.

 

[_anonymous0815_]

Ich rate mal ins Blaue hinein da du keinerlei Infos lieferst zum Partitionierungsschema deines Systems:
Du hast komplett LVM verwendet? "Problem" was du hast ist folgendes: Dein Grub wartet nicht lang genug bis er das Root-Dateisystem gefunden hat was innerhalb des LVMs liegt.
Bemüht man eine Suchmaschine mit "debian volume group not found" sollte dies einer der ersten Treffer sein der eine Lösung bietet: https://www.thomas-krenn.com/de/wiki/GRUB_Bootloader_bootet_nicht_von_LVM_Volume

Die Unterstellung, dass ich so gar keine Ahnung von LVM habe, finde ich nicht gut, denn ein Grundwissen zur grundlegenden Partitionierung, der Einbindung weiterer Physical Volumes oder Partitions in eine Volume Group, sowie das Zuweisen des gewonnenen Speichers und dem online-resizing eines Logical Volumes sind vorhanden. Des Weiteren natürlich auch die Grundlagen zum Thema Mountpoints und Einträgen in die fstab. Für erfahrene Linux-Administratoren mag das alles kein Aufwand sein, ich bin jedoch ein absoluter Einsteiger, der sich langsam an das Thema herantasten möchte, diese Art (pauschale Abwertung) finde ich in dem Kontext einfach unangemessen. Zumal mir der verlinkte Artikel nicht weiterhilft, DENN: bekommt die BusyBox keinerlei Input von HyperV durchgereicht UND selbst der Delay-Eintrag in der Grub-Config von besagten 5 Sekunden bringt keine Besserung.

 

[snaxilian]

Das sollte keine Abwertung sein sondern ein gut gemeinter Ratschlag es nicht unnötig zu verkomplizieren. Auch der langjährige Linux-Admin fing mal klein an. Daher der Vorschlag es mit einem minimalsten System zu versuchen wenn man den eigenen Kernel bauen will. Du kannst von den Erfahrungen anderer profitieren oder eben auch nicht.
Anhand der bisherigen Posts ist nun einmal nicht ersichtlich was du bereits kannst oder eben nicht.

Wenn keine Eingaben per HyperV Konsole eingegeben werden ist das ein (weiteres) Problem. Vermutung wäre hier, dass busybox kein/nicht den hyperv_keyboard synthetic Treiber lädt bzw. geladen hat. Wenn du (weitere) Probleme nicht nennst dann können wir davon nichts wissen.

Kannst vorher im Grub noch den alten funktionierenden Standardkernel booten? Dann starte mit dem.
Angeblich lässt sich das busybox-hyperV-Keyboard Problem "lösen" wenn man secure boot für die VM deaktiviert.

Der genannte Wert von 5 Sekunden ist ein Beispiel. Je nach Situation reichen hier ggf. schon 2 oder es müssen 10 oder noch mehr werden. Tutorials müssen immer an die jeweilige eigene Situation angepasst werden.

Mein Tipp wäre ebenfalls /boot in eine eigene (kleine) Partition auszulagern die nicht innerhalb von LVM besteht. Bei Verwendung von UEFI dann ggf. noch /boot/efi auch auslagern.

 

[_anonymous0815_]

Wenn keine Eingaben per HyperV Konsole eingegeben werden ist das ein (weiteres) Problem. Vermutung wäre hier, dass busybox kein/nicht den hyperv_keyboard synthetic Treiber lädt bzw. geladen hat. Wenn du (weitere) Probleme nicht nennst dann können wir davon nichts wissen.

Das geht klar auf meine Kappe, dafür entschuldige ich mich, das hätte ich bereits im Ausgangspost thematisieren müssen.

Kannst vorher im Grub noch den alten funktionierenden Standardkernel booten? Dann starte mit dem.
Angeblich lässt sich das busybox-hyperV-Keyboard Problem "lösen" wenn man secure boot für die VM deaktiviert.

Vom 4.19.0-10 Kernel kann ich noch ganz normal booten. Secure Boot deaktiviere ich bei meinen VMs generell, das schafft leider keine Abhilfe.

Mein Tipp wäre ebenfalls /boot in eine eigene (kleine) Partition auszulagern die nicht innerhalb von LVM besteht. Bei Verwendung von UEFI dann ggf. noch /boot/efi auch auslagern.

/boot (/dev/sda2) und /boot/efi(/dev/sda1) sind nach der Installationsroutine (LVM /, /var, /home, /tmp)standardmäßig nicht in einer Volume Group. /dev/sda2 (/boot) habe ich aufgrund der geringen Größe mithilfe von dd auf eine größere Partition /dev/sda4(ext4) geklont und wird beim Start durch den /etc/fstab-Eintrag unter /boot eingehangen. Diesen Schritt habe ich vollzogen, weil laut einem anderen Foreneintrag ein

update-initramfs -u -k 5.8.3

notwendig sein könnte, dieser Prozess mir aber zurückmeldete, dass der vorhandene Speicher in /boot nicht ausreicht, obwohl dort nur die Kernel 4.19.0-10 und 5.8.3 liegen.

EDIT: Trotz Erweiterung der /boot Partition bekomme ich immer noch einen Fehler zurückgemeldet, dieser bezieht sich diesmal auf ein anderes Verzeichnis, in dem kein Speicher zur Verfügung stehen soll, dies verstehe ich nicht ganz:

root@debian-vm:/boot# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.8.3
cp: Fehler beim Schreiben von '/var/tmp/mkinitramfs_ILXAQw//usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.20301.0': Auf dem Gerät ist kein Speicherplatz mehr verfügbar
E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.8.3 with 1.

So sieht es aktuell bei mir aus:

root@debian-vm:/boot# df -h
Dateisystem                     Größe Benutzt Verf. Verw% Eingehängt auf
udev                             2,0G       0  2,0G    0% /dev
tmpfs                            395M     11M  384M    3% /run
/dev/mapper/debian--vm--vg-root   43G     17G   24G   42% /
tmpfs                            2,0G       0  2,0G    0% /dev/shm
tmpfs                            5,0M       0  5,0M    0% /run/lock
tmpfs                            2,0G       0  2,0G    0% /sys/fs/cgroup
/dev/sda4                        4,9G    118M  4,6G    3% /boot
/dev/mapper/debian--vm--vg-var   1,4G    279M  1,1G   21% /var
/dev/mapper/debian--vm--vg-home  9,9G     37M  9,3G    1% /home
/dev/mapper/debian--vm--vg-tmp   314M    2,1M  291M    1% /tmp
/dev/sda1                        511M    5,2M  506M    1% /boot/efi
tmpfs                            395M    4,0K  395M    1% /run/user/114
tmpfs                            395M       0  395M    0% /run/user/0
tmpfs                            395M       0  395M    0% /run/user/1000

Ich sehe ehrlich gesagt nicht, welches Verzeichnis voll läuft, weiß dazu nochmal jemand Rat?

EDITEDIT: Ich habe mal

df -h

in einer Schleife laufen lassen, währenddessen ich

update-initramfs -u -v

ausgeführt habe. /var läuft tatsächlich voll, Fehler gefunden.

 

[snaxilian]

Gut programmierte Prozesse unter Linux haben die Angewohnheit im Fehlerfall hinter sich aufzuräumen. Daher wird /var während des erzeugens des Kernels voll laufen, ist es aber am Ende nicht mehr.

Du könntest auch noch zusätzlich in der /etc/fstab gucken ob du die Partitionen per Devicename /dev/sdaX o.ä. ansprichst oder per UUID. Die UUID findest du z.B. mit dem Tool blkid heraus und ist zu bevorzugen, da diese eindeutig ist. Das kann sonst gerne mal bei Systemen mit mehr als einem Laufwerk zu Problemen führen da sda nicht immer sda ist sondern die zuerst initialisierte Disk bzw. Laufwerk beim Start ist sda, die zweite dann sdb usw. usf.

 

[_anonymous0815_]

Habe nun /var ebenfalls erweitert und somit läuft update-initramfs -u -v durch, dabei erstellt er ein neues Image der Initial RAM-Disk, am Problem selbst hat sich aber noch nichts geändert, selbst ein Delay von 20 Sekunden bringt keine Änderung. Nach Grub sehe ich nur für 20 Sekunden nur einen blinkenden Prompt, danach erfolgt wieder die Meldung des Ausgangsposts. Die BusyBox kann ich noch immer nicht bemühen.

Ergänzung (28. August 2020)

Was mich gerade ein bisschen stutzig macht: Das initrd.img von Kernel 5.8.3 ist deutlich größer als das Image des 4.19.0 Kernels:

-rw-r--r-- 1 root root  37M Aug 24 11:29 initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 root root 376M Aug 28 18:18 initrd.img-5.8.3

Kann sich das jemand erklären, wie diese Diskrepanz zustande kommt?

 

[Alexander2]

So wie es aussieht hast du in deiner konfig viel mehr an treiber festgelegt, dass sie direkt im image mit abgespeichert werden, wenn ich das richtig weiß ist das so, wenn sie als static statt als modul kompiliert werden.
https://en.wikipedia.org/wiki/Initial_ramdisk
Bei dem kleineren Image dürften diese nach dem Start der wichtigsten Komponenten und Dateisystemtreiber dann von der Partition als Module geladen werden.

 

[lokon]

Überprüfe mal die Größe von Kernel und dem erstelleten Modules.
Eventuell wurde mit Debug-Symbolen kompiliert - diese sind oft aktiviert, werden aber nicht benötigt bzw. in Debian in extra Pakete ausgelagert (dbgsym).

Kernelkonfiguration ändern bzw. auch
make INSTALL_MOD_STRIP=1 modules_install
siehe quelle

Edit: Beim booten sollten die LVM tools doch in der emergency shell verfügbar sein um manuell den LVM zu mounten - ansonsten die entsprechenden Konfigurationen bei initramfs-Erstellung anpassen.

Kernelparameter gibt es afaik noch rootwait
Quelle: Kernel Dokumentation hier

Ergänzung (28. August 2020)

Achja - LVM mit Snapshots benötigt Zeit zum Prüfen - früher™ gab es sowas auch beim RAM usw.... - Bootzeiten in Minuten

But with, say, 200 snapshots (some of which include creation of an iso image), it takes more than 1.5 minutes

Quelle 1 , Quelle 2 ("time out")

 

[_anonymous0815_]

Überprüfe mal die Größe von Kernel und dem erstelleten Modules.
Eventuell wurde mit Debug-Symbolen kompiliert - diese sind oft aktiviert, werden aber nicht benötigt bzw. in Debian in extra Pakete ausgelagert (dbgsym).

Kernelkonfiguration ändern bzw. auch
make INSTALL_MOD_STRIP=1 modules_install
siehe quelle

Damit konnte ich das initrd.img auf 16 MiB shrinken, ändert leider nichts an meinem Problem, selbst mit einem Delay von 180 Sekunden ergibt sich keine Änderung, ich weiß nicht mehr weiter. Ich habe hier eine Möglichkeit gefunden, wie man initramfs eigene Skripte übergeben kann, die dann je nach Lokation zu unterschiedlichen Zeitpunkten im Prozess ausgeführt werden, so könnte ich prinzipiell das Problem umgehen, dass ich keinen Input bei der BusyBox habe, jedoch macht mich ein Punkt stutzig:

/usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
/etc/initramfs-tools/scripts/local-top/forcelvm ignored: not executable
/usr/share/initramfs-tools/scripts/local-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/panic/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable

Sobald ich ein update-initramfs -u -v -k all ausführe, meldet er mir dies zurück, das liest sich für einen unbedarften Einsteiger etwa so, als ob die Skripte in diesen Verzeichnissen ignoriert werden und das würde sich mit meinem Erlebten decken, denn dieses Skript hier wird bei mir nicht ausgeführt.

 

[Alexander2]

musst du eventuell das script ausführbar dort einfügen? Ich weiß nicht ob dir bekannt ist wie man Scripte ausführbar einstellt?

Mit "chmod +x FILENAME" kannst du eine Datei das attribut zum ausführen setzen. im script müsste entsprechend auch in der ersten Zeile eine info für die Kommandozeile enthalten sein womit dieses ausgeführt werden soll wie zum beispiel "#!/bin/bash"

Hier auch eine gute Infoquelle zu Shell Scripts :-)
https://de.wikibooks.org/wiki/Linux-Praxisbuch/_Shellprogrammierung

 

[lokon]

Im Kernel bzw. Initramfs muss das HyperV-Keyboard aktiviert sein
siehe askubuntu: Keyboard not working in Hyper-V ...

Also: hyperv_keyboard hid_hyperv
Sind diese Module überhaupt im neuen Kernel aktiviert ? Die HyperV Konfiguration im Kernel muss aktiviert sein dafür.

Wenn du die Module in den Kernel einkompilierst anstatt Module zu erstellen, dann gibt es keine / weniger Probleme mit dem initramfs-hook, der diese Module zum initramfs/initrd hinzufügt.

Mit funktionierender Tastatur klappt Fehlersuche/Tests in der busybox rescue-console besser.

 

[_anonymous0815_]

Also: hyperv_keyboard hid_hyperv
Sind diese Module überhaupt im neuen Kernel aktiviert ? Die HyperV Konfiguration im Kernel muss aktiviert sein dafür.

Im neuen Kernel definitiv, genauso wie LVM, ich bin mit den Ideen am Ende, die BusyBox bekomme ich nicht zum laufen, kann weiterhin keine Befehle absetzen, das initramfs-Skript wird nicht wie gewünscht ausgeführt. Ich glaube ich muss hier einfach einen Cut machen, die Grundlagen zur Kernel-Erstellung habe ich ja durchaus erlernt, dieses spezifische Problem zu lösen, überschreitet einfach meine derzeitigen Fähigkeiten und Kenntnisse.