cryptsetup: lvm is not available

[Baysa]

Hallo,

mein debian 8 wiil jetzt nicht mehr starten. Beim booten bekomme ich
cryptsetup: lvm is not available

Gestern war mein Rechner beim Herunterfahren hängen geblieben. Dann habe ich einfach mit power knopf ausgeschaltet.
Und heute morgen bekomme ich das.

Ich habe mein swap und home verschlüsselt.
Immer noch kann ich von einem live System die beiden Partition entschlüsseln.
ich konnte nicht hilfreiches nach googlen finden.

Bitte Hilft

[NAB]

Das klingt so ähnlich wie dieses Problem:
viewtopic.php?f=37&t=160471

[debianoli]

Richtig, liest sich ziemlich genau wie bei meinem Fall.

Also, zuerst Live-CD starten. Damit du wieder hochfahren kannst, solltest zuerst die Einträge für swap in der /etc/crypttab und /etc/fstab auskommentieren. Richtig hinbiegen kannst du es dann, wenn der Rechner wieder läuft.

Dann musste ich zusätzlich initramfs/Grub etc richten. Am einfachsten machst du das von der Live-CD aus so:

Code: Alles auswählen

mkdir MP
mount /dev/deine_system_partition MP
mount --bind /dev MP/dev
mount --bind /sys MP/sys
mount --bind /proc MP/proc
chroot MP
dpkg-reconfigure linux-image

Und dann Reboot.

Ediit:

Poste bitte die Ausgabe von lsblk, cat /etc/crypttab und cat /etc/fstab

[Baysa]

/etc/cryptab

Code: Alles auswählen

sda6_crypt UUID=4f30a2fc-32d1-437d-8788-ec26b8550b2c none luks, swap
sda7_crypt UUID=edbdb3c8-ce0d-4318-acb3-770688e8f1ce none luks

fstab

Code: Alles auswählen

UUID=75f70aa7-2014-43e8-8261-46933613b218 /                ext4    errors=remount-ro 0      1
/dev/mapper/sda7_crypt        /home                 ext4                  defaults       0       2
/dev/mapper/sda6_crypt        none                swap      sw       0         0

[debianoli]

Das ist das gleiche wie in meinem Fall aus viewtopic.php?f=37&t=160471

Bring mal dein System zum Laufen, dann kannst du dein Swap wieder zum Leben erwecken. Dazu muss der Swap-Eintrag in der crypttab raus und du kannst dann auf der Partition mit mkswap ein Swap anlegen. Später noch die UUID in der crypttab richten und Swap in der fstab wieder zum Leben erwecken.

[Baysa]

also habe ich swap auskommentiert und system gemounted wie du geschrieben hast.
Leider kann ich weiter nicht gehen.

[debianoli]

Sorry, da fehlte noch ein Hinweis für das dpkg-reconfigure der richtigen Kernel-Version.

Fahre den Rechner wieder mit Live-System hoch und dann das gleiche Spiel wie oben:

Code: Alles auswählen

mkdir MP
mount /dev/deine_system_partition MP
mount --bind /dev MP/dev
mount --bind /sys MP/sys
mount --bind /proc MP/proc
chroot MP
dpkg -l | grep linux-image

Da erhältst du dann als Ausgabe was wie das da:

Code: Alles auswählen

dpkg -l | grep linux-image
ii  linux-image-3.16.0-0.bpo.4-amd64                            3.16.7-ckt9-3~deb8u1~bpo70+1         amd64        Linux 3.16 for 64-bit PCs
ii  linux-image-3.16.0-4-amd64                                  3.16.7-ckt25-2                       amd64        Linux 3.16 for 64-bit PCs
ii  linux-image-amd64                                           3.16+63                              amd64        Linux for 64-bit PCs (meta-package)

Jetzt machst du ein dpkg-reconfigure für den richtigen Kernel (falls du mehrere hast, eben für alle bei dir installierten). Also so:

Code: Alles auswählen

dpkg-reconfigure linux-image-3.16.0-0.bpo.4-amd64
dpkg-reconfigure  linux-image-3.16.0-4-amd64  

[Baysa]

Danke, auf jedem Fall habe ich gebooted.

