[gelöst]Woher erhält update-initramfs diese "alte" UUID?

[halo44]

Ich hoffe, daß ich das richtige Unterforum gewählt habe. Sonst bitte verschieben.

Die Festplatte auf der sich meine Root- und Homepartition befinden wollte ich wechseln, d.h. einen neuen Datenträger einsetzen.

Ich habe die neue Platte an einen freien Sata-Port angeschlossen, über Gparted eine Msdos-Partitionstabelle erstellt und die Partitionen für Root, Home, Swap und Extended eingerichtet. Danach die Root- und die Homepartition, die ich vorher mit rsync auf externe Festplatte gesichert hatte, ebenfalls mit rsync auf die neuen Partitionen geladen.

Anschließend habe ich die neue Rootpartition auf /mnt gemountet und in deren /boot/grub/grub.cfg die neue UUID eingestellt. Auch die /etc/fstab und die /etc/initramfs-tools/conf.d/resume habe ich mit den neuen UUIDs versorgt.

Jetzt den Rechner runtergefahren, die alte Platte abgehängt und die neue an den anderen Sata-Port angeschlossen. Danach habe ich den Rechner vom USB-Live-Stick gebootet und den Bootloader auf der neuen /dev/sda erstellt (grub-install und update-grub).

Dann den Rechner von /dev/sda gestartet, wobei der Bootvorgang abbrach und meldete

gave up waiting for suspend/resume device

Nachdem ich die "alte" Festplatte wieder an einen freien SATA-Port angeschlossen hatte, lief der Start durch.

Zwar wurde die richtige Swap-Partition, die auch in der /etc/initramfs-tools/conf.d/resume
und der /etc/fstab eingetragen war benutzt, aber das System wollte offensichtlich auch die „zweite“
Swap-Partition zumindest finden.

Beim Versuch die Situation zu bereinigen erhielt ich

Code: Alles auswählen

update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.9.0-6-amd64
cryptsetup: WARNING: found more than one resume device candidate:
                     29011482-acf2-4af2-acc9-637bbbc36ab7
                     c29f9a07-7664-4024-9131-0fe16c7a397d

Ich habe dann die zweite Swap-Partition auf der „alten“ Systemplatte gelöscht und die Platte abgehängt.

Nach erneutem grub-install /dev/sda und update-grub und Neustart mit abgehängter alter Systemplatte
startete das System jetzt problemlos.

Allerdings erhalte ich den Hinweis auf die mehrfach vorhandenen resume device candidaten immer
noch, wenn ich update-initramfs -u probeweise durchführe.

Zwar läuft mein System ohne Probleme, aber ich wüßte doch gern woher update-initramfs die UUID der "alten" Swappartition (übrigens die erste oben 29011482- usw.) erhält.

Hier komme ich allerdings deutlich an meine Grenzen und bedanke mich für jede Hilfe.

Gruss H.

[schorsch_76]

Es könnte noch in /etc/default/grub eine UUID eingetragen sein.

[halo44]

Danke für den Hinweis. Nein, es ist keine eingetragen:

GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

Gruss H.

[schorsch_76]

/etc/crypttab ??

Hast du noch die Ausgabe von

Code: Alles auswählen

blkid

und von

Code: Alles auswählen

lsblk

[halo44]

Gerne, hier die Ausgaben

Code: Alles auswählen

/dev/sda1: LABEL="debian-root" UUID="118c2379-d650-48f4-a509-2ff8e4bb4e0c" TYPE="ext4" PARTUUID="a572fe79-01"
/dev/sda2: LABEL="debian-home" UUID="1d19895d-7fa2-40f7-8e14-becc327b5053" TYPE="ext4" PARTUUID="a572fe79-02"
/dev/sda3: UUID="c29f9a07-7664-4024-9131-0fe16c7a397d" TYPE="swap" PARTUUID="a572fe79-03"
/dev/sda5: UUID="46a400cd-8c32-4548-9d28-0f1a4dff83b3" TYPE="crypto_LUKS" PARTUUID="a572fe79-05"
/dev/sda6: LABEL="pclos-root" UUID="56328d10-d347-4c15-af68-02584e500137" TYPE="ext4" PARTUUID="a572fe79-06"
/dev/sda7: LABEL="pclos-home" UUID="b08a72d7-f0b6-4cef-a457-0a84c1add920" TYPE="ext4" PARTUUID="a572fe79-07"
/dev/sda8: LABEL="div-root" UUID="45d5d29c-5af9-41cf-b709-a48721e6a308" TYPE="ext4" PARTUUID="a572fe79-08"
/dev/sda9: LABEL="div-home" UUID="a637fb0e-5bc2-4a04-b8fc-ab90e8c71ee6" TYPE="ext4" PARTUUID="a572fe79-09"
/dev/sdb1: UUID="18c1ec6e-7b16-4fc3-909b-0a30f439c005" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="9fd6310f-6b05-46a5-b0e9-7a7befad0b33"
/dev/sdb2: LABEL="Daten-1" UUID="dd03a64b-a64c-4810-a8ab-69b398f36e05" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="614a7788-ccf3-445c-896b-efe9777c2574"
/dev/sdb3: LABEL="Daten-2" UUID="722b10b5-f196-48a4-9b58-b3e8c9694635" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="7229ba50-c9b8-4537-b9fe-70323d74b44d"
/dev/sdb4: LABEL="Daten-Sicherung" UUID="67977c3a-ae1a-4d07-929f-eac938acf480" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="01b76aa8-1518-432c-b839-92aa33f6ee6b"
/dev/sdb5: LABEL="Daten-Filme" UUID="f2bfeb79-4113-425b-98eb-506e5d3c86ad" TYPE="ext4" PARTUUID="83743705-9910-4cc0-ae34-29fd86beed01"
/dev/sdc1: LABEL="ohne_bezeichnung" UUID="49e653d7-5356-4acf-8949-3bef58050d94" TYPE="ext4" PARTUUID="0776c23e-01"
/dev/mapper/_datenpartition: UUID="6a6c659f-7b4a-4ee4-aa26-c20428cc6f78" TYPE="ext4"
/dev/mapper/_lokalsicherung: UUID="57239594-458f-4eb0-ac43-c8e1ab5ba714" TYPE="ext4"

NAME                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                   8:0    0 223,6G  0 disk  
├─sda1                8:1    0    15G  0 part  /
├─sda2                8:2    0     5G  0 part  /home
├─sda3                8:3    0     8G  0 part  [SWAP]
├─sda5                8:5    0    82G  0 part  
│ └─_lokalsicherung 254:1    0    82G  0 crypt /lokalsicherung
├─sda6                8:6    0    10G  0 part  
├─sda7                8:7    0     5G  0 part  
├─sda8                8:8    0    10G  0 part  
└─sda9                8:9    0     5G  0 part  
sdb                   8:16   0 465,8G  0 disk  
├─sdb1                8:17   0    12G  0 part  
│ └─_datenpartition 254:0    0    12G  0 crypt /Datenpartition
├─sdb2                8:18   0    40G  0 part  /Daten-1
├─sdb3                8:19   0    50G  0 part  /Daten-2
├─sdb4                8:20   0    50G  0 part  
└─sdb5                8:21   0   300G  0 part  
sdc                   8:32   1   7,5G  0 disk  
└─sdc1                8:33   1   7,5G  0 part  
sr0                  11:0    1  1024M  0 rom

Gruss H.

[schorsch_76]

Da fällt mir noch was ein

Die initramfs wird normalerweise nur geupdatet. mach mal ein

Code: Alles auswählen

update-initramfs -k all -d
update-initramfs -k all -c

Damit löscht du zuerst deine alte initramfs und erstellst anschliessend die komplett neue initramfs.

[KBDCALLS]

Möglich das Systemd da seine Finger mit drinn hat. Existieren Units in denen auf die fehlerhafte UUID verwiesen wird. ?

[halo44]

Möglich das Systemd da seine Finger mit drinn hat. Existieren Units in denen auf die fehlerhafte UUID verwiesen wird. ?

Nein, es existieren keine, auf die das zutrifft.

Gruss H.

[halo44]

Da fällt mir noch was ein

Die initramfs wird normalerweise nur geupdatet. mach mal ein

Code: Alles auswählen

update-initramfs -k all -d
update-initramfs -k all -c

Damit löscht du zuerst deine alte initramfs und erstellst anschliessend die komplett neue initramfs.

Danke, werde ich in etwa einer Stunde versuchen. Gleich starten meine automatischen Datensicherungen auf lokale Partitionen und auf mein NAS. Da möchte ich nicht dazwischen funken.

Gruss H.

[halo44]

So da bin ich wieder. Das Löschen der initramfs hat offensichtlich funktioniert:

Code: Alles auswählen

update-initramfs -k all -d
update-initramfs: Deleting /boot/initrd.img-4.9.0-6-amd64

Aber das Neuerstellen nicht, auf mein

Code: Alles auswählen

update-initramfs -k all -c

kommt der Prompt ohne Fehlermeldung zurück, allerdings wurde keine neue initrd.img erstellt. Sie bleibt gelöscht. Ich kann zwar noch in der laufenden Session arbeiten, werde allerdings vor einem Neustart den Bootloader neu erstellen müssen.

Gruss H.

[Tintom]

Gib update-initramfs noch den Schalter -v mit, dann wird's gesprächiger.

[KBDCALLS]

Oder mkinitramfs direkt aufrufen.

[owl102]

Oder den Partitionen auf der neuen Platte die gleichen UUIDs geben? (Und den Partitionen auf der alten Platte natürlich neue UUIDs geben.)

P.S.: Ich weiß, das ist die unsportliche Lösung.

[halo44]

Gib update-initramfs noch den Schalter -v mit, dann wird's gesprächiger.

Ja, ist so:

Code: Alles auswählen

update-initramfs -v -k all -c
Available versions: 
Nothing to do, exiting.

Allerdings stimmt das nicht. Es ist keine initrd.img mehr vorhanden.

Gruss H.

[halo44]

Oder mkinitramfs direkt aufrufen.

Auch das bringt:

Code: Alles auswählen

mkinitramfs -o initrd.img-4.9.0-6-amd64 
cryptsetup: WARNING: found more than one resume device candidate:
                     29011482-acf2-4af2-acc9-637bbbc36ab7
                     c29f9a07-7664-4024-9131-0fe16c7a397d

Gruss H.

[KBDCALLS]

Da schon mal reingeschaut.

• /etc/initramfs-tools/conf.d/resume

[halo44]

Oder den Partitionen auf der neuen Platte die gleichen UUIDs geben? (Und den Partitionen auf der alten Platte natürlich neue UUIDs geben.)

P.S.: Ich weiß, das ist die unsportliche Lösung.

Danke für die Idee, aber die alte Platte ist bereits ausgebaut.

Ich hätte ja nichts gegen eine unsportliche Lösung, aber es muß doch möglich sein eine neue initrd.img zu erstellen, was aber anscheinend nur über eine Neuerstellung des Bootloaders gelingt. Woher der dann aber die alte UUID nimmt, ist das große Rätsel.

Gruss H.

[KBDCALLS]

Oder den Partitionen auf der neuen Platte die gleichen UUIDs geben? (Und den Partitionen auf der alten Platte natürlich neue UUIDs geben.)

P.S.: Ich weiß, das ist die unsportliche Lösung.

Danke für die Idee, aber die alte Platte ist bereits ausgebaut.

Ich hätte ja nichts gegen eine unsportliche Lösung, aber es muß doch möglich sein eine neue initrd.img zu erstellen, was aber anscheinend nur über eine Neuerstellung des Bootloaders gelingt. Woher der dann aber die alte UUID nimmt, ist das große Rätsel.

Gruss H.

Scheinbar wohl nicht. Anscheinend hat der Bootloader damit nix zu tun.

[Tintom]

Gib update-initramfs noch den Schalter -v mit, dann wird's gesprächiger.

Ja, ist so:

Code: Alles auswählen

update-initramfs -v -k all -c
Available versions: 
Nothing to do, exiting.

Allerdings stimmt das nicht. Es ist keine initrd.img mehr vorhanden.

Gruss H.

In dem Fall mal anstelle von all `uname -r` probieren. Tut sich dann was?

[halo44]

... In dem Fall mal anstelle von all `uname -r` probieren. Tut sich dann was?

Leider nein:

Code: Alles auswählen

update-initramfs -v -k `uname -r` -c
/boot/initrd.img-4.9.0-6-amd64 already exists, cannot create.

Sie existiert nicht, zumindest nicht in /boot.

Gruss H.

[halo44]

Ich muß jetzt kurz zurückrudern. Die initrd.img ist jetzt doch da. Sie wurde um 18:16 erstellt. Ich muß jetzt feststellen mit welchem Befehl sie erstellt wurde.

Ich melde mich dann.

Gruss H.

[halo44]

Wenn ich das zeitlich abgleiche, wurde die initrd.img hiermit erstellt, wobei auch hier die alte UUID angezogen wurde:

Code: Alles auswählen

mkinitramfs -o initrd.img-4.9.0-6-amd64 
cryptsetup: WARNING: found more than one resume device candidate:
                     29011482-acf2-4af2-acc9-637bbbc36ab7
                     c29f9a07-7664-4024-9131-0fe16c7a397d

Ich weiß immer noch nicht, wer diese UUID präsentiert.

Gruss H.

Edit: ich kann auch nicht verstehen, was cryptsetup damit zu tun hat.

[KBDCALLS]

Wenn ich das zeitlich abgleiche, wurde die initrd.img hiermit erstellt, wobei auch hier die alte UUID angezogen wurde:

Code: Alles auswählen

mkinitramfs -o initrd.img-4.9.0-6-amd64 
cryptsetup: WARNING: found more than one resume device candidate:
                     29011482-acf2-4af2-acc9-637bbbc36ab7
                     c29f9a07-7664-4024-9131-0fe16c7a397d

Ich weiß immer noch nicht, wer diese UUID präsentiert.

Gruss H.

Edit: ich kann auch nicht verstehen, was cryptsetup damit zu tun hat.

Sieh dir mal de Config an die ich dir genannt habe.

[halo44]

... Sieh dir mal de Config an die ich dir genannt habe.

Wenn Du die meinst "/etc/initramfs-tools/conf.d/resume", dann findet sich dort

Code: Alles auswählen

RESUME=UUID=c29f9a07-7664-4024-9131-0fe16c7a397d

also die richtige UUID, wie ich auch schon im Eröffnungspost schrieb:

Anschließend habe ich die neue Rootpartition auf /mnt gemountet und in deren /boot/grub/grub.cfg die neue UUID eingestellt. Auch die /etc/fstab und die /etc/initramfs-tools/conf.d/resume habe ich mit den neuen UUIDs versorgt.

Gruss H.

[Tintom]

Nächster Schuss ins Blaue: Existiert die Datei /etc/suspend.conf oder /etc/uswsusp.conf?