grub und luks

[The Hit-Man]

Ich mußte mein Rechner zurücksichern. Das hat auch wunderbar geklappt. Die Platte hat eine /boot Partition und eine verschlüsselte root Partition.
Ich gehe dann per Debian-Rettung oder grml per chroot auf die Platte. Vorher habe ich natürlich die root Partition entschlüsselt.
Nun möchte ich einfach per

Code: Alles auswählen

grub-install /dev/sda

den Grub neu installieren. Da gibts auch keine Fehlermeldung. Aber er nimmt leider in seiner .conf Datei immer die UUID der entschlüsselten root Partition und muß doch die UUID von der verschlüsselten Partition nehmen denn sonst wartet er beim booten auf die falsche UUID. Ich muß dem Grub also bei bringen, wie er die verschlüsselte root Platte nimmt.
Achja, ich benutze kein LVM oder so was, nur eine /boot Partition und die besagte verschlüsselte root Partition.

Hat da jemand nen Tip?

[Livingston]

Wenn /dev/sda die Platte ist, in der sich die luks-Partition befindet, ist das schon generell richtig.
Du solltest aber lieber von einer chroot-Umgebung aus grub neu installieren, damit die Abhängigkeiten und Installationsorte vom bestehenden System berücksichtigt werden.
1.

Code: Alles auswählen

cryptsetup luksOpen /dev/sda<Partitionsnummer> <irgendeinname>

2.

Code: Alles auswählen

mount /dev/mapper/<irgendeinname> /mnt

3. Vor dem chroot Einbinden der wichtigsten Pseudodateisysteme, damit vorhandene Geräte der chroot-Umgebung bekannt gemacht werden können:

Code: Alles auswählen

root@debian:~# mount -o bind /proc /mnt/proc
root@debian:~# mount -o bind /dev /mnt/dev
root@debian:~# mount -o bind /dev/pts /mnt/dev/pts
root@debian:~# mount -o bind /sys /mnt/sys

4. Rein in die Umgebung:

Code: Alles auswählen

chroot /mnt

5. Darin dann

Code: Alles auswählen

grub-install /dev/sda
update-grub

6. Initramfs möchte wissen, was zu entluksen und zu öffnen ist:

Code: Alles auswählen

update-initramfs -u

7. Anschließend raus mit exit, alles wieder unmounten, luksClose <irgendeinname>, fertig.

[The Hit-Man]

3. Vor dem chroot Einbinden der wichtigsten Pseudodateisysteme, damit vorhandene Geräte der chroot-Umgebung bekannt gemacht werden können:

Code: Alles auswählen

root@debian:~# mount -o bind /proc /mnt/proc
root@debian:~# mount -o bind /dev /mnt/dev
root@debian:~# mount -o bind /dev/pts /mnt/dev/pts
root@debian:~# mount -o bind /sys /mnt/sys

Ich bein davon ausgegangen, das grml-chroot oder auch das RescueSystem vom Debian genau das tut. Kann man dem grub nicht einfach eine UUID mit geben, die root sein soll?

[Livingston]

Hab grad kein grml zur Hand, aber Du kannst ja selbst mit mount anzeigen lassen, ob das schon erledigt ist.
Der Knackpunkt ist, das update-grub die Suche nach Partionskandidaten übernimmt. Da kommt dann der ganze Klapperatismus in /etc/grub.d/ und /etc/default/grub zu tragen, der zugegebenermaßen etwas kryptisch daherkommt.
Am Ende wird daraus dann die eigentliche grub-Konfiguration gebaut, die gewöhnlich /boot/grub/grub.cfg heißt.
Das Kommando grub-install /dev/sda erstellt einen minimalen Boot-Code, der wiederum auf die Partition zugreift, wo /boot/grub/grub.cfg steckt, wo dann die zweite Stufe von grub liegt und die erstellte grub.cfg nutzt.

Du kannst die grub.cfg auch selbst erstellen, aber das kostet Einarbeitungszeit, zum anderen würde das Debian-Paket grub-efi-amd64 bzw. grub-pc (je nachdem, ob du auf UEFI oder BIOS installiert hast) bei jedem Update die Konfiguration wieder überschreiben. Wenn Du das wirklich vorhast, hilft nur intensives Büffeln in

Code: Alles auswählen

info grub

und viel Testen (am besten in einer virtuellen Umgebung) - und einen neuer Thread im Forum.

EDIT:
Fast vergessen: Damit update-grub findet, was es braucht, muss in der chroot-Umgebung auch die /boot-Partition gemountet werden, sonst geht der Aufruf ins Leere.

[The Hit-Man]

@Livingston:
Das hat dann alles so weit geklappt, wie beschrieben. Grml macht dann auch genau diesen chroot. Was mich nen bischen verwirrt ist diese Fehlermeldung ( die ich aber im Griff bekommen habe ):

Code: Alles auswählen

W: ryptsetup: WARNING: target 'root' not found in /etc/crypttab

In der /etc/crypttab steht eigentlich etwas anderes von der Debianinstallation her. Aber genau das was da drin steht, steht auch so weit ich das sehen kann richtig in der /etc/fstab.
/etc/crypttab

Code: Alles auswählen

sda5_crypt UUID=ca20750a-f37e-4bb4-bdff-e9e0e1a70099 none luks,discard

/etc/fstab

Code: Alles auswählen

# /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).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda5_crypt /               ext4    errors=remount-ro 0       1

# /boot was on /dev/sda2 during installation
UUID=e722e010-0421-4d7e-908e-3122816098b7 /boot           ext4    defaults        0       2

Woher hat er die Fehlermeldung mit 'root'? Also wo holt er sich das noch her?

[MSfree]

Was mich nen bischen verwirrt ist diese Fehlermeldung ( die ich aber im Griff bekommen habe ):

Code: Alles auswählen

W: ryptsetup: WARNING: target 'root' not found in /etc/crypttab

Wo siehst du dort eine Fehlermeldung?

[The Hit-Man]

Beim

Code: Alles auswählen

update-initramfs -u

Wenn ich nun root in die /etc/crypttab setze ( also den Namen tausche ) und auch den Namen in der /etc/fstab in root tausche, ist der Fehler weg. Aus dem Grund frage ich mich, wo hat er diesen Devicenamen her wenn in den beiden Dateien doch was ganz anderes steht.

[MSfree]

Wenn ich nun root in die /etc/crypttab setze ( also den Namen tausche ) und auch den Namen in der /etc/fstab in root tausche, ist der Fehler weg.

Nochmal, welcher Fehler?

Ich sehe da nur eine Warnung. Warnung != Fehler.

[The Hit-Man]

Ich sehe da nur eine Warnung. Warnung != Fehler.

Achso, dachte das wäre ein Fehler aber unschön ist sie ja trotzdem.

[The Hit-Man]

Hab jetzt aus Spaß an einem anderen Rechner in der /etc/crypttab und in der /etc/fstab den Devicenamen geändert:

/etc/crypttab:

Code: Alles auswählen

# sda5_crypt UUID=ca20750a-f37e-4bb4-bdff-e9e0e1a70099 none luks,discard
root UUID=ca20750a-f37e-4bb4-bdff-e9e0e1a70099 none luks,discard

/etc/fstab

Code: Alles auswählen

# /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).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# /dev/mapper/sda5_crypt /               ext4    errors=remount-ro 0       1
/dev/mapper/root /               ext4    errors=remount-ro 0       1

# /boot was on /dev/sda2 during installation
UUID=e722e010-0421-4d7e-908e-3122816098b7 /boot           ext4    defaults        0       2

Code: Alles auswählen

update-initramfs -u

update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
cryptsetup: WARNING: target 'sda5_crypt' not found in /etc/crypttab
W: Couldn't identify type of root file system for fsck hook

Also der /dev/mapper/sda5_crypt Eintrag, macht keine Probleme. Ob der Rechner dann überhaupt startet?

[The Hit-Man]

So... Rechner fährt dann nicht mehr hoch ... Wenn man das ganze im LiveBetrieb macht, gehts in die Hose. Da ich ja jetzt das System wieder retten mußte ( grml ) ... in der chroot-Umgebung gabs dann keine Fehler und es konnte nach dem

Code: Alles auswählen

update-initramfs -u

wieder ganz normal gebootet werden ... Trotzdem komisch

[Livingston]

Könnte sein, dass grml andere Namen für die entschlüsselte Partition unter /dev/mapper vorsieht, als das bei der normalen Debian-Installation üblich ist. Bei mir heißt die Partition z.B. /dev/mapper/sda3_crypt, grml nennt sie aber bei Dir /dev/mapper/root, wenn Du vom grml-Stick bootest.

Wenn Du dann update-initramfs aufrufst, checkt der Befehl, welches die zu entschlüsselnde Partition ist und trägt diese in der initrd-internen crypttab ein. Beim Booten des reparierten Systems wird dann innerhalb der initrd die Partion aufgesperrt (d.h. das Ding führt ein cryptsetup luksOpen ... durch), und erzeugt für sie den Eintrag /dev/mapper/root. Dieser Name beisst sich nun aber mit den alten Einträgen in /etc/crypttab und/oder /etc/fstab des Hauptsystems.

Die Verwirrung entsteht also dadurch, das in fstab, crypttab und innerhalb der initrd-internen crypttab unterschiedliche Einträge stehen.
Ich könnte das nochmal in einer virtuellen Maschine nachstellen, würde aber ein, zwei Tage brauchen, weil ich gerade einiges um die Ohren habe.

[The Hit-Man]

Ahhh... Wart mal. Der devicename kommt von mir selbst. Wenn ich die Platte unter grml entschlüssel um per chroot drauf zugreifen zu können, nenne ich sie immer root. Jetzt weiß ich bescheid, danke ...

[rhHeini]

Die Benennung des entschlüsselten Devices in der crypttab muss sich in /dev/mapper wiederfinden und geht auch in die initrd ein, dazu wird die crypttab ausgelesen. Das muss konsitent sein.

Wenn man also zur Rettung chrootet muss man den gleichen Namen wie in der Ziel-crypttab verwenden, sonst geht es schief.