ich bekomme jetzt
cryptsetup: cryptsetup failed, bad password or options?

bestimmt wegen neue swap partition?

[debianoli]

Ja, das ist der Grund. Kommentier einfach die Swap Einträge in der Crypttab und in der fstab aus. Dann Hochfahren und die Swap Partition mit cryptsetup formatieren und mit cryptsetup open einbinden. Nun machst du mkswap mit der geöffneten zukünftigen Swap Partitionen. Dann die UUID in die Crypttab eintragn und den fstab Eintrag anpassen.

[multisync]

Hallo zusammen!

Ich habe diesen Thread ueber Google gefunden, da ich von dem Problem ebenfalls betroffen bin.

Ich habe den geposteten Loesungsvorschlag (etwas abgewandelt) angewandt, jedoch besteht das Problem nach wie vor. Mit "etwas angewandt" meine ich, dass ich die geposteten Schritte nicht von einer LiveCD aus ausgefuehrt habe, sondern aus der betroffenen Debian-Installation selbst. Nach vielen vielen "lvm is not available"-Meldungen kam ich naemlich in eine ?Busybox?-Shell, von der aus ich mit Ctrl+D den Bootvorgang fortsetzen konnte. Debian startete dann, allerdings ohne swap. Swap in crypttab und fstab auskommentiert und reboot welcher dann unauffaellig verlief.

Nach dem Neustart habe ich anschlieszend folgende Schritte in geposteter Reihe ausgefuehrt:
(Entschuldigt meine seltsamen Umlaute, aber ich habe keine deutsche Tastatur gerade.)

Code: Alles auswählen

manuel@manuelthinkpad:~$ lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda              8:0    0 238,5G  0 disk  
├─sda1           8:1    0   260M  0 part  /boot/efi
├─sda2           8:2    0    16M  0 part  
├─sda3           8:3    0  59,6G  0 part  
├─sda4           8:4    0  1000M  0 part  
├─sda5           8:5    0   953M  0 part  /boot
├─sda6           8:6    0   7,9G  0 part  
├─sda7           8:7    0  18,6G  0 part  
│ └─sda7_crypt 254:0    0  18,6G  0 crypt /
└─sda8           8:8    0 150,2G  0 part  
  └─sda8_crypt 254:1    0 150,2G  0 crypt /home

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sda6
[sudo] password for manuel: 

WARNING!
========
This will overwrite data on /dev/sda6 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo cryptsetup luksOpen /dev/sda6 sda6_crypt
Enter passphrase for /dev/sda6: 

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo mkswap /dev/mapper/sda6_crypt 
Setting up swapspace version 1, size = 7,9 GiB (8497655808 bytes)
no label, UUID=0f1ef890-a6fc-4c46-9ae1-8bddf8078495

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo swapon /dev/mapper/sda6_crypt

Hier habe ich dann die oberste Zeile der crypttab ent-auskommentiert und die UUID angepasst. Endprodukt:

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo cat /etc/crypttab 
sda6_crypt UUID=0f1ef890-a6fc-4c46-9ae1-8bddf8078495 none luks,swap
sda7_crypt UUID=0c1cb6b9-c62b-46e2-95b8-0a89ffbfc6d0 none luks
sda8_crypt UUID=d70472ed-ea42-4f3b-a7a0-5bfc97dd07e0 none luks

In der fstab habe ich die unterste Zeile ent-auskommentiert:

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo cat /etc/fstab
# /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/sda7_crypt /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda5 during installation
UUID=85f70d48-b916-46fa-a679-278a82985daf /boot           ext4    defaults        0       2
# /boot/efi was on /dev/sda1 during installation
UUID=0091-28C0  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/sda8_crypt /home           ext4    defaults        0       2
/dev/mapper/sda6_crypt none            swap    sw              0       0

Code: Alles auswählen

manuel@manuelthinkpad:~$ dpkg -l | grep linux-image
rc  linux-image-3.16.0-4-amd64            3.16.36-1+deb8u2                     amd64        Linux 3.16 for 64-bit PCs
ii  linux-image-4.7.0-1-amd64             4.7.8-1                              amd64        Linux 4.7 for 64-bit PCs (signed)
ii  linux-image-4.9.0-1-amd64             4.9.6-3                              amd64        Linux 4.9 for 64-bit PCs (signed)
ii  linux-image-amd64                     4.9+78                               amd64        Linux for 64-bit PCs (meta-package)

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo dpkg-reconfigure linux-image-4.7.0-1-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.7.0-1-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-4.9.0-1-amd64
Found initrd image: /boot/initrd.img-4.9.0-1-amd64
Found linux image: /boot/vmlinuz-4.7.0-1-amd64
Found initrd image: /boot/initrd.img-4.7.0-1-amd64
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Found Ubuntu 16.10 (16.10) on /dev/sda3
Adding boot menu entry for EFI firmware configuration
done

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo dpkg-reconfigure linux-image-4.9.0-1-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-1-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-4.9.0-1-amd64
Found initrd image: /boot/initrd.img-4.9.0-1-amd64
Found linux image: /boot/vmlinuz-4.7.0-1-amd64
Found initrd image: /boot/initrd.img-4.7.0-1-amd64
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Found Ubuntu 16.10 (16.10) on /dev/sda3
Adding boot menu entry for EFI firmware configuration
done

Meinem Verstaendnis nach haetten diese Schritte das Problem beheben muessen. Dass das nicht der Fall war, zeigt, dass ich irgendwas noch nicht ganz durchblickt habe. Koennt ihr mir weiterhelfen? Swap benoetige ich nicht unbedingt, ich koennte (und tue einstweilen auch) swap einfach abschalten. Ich moechte aber trotzdem verstehen, weshalb die von mir geposteten Schritte nicht zum Erfolg gefuehrt haben. Einfach, um zu lernen. Ich musste beruflich auf GNU/Linux umsteigen, habe allerdings Gefallen daran gefunden und moechte auch die Hintergruende verstehen, anstatt einfach nur blind Befehle abzutippseln.

Danke!
LG Manuel

[breakthewall]

Hallo zusammen!

Ich habe diesen Thread ueber Google gefunden, da ich von dem Problem ebenfalls betroffen bin.

Meinem Verstaendnis nach haetten diese Schritte das Problem beheben muessen. Dass das nicht der Fall war, zeigt, dass ich irgendwas noch nicht ganz durchblickt habe. Koennt ihr mir weiterhelfen? Swap benoetige ich nicht unbedingt, ich koennte (und tue einstweilen auch) swap einfach abschalten. Ich moechte aber trotzdem verstehen, weshalb die von mir geposteten Schritte nicht zum Erfolg gefuehrt haben. Einfach, um zu lernen. Ich musste beruflich auf GNU/Linux umsteigen, habe allerdings Gefallen daran gefunden und moechte auch die Hintergruende verstehen, anstatt einfach nur blind Befehle abzutippseln.

Ich bin mal ein paar Suchergebnisse durchgegangen, und fand stets denselben Fehler in den Konfigurationen. Nahezu immer wurde versucht die Swap als gewöhnliches LUKS-Volume zu mounten, obwohl eine Swap kein LUKS-Volume sein kann. Eine verschlüsselte Swap wird demnach auch nicht mit einem luksFormat beschrieben, und bekommt ebenso wenig ein fixes Passwort, sondern eine Swap wird stets bei jedem Systemstart zufallsgeneriert neu angelegt. Ein Swap-Dateisystem ist nicht dafür gedacht, wie ein gewöhnliches Volume eingehängt und benutzt zu werden.

Code: Alles auswählen

manuel@manuelthinkpad:~$ sudo cat /etc/crypttab
sda6_crypt UUID=0f1ef890-a6fc-4c46-9ae1-8bddf8078495 none luks,swap

Hier ist die Kombination von luks mit swap schon falsch. Eine Swap kann nicht als LUKS-Volume genutzt werden. Schon der Eintrag swap definiert laut "man crypttab", dass die Swap bei jedem Systemstart neu generiert wird. Warum sollte man dann die Swap selbst gleich zweimal formatieren und im Anschluss aktivieren, wenn das Volume beim nächsten Systemstart sowieso wieder überschrieben wird? Das passt nicht so recht zusammen.

Normal sollte eine Swap zunächst angelegt werden, wie eine gewöhnliche Partition oder ein LVM-Volume fixer Größe. Man muss hier nichts weiter formatieren, wenn sie verschlüsselt werden soll. Deine Einträge hinsichtlich der Swap, müssten in der fstab und der crypttab korrigiert werden. Das Swap-Volume würde ich vorsorglich auch neu formatieren.

Code: Alles auswählen

mkfs.ext4 /dev/sda6

fstab:

Code: Alles auswählen

/dev/mapper/swap none            swap    sw              0       0

crypttab:

Code: Alles auswählen

swap /dev/sda6 /dev/urandom cipher=aes-xts-plain64,size=256,swap

Nun muss die Init aktualisiert werden:

Code: Alles auswählen

update-initramfs -u -k all

Damit wird sda6 bei jedem Systemstart via zufallsgeneriertem Passwort neu verschlüsselt, dann via mkswap formatiert und dann direkt eingehängt. Das hat die positive Eigenschaft, dass die Daten einer Swap nach jedem Neustart für immer verloren wären.

[multisync]

Hallo breakthewall,

was du schreibst klingt einleuchtend und nachvollziehbar. Danke für die Erklärung!

Kannst du dir erklaeren, weshalb es mit meinen falschen crypttab- und fstab-Einträgen so lange funktioniert hat? Was hat sich durch die dreimalige falsche Passworteingabe genau verändert, dass es früher schon ging, und jetzt nicht mehr?

Nachtrag: Haben die von dir geposteten Einstellungen Auswirkungen auf die Funktionsweise von Hibernate? Ich meine gelesen zu haben, dass manche Kryptographie-Einstellungen inkompatibel dazu wären.

[breakthewall]

Hallo breakthewall,

was du schreibst klingt einleuchtend und nachvollziehbar. Danke für die Erklärung!

Kannst du dir erklaeren, weshalb es mit meinen falschen crypttab- und fstab-Einträgen so lange funktioniert hat? Was hat sich durch die dreimalige falsche Passworteingabe genau verändert, dass es früher schon ging, und jetzt nicht mehr?

Was heisst es hat funktioniert? War das nachweislich sicher oder bist nur davon ausgegangen alles wäre in Ordnung? Ansonsten schwierig zu sagen warum es so hätte funktionieren sollen. Für gewöhnlich ist eine Swap auf diese Weise defekt. Und hinsichtlich der Passworteingabe ist das ziemlich dubios. Normalerweise verändert das so überhaupt nichts. Vor einiger Zeit wurde nach dreimaliger Falscheingabe schlicht neu gestartet, und inzwischen wird lediglich ein 60 Sekunden Delay forciert. Doch es tritt keine Veränderung ein hinsichtlich der Konfiguration, was eher wirkt als wären hier anderweitige ernste Probleme im Spiel. Nur um das herauszufinden, müsste man deinen PC auseinander nehmen, bzw. wissen was alles so getan hast in deinem installierten System, und zwar über den gesamten Zeitraum bis der Fehler kam. Das würde auch die ganzen Logs etc. mit einschliessen. Ein übliches Verhalten ist das jedenfalls nicht, was man an den extrem geringen Informationen im Netz erkennen kann. Und möglicherweise wurde auch nutzerseitig etwas getan was dazu führte.

Nachtrag: Haben die von dir geposteten Einstellungen Auswirkungen auf die Funktionsweise von Hibernate? Ich meine gelesen zu haben, dass manche Kryptographie-Einstellungen inkompatibel dazu wären.

Also negative Auswirkungen haben sie nicht, ausser das es generell keine gute Idee ist, Ruhezustand und Verschlüsselung zu kombinieren. Denn der Schlüssel für die Daten liegt stets im Arbeitsspeicher ab Systemstart, und bein Ruhezustand werden genau jene Inhalte auf den Datenträger geschrieben. Und das wäre im kryptographischen Sinne eine Sicherheitslücke, die unter Umständen ausgenutzt werden könnte. Würde nicht empfehlen Standby noch Ruhezustand zu nutzen, wenn Sicherheit wirklich Priorität hat.