initramfs wiederherstellen

[Silberwoelfin]

Hi,

ich hab da so ein klitzekleines, ganzgroßes Problem: nach einem Update des Kernels wollte dieser meine verschlüsselte Festplatte nicht mehr finden und weil ich da sowas gelesen hatte über initramfs und man müsse das neuerstellen, habe ich das natürlich versucht. Leider lief das mit create nicht, weil das ja schon da war. Also habe ich es erst entfernt, was mein PC auch brav gemacht hat, und wollte es dann wieder erstellen. Das hat er aber aus irgendwelchen Gründen nicht gemacht, es gab keinerlei Meldung, weder Fehler- noch Erfolgs-. Darum hab ich rebootet.
Nun das Problem: Das initramfs ist natürlich nicht wieder aufgetaucht. Und jetzt bootet gar nichts mehr.
Kann man das irgendwie mit einer Live-CD wiederherstellen oder neu erstellen? Oder darf ich jetzt schon wieder eine Neuinstallation machen?

Gruss,
Silberwoelfin

[Saxman]

Kann man das irgendwie mit einer Live-CD wiederherstellen oder neu erstellen? Oder darf ich jetzt schon wieder eine Neuinstallation machen?

Du kannst von einer live cd in das system rein chrooten und update-initramfs ausführen.
z.B so

Code: Alles auswählen

update-initramfs -v -u -k all

Für mehr wirf einen Blick in die Manpage.

[Silberwoelfin]

Du kannst von einer live cd in das system rein chrooten

Kannst du mir vielleicht auch noch verraten, wie das geht? Ich versuch das schon nach dieser Anleitung, aber das klappt einfach nicht:

Code: Alles auswählen

ubuntu@ubuntu:~$ sudo mount /dev/mapper/debian-root /mnt
mount: Gerätedatei /dev/mapper/debian-root existiert nicht

Laut ls existiert sie auch tatsächlich nicht, aber vorhin hat sie noch existiert, zumindest mit dem 2.6.26er-Kernel, der 2.6.32er hat sie auch da schon nicht gefunden (und vermutlich deshalb nicht gebootet). Aber wie kann ein Kernel die Datei finden und der andere nicht? Im Abstand von nicht mal 5 Minuten in denen nur in den anderen Kernel gebootet wurde?

Ich bin langsam echt verzweifelt

Silberwoelfin

[Saxman]

Laut ls existiert sie auch tatsächlich nicht, aber vorhin hat sie noch existiert, zumindest mit dem 2.6.26er-Kernel, der 2.6.32er hat sie auch da schon nicht gefunden (und vermutlich deshalb nicht gebootet). Aber wie kann ein Kernel die Datei finden und der andere nicht? Im Abstand von nicht mal 5 Minuten in denen nur in den anderen Kernel gebootet wurde?

Das hat mit den installierten kernel nichts zu tun. Du willst ja pre chroot rein.
Was ist das denn für ein System? dm-crypt? lvm?
Du musst schon etwas mehr schreiben wenn ich dir helfen soll.

/Edit

Im Groben so

Code: Alles auswählen

modprobe dm_crypt
cryptsetup-luks luksOpen /dev/hdaX <devicename>
mount /dev/mapper/<devicename> /mountpoint

und dann per chroot rein.

[Silberwoelfin]

Was ist das denn für ein System? dm-crypt? lvm?
Du musst schon etwas mehr schreiben wenn ich dir helfen soll.

Sorry. Es ist ein LVM. Aber das hat sich jetzt scheinbar eh erledigt, ich habe auf der unverschlüsselten boot-Partition Backup-Files gefunden und die einfach umbenannt. Damit lässt sich zumindest der 2.6.26er-Kernel wieder booten.

Danke.

Aber irgendwas muss es doch mit den Kerneln zu tun haben, wenn ich die Datei bei dem einen Kernel finde und beim anderen nicht? Woran könnte es sonst liegen?

Gruss,
Silberwoelfin

[Saxman]

Aber irgendwas muss es doch mit den Kerneln zu tun haben, wenn ich die Datei bei dem einen Kernel finde und beim anderen nicht? Woran könnte es sonst liegen?

Welche Datei meinst du und was ist das für ein ominöser Kernel?
Meine Glaskugel ist leider gerade im Thread nebenan belegt..

[Silberwoelfin]

Welche Datei meinst du und was ist das für ein ominöser Kernel?

Es geht immer noch um die Gerätedatei /dev/mapper/debian-root. Wenn ich den 2.6.26er-Kernel boote, wird diese Datei problemlos gefunden und der Kernel bootet ganz normal. Wenn ich aber den 2.6.32er-Kernel booten will, kommt nach ewigem warten die Fehlermeldung "/dev/mapper/debian-root does not exist! Dropping to a shell!" und es wird natürlich nicht gebootet. Beides sind die Standard-Kernel aus dem ganz normalen Repo. (Architektur ist normales 32-bit)

Führe ich im bootenden 2.6.26er-Kernel den Befehl "ls /dev/mapper/" aus, so befindet sich dort genannte Gerätedatei. Führe ich denselben Befehl allerdings in der BusyBox-Shell, in die ich nach obiger Fehlermeldung entlassen werde, aus, so befindet sich in dem Verzeichnis nichts.

Mittlerweile hab ich aber gesehen, dass im alten Kernel meine Festplatte hda heißt, im neuen dagegen aber sda genannt wird. Möglicherweise hängt das damit zusammen.
Ich befürchte aber, dass wenn ich den Pfad in /etc/crypttab ändere, ich den alten Kernel nicht mehr booten kann.

Gruss,
Silberwoelfin

[Saxman]

Mittlerweile hab ich aber gesehen, dass im alten Kernel meine Festplatte hda heißt, im neuen dagegen aber sda genannt wird. Möglicherweise hängt das damit zusammen.

Wäre zumindest auch mein erster Tip gewesen.
Das kannst du in der /boot/grub/device.map korrigieren und dann update-grub laufen lassen. Danach sollte 2.6.32 booten.
Zumindest insofern du vorher die initram wieder neu anlegst.

[Silberwoelfin]

Das kannst du in der /boot/grub/device.map korrigieren und dann update-grub laufen lassen.

Das hat irgendwie gar nichts gebracht. In der device.map steht jetzt drin:

Code: Alles auswählen

#(hd0)      /dev/disk/by-id/ata-SAMSUNG-$lange_Zahlenkolonne
(hd0)      /dev/hda

Danach update-grub und update-initramfs -u laufen gelassen. Trotzdem bootet da gar nichts und die Festplatte taucht bei "ls /dev" noch immer nur als sda auf.

[Saxman]

Das kannst du in der /boot/grub/device.map korrigieren und dann update-grub laufen lassen.

Das hat irgendwie gar nichts gebracht. In der device.map steht jetzt drin:

Code: Alles auswählen

#(hd0)      /dev/disk/by-id/ata-SAMSUNG-$lange_Zahlenkolonne
(hd0)      /dev/hda

Danach update-grub und update-initramfs -u laufen gelassen. Trotzdem bootet da gar nichts und die Festplatte taucht bei "ls /dev" noch immer nur als sda auf.

Code: Alles auswählen

(hd0)      /dev/sda

In der Form korrigieren.

[Silberwoelfin]

Code: Alles auswählen

(hd0)      /dev/sda

In der Form korrigieren.

Das gibt leider auch keine Veränderung. (mit erneutem update-grub und -initramfs)

Edit: Es ist aber eine neue Fehlermeldung aufgetaucht, die noch vor der alten kommt:

Code: Alles auswählen

cryptsetup: source device /dev/hda2 not found

Ich weiß aber nicht, wo cryptsetup die Bezeichnung /dev/hda2 her hat, denn in der /etc/crypttab steht die nicht drin, da steht nur die UUID drin.

Edit2: Krass, es funktioniert! Hatte aber offenbar relativ wenig mit der Festplattenbezeichnung zu tun. Ich hab einfach mal das hier gemacht und auf mal bootet es

Trotzdem ein großes Danke für die Hilfe.

Gruss,
Silberwoelfin

[KBDCALLS]

Die UUIDS werden ja auch nur in der /etc/fstab , in der Grubconfig verwendet, wenn dann mit mount abfragt was gemountet worden ist, dann erscheint in der Ausgabe das exhte Device . Also /dev/sda , Nachprüfbar ist das mit

Code: Alles auswählen

cat /etc/mtab

. Die UUIDS , Lablels usw. verwendet man nur um zu verhindern das es Chaos gibt, falls sich der echte Devicename ändert. Als Beispiel beim Wechsel von IDE Treibern auf die Libata Treiber. Dann wird aus /dev/hda ein /dev/sda