staging.inyokaproject.org

LUKS - System startet (nach Update>Kernel 3.13.0-34) nicht

Status: Gelöst | Ubuntu-Version: Kubuntu 14.04 (Trusty Tahr)
Antworten |

marwell

Avatar von marwell

Anmeldungsdatum:
18. Januar 2007

Beiträge: 165

Starte ich meinen Computer nach einem Update, das auch den Kernel 3.13.0-34 installiert hat, meldet sich nach einiger Zeit die BusyBox build in Shell und sagt

Gave up waiting for root device
...
ALERT! /dev/mapper/kubuntu--vg-root does not exist

Ich habe ein LUKS-System installiert.
Auf sda1 /boot
Auf sda2 eine verschlüsselte, logische Partition sda5 mit /root (incl home) und swap.

Eine Passwortabfrage erscheint nicht. Ich habe auf einer zweiten Festplatte ein altes System, von dem aus ich starten kann. Dort kann ich die verschlüsselte Partition auch mit Passwort öffnen. Von dort bin ich mit chroot in das verschlüsselte System gewechselt und habe versucht, mit

update-initramfs -u -k all

das initramfs upzudaten, was aber mit

cryptsetup: WARNING: invalid line in /etc/crypttab

abbricht, auch obwohl ich die Datei mit

lukslvm UUID=850550d3-b9f1-4d30-b249-c8141c7a8c8a none luks

gefüllt habe. Eigenartig, dass sie als Inhalt nur

# <target name>	<source device>		<key file>	<options>

hatte... Eine Leerzeile hat die geänderte Datei am Ende nicht.

update-grub

meldet sich mit

NOTICE: Skipping dropbear installation because /etc/crypttab has no entries
$ sudo blkid
/dev/sda1: UUID="188060fb-ee2a-4ae9-911b-5fb9d45c5fa0" TYPE="ext2" (/boot)
/dev/sda5: UUID="850550d3-b9f1-4d30-b249-c8141c7a8c8a" TYPE="crypto_LUKS" (crypt /root + swap)
...(noch eine Windows-Partition)...
/dev/sdb5: LABEL="INTERN_ROOT" UUID="b93e10a9-adda-44b6-9367-dd56a27b6b17" TYPE="ext4" (2tes, altes Kubuntu)
/dev/sdb6: UUID="5a2ef36b-b2d7-4b00-afed-1bf6bbd57497" TYPE="swap" 
/dev/sdb7: LABEL="INTERN_HOME" UUID="207d576c-0723-4b1c-b336-95904d4c8309" TYPE="ext4" (2tes, altes Kubuntu)
/dev/mapper/luks-850550d3-b9f1-4d30-b249-c8141c7a8c8a: UUID="4Vj3PZ-XXbL-vbcW-TvbE-rO6W-Gxbn-exHbme" TYPE="LVM2_member" 
/dev/mapper/kubuntu--vg-root: UUID="04ab0625-af2d-45ab-b8f9-cbf15d0920db" TYPE="ext4" 
/dev/mapper/kubuntu--vg-swap_1: UUID="f44795a4-2aa1-4797-a49b-e6be91393237" TYPE="swap" 

In der grub.cfg steht als Start-Device die UUID von sda1, also der /boot-Partition des verschlüsselten Kubuntus.

Ich komme nicht weiter... Hat jemand einen Tip, woran es liegen könnte oder was ich ausprobieren sollte? Danke!

marwell

(Themenstarter)
Avatar von marwell

Anmeldungsdatum:
18. Januar 2007

Beiträge: 165

...falls es an der grub.cfg liegt, hier im Anhang. Mir ist da nichts ersichtlich, obwohl es mir nicht verständlich ist, dass da sda1 als root angegeben ist, also die /boot=Partition. Ich habe beim Start Grub editiert und stattdessen die UUID von sda5=Crypto-LUKS angegeben, was wohl keinen Sinn macht. Ich verstehe aber auch nicht den genauen Ablauf, wie Grub die LUKS-Partition aufruft und einbindet.

grub.cfg (10.9 KiB)
Download grub.cfg

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7795

Das Invalid Line würde ich mal ernst nehmen...

Ich verstehe aber auch nicht den genauen Ablauf, wie Grub die LUKS-Partition aufruft und einbindet.

Nicht Grub, sondern das Initramfs sollte das dann machen.

Benno-007

Anmeldungsdatum:
28. August 2007

Beiträge: 29240

Zeig nochmal die crypttab und befülle sie nochmal sowie mit Leerzeile am Ende. Durch das Update dürfte sie sich nicht verändert haben, alternativ Rechte ansehen oder dies mit chattr (-i) verhindern, als Workaround. Mir ist noch nicht ganz klar, in welchen Reihenfolgen die Datei befüllt war und wurde und leer war.

Boote ggf. per Bootmenü einen alten Kernel. Dazu nach dem Anschalten des Computers schnell ganz oft die ESC-Taste drücken.

Notfalls das System per Live-CD öffnen bzw. chroot/Live-CD für Änderungen wie update-initramfs nutzen, wenn du da was einlesen musst/ testen willst.

marwell

(Themenstarter)
Avatar von marwell

Anmeldungsdatum:
18. Januar 2007

Beiträge: 165

Danke frostschutz, danke Benno-007!

crypttab sieht jetzt so aus:

kubuntu--vg-root UUID=850550d3-b9f1-4d30-b249-c8141c7a8c8a none luks

Dann

$ sudo mount /dev/mapper/kubuntu--vg-root /mnt
[sudo] password:
mlinux@mlinux:~$ sudo mount /dev/sda1 /mnt/boot
mlinux@mlinux:~$ sudo mount -o rbind /dev /mnt/dev
mlinux@mlinux:~$ sudo mount -t proc proc /mnt/proc
mlinux@mlinux:~$ sudo mount -t sysfs sys /mnt/sys
mlinux@mlinux:~$ sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
mlinux@mlinux:~$ sudo chroot /mnt /bin/bash
root@mlinux:/# sudo update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-3.13.0-34-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-32-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-24-generic
grep: /boot/config-3.13.0-24-generic: Datei oder Verzeichnis nicht gefunden
root@mlinux:/# update-grub
Grub-Konfigurationsdatei wird generiert …
using custom appearance settings
Found background image: .background_cache.jpeg
Linux-Abbild gefunden: /boot/vmlinuz-3.13.0-34-generic
initrd-Abbild gefunden: /boot/initrd.img-3.13.0-34-generic
Linux-Abbild gefunden: /boot/vmlinuz-3.13.0-32-generic
initrd-Abbild gefunden: /boot/initrd.img-3.13.0-32-generic
Linux-Abbild gefunden: /boot/vmlinuz-3.13.0-34-generic                                       
initrd-Abbild gefunden: /boot/initrd.img-3.13.0-34-generic                                   
Linux-Abbild gefunden: /boot/vmlinuz-3.13.0-32-generic                                       
initrd-Abbild gefunden: /boot/initrd.img-3.13.0-32-generic                                   
Found memtest86+ image: /memtest86+.elf                                                      
Found memtest86+ image: /memtest86+.bin                                                      
Found memtest86+ image: /memtest86+.elf                                                      
Found memtest86+ image: /memtest86+.bin                                                      
erledigt                                                                        

update initramfs und grub-update sollten jetzt richtig konfiguriert sein. Das System started aber trotzdem nicht, sondern zeigt die Meldung

BusyBox v1.21.1 (Ubuntu 1:121-1ubuntu1) build-in shell (ash)
...
(initramfs) IP-config: eth0 hardware address f0:de:cb:62:eb mtu 1500 DHCP RARP
IP-Config: no response after 9 secs - giving up
IP-Config: eth0 hardware address f0:de:cb:62:eb mtu 1500 DHCP RARP
IP-Config: no response after 16 secs - giving up

Daraufhin habe ich wie in /mnt/usr/share/initramfs-tools/scripts/init-premount/dropbear beschrieben

# If you encounter this specific issue then you should disable dropbear in the
# initramfs as it isn't needed to unlock the passphrase prompt. For this do:
# 1) Edit /usr/share/initramfs-tools/conf-hooks.d/dropbear and set DROPBEAR=n
# 2) Run: sudo update-initramfs -k all -u
configure_networking &

/usr/share/initramfs-tools/conf-hooks.d/dropbear geändert und dort

# DROPBEAR=y
auf
DROPBEAR=n 

geändert, initramfs unf Grub neu geupdatet, das hilft aber auch nichts.

Wieso braucht das überhaupt Dropbear? Und wieso sollte ich eine Netzwerkverbindung vor dem Mount von / haben, ich brauche keinen Zugriff per SSH oder ähnlichem? Ich mache jetzt erstmal ein aktuelles Backup des Crypto-LUKS. Sorry, das ist try and error bei mir, ich verstehe zu wenig von dem Bootvorgang mit LUKS. Es scheint ja aber wenigstens auf die richtige Partition jetzt zu verweisen, was in crypttab eingetragen ist. Wie kann ich BusyBox dazu bringen, nicht einzugreifen und nicht auf eine Netzwerkverbindung zu bestehen? Ich könnte den Computer natürlich auch mal mit LAN verbinden und sehen, was dann passiert.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7795

marwell schrieb:

Wieso braucht das überhaupt Dropbear?

Wenn du das nicht über Netzwerk machst, sondern selbst am Rechner sitzt, dann brauchst du auch kein Dropbear. dropbear kannst du komplett mit purge deinstallieren...

Wie kann ich BusyBox dazu bringen, nicht einzugreifen und nicht auf eine Netzwerkverbindung zu bestehen?

Eigentlich ist das der Standard... von daher stellt sich die Frage wie du das überhaupt hinbekommen hast.

Deine Crypttab stört mich irgendwie immer noch... kubuntu--vg-root klingt so nach dem Standardnamen den LVM für ein Root-LV in einer kubuntu-vg erstellen würde. Das LUKS Gerät sollte von daher einen anderen Namen haben (z.B. luks-root o.ä.). Sonst hast du in /dev/mapper/ zwei Geräte mit dem gleichen Namen (eines muss weichen) oder zwei mit sehr ähnlichem Namen und Verwechslungsgefahr wenn du jemals direkt auf diese Geräte zugreifen willst...

Aber das wird nicht der Auslöser deines Problems sein sonst hättest du da noch eine andere Fehlermeldung irgendwo.

marwell

(Themenstarter)
Avatar von marwell

Anmeldungsdatum:
18. Januar 2007

Beiträge: 165

Das Problem ist nicht die Netzwerkverbindung. Wenn ich LAN anschließe stört sich Dropbear daran nicht mehr. Das wurde automatisch installiert, als ich im chroot lvm2 installiert habe. Das war aus irgendwelchen Gründen nicht vorhanden. Dabei wurde Dropbear installiert. Das werde ich jetzt gleich mal mit purge entfernen. Wie ich das hinbekommen habe? 😊 Keine Ahnung...

Einen Fehler hatte ich übersehen, um den es wahrscheinlich geht. Nach der Passworteingabe bekomme ich eine Meldung

cryptsetup: lvm fs found but no lvm configured

Ich traue mich nur gerade nicht, bevor das Backup fertig ist, am cryptsetup irgendwas zu ändern.

Und ja, frostschutz, mit dem Namen des Cryptlaufwerkes in der crypttab bin ich mir tatsächlich unsicher. Wie finde ich raus, wie der ursprünglich hieß?

marwell

(Themenstarter)
Avatar von marwell

Anmeldungsdatum:
18. Januar 2007

Beiträge: 165

Es war wohl tatsächlich der Name des LUKS falsch.

Ich habe crypttab geändert in

luks-850550d3-b9f1-4d30-b249-c8141c7a8c8a UUID=850550d3-b9f1-4d30-b249-c8141c7a8c8a none luks

erneut im chroot initramfs und grub geupdated

update-initramfs -k all -u
update-grub

und der Rechner startet wieder. Auf den Namen war ich gekommen, weil in meinem Rettungssystem, das LUKS manuell eingehängt, unter /dev/mapper eben dieser Name vorhanden war.

Was ich gelernt habe ist, dass ich von LUKS mit LVM herzlich wenig verstehe. Hat man ein Problem muss man über sein eigenes System Bescheid wissen, sowas wie den LUKS-Namen habe ich aber bei der Installation nicht beachtet und verstanden. Und bis jetzt ist es für mich schwer, dass Zusammenspiel zwischen LUKS und LVM wirklich zu verstehen oder was im Einzelnen beim Booten Schritt für Schritt abläuft. Warum das Problem auftrat, weiß ich auch nicht. Ich hatte vorher ein Update gemacht, das einen Kernel beinhaltet hat, aber ich weiß nicht, ob das der Grund ist. Ansonsten habe ich aber vor dem Problem nichts am System geändert.

Nochmal einen herzlichen Dank anfrostschutz für deine Hinweise, ohne die ich das Problem nicht verstanden und lösen können hätte.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7795

Der Name ist an sich wurscht, darf nur nicht mit was anderem kollidieren und du hast halt irgendwie den Namen genommen den das (vermutl. verschlüsselte) VG-LV hat. Wenn durch die Änderung das Problem gelöst wurde, und alles wieder geht, um so besser...

Antworten |