staging.inyokaproject.org

Moin, ich hatte gestern Abend einen Smartfehler 5 auf meiner letzten HDD, der Linux Systemplatte. Kein Problem hab ich mir gedacht. Ersatz SSD is ja wegen Kapazitätserweiterung eh schon da. Habe mir also wie beim letzten Festplattenumzug meinen Clonezilla USB Stick geschnappt, alle anderen Platten abgeklemmt damit mir auch ja nix schief geht und ich die falsche Platte überschreibe und hab als Disk->Disk von der alten Seagate als Quelle auf die neue Samsung SSD als Ziel alles kopieren lassen. Das Tool hat brav nach dem Passwort für die LUKS Verschlüsselte VolumeGroup gefragt, es hat ne Weile gedauert. Keine Fehlermeldungen , klasse.

Nu hab ich die Quellplatte abgeklemmt, die neue angesteckt. Alle anderen SSDs wieder verkabelt und wollte mich an der neuen Geschwindigkeit berauschen. Allerdings kommt beim Start der Linux Partition nur noch eine müde Shell auf der Initramfs steht und nu steck ich fest.

Sollte es nich wie sonst nahtlos weitergehen da ich eine 1 zu 1 kopie gemacht habe?

Moin frostgram

Das Tool hat brav nach dem Passwort für die LUKS Verschlüsselte VolumeGroup gefragt

Diese Passwortabfrage hätte mich jetzt bei einem 1:1 Klon (Disk-to-Disk) stutzig gemacht. Beim Klonen wird ja einfach bit-genau der Inhalt auf die neue Platte geschrieben, dafür muss clonezilla aber nicht in deinen LUKS-Container schauen... Wie genau hast du denn geklont?

Hast du mal den Inhalt der neuen und alten Platte verglichen? (Wenn es so viele sind kommentiere vielleicht kurz um welche es geht)

sudo fdisk --list

Grüße

san04

Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EC354871-766F-4D0D-A902-FD268C6D66B5

Device       Start        End    Sectors   Size Type
/dev/sda1     2048    1050623    1048576   512M EFI System
/dev/sda2  1050624    2549759    1499136   732M Linux filesystem
/dev/sda3  2549760 1953523711 1950973952 930.3G Linux filesystem


Disk /dev/sdb: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST31000528AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EC354871-766F-4D0D-A902-FD268C6D66B5

Device       Start        End    Sectors   Size Type
/dev/sdb1     2048    1050623    1048576   512M EFI System
/dev/sdb2  1050624    2549759    1499136   732M Linux filesystem
/dev/sdb3  2549760 1953523711 1950973952 930.3G Linux filesystem

Das sind die beiden Kandidaten

Auf keinen Fall und zu keiner Zeit darf man nach einer 1:1-Kopie Original und Kopie gleichzeitig anschließen, weil sonst ja sämtliche UUIDs der Datenträger, der Partitionen und auch der Dateisysteme eben nicht mehr eindeutig sind, sondern garantiert doppelt vorhanden sind.

Nach einer 1:1-Kopie auf einen größeren Datenträger muss auch immer eine GPT-Partitionstabelle auf der Kopie repariert werden. Das geht mit gdisk, welches in den Händen von Unwissenden leicht durch Bedienfehler Schaden verursachen kann. Eine GPT-Partitionstabelle besteht aus einem Datenbereich am Anfang der Platte und einem zweiten Bereich als Backup am Ende der Platte.

Die beiden Platten hatte ich nur zu Vergleichszwecken gleichzeitig angeschlossen und Read-Only eingehängt und von einem USB Stick LiveImage gestartet ☺

Ich hab hier ja noch die Original Platte , die hoffentlich noch etwas durchhält.

Was empfiehlst du als nächsten Schritt?

frostgram schrieb:

[…] Was empfiehlst du als nächsten Schritt?

• Das Handbuch von clonezilla lesen und herausbekommen, was Du eigentlich gemacht hast. Offenbar keine 1:1-Kopie, wie san04 ja schon erklärt hat.

• Die Partitionstabelle der Kopie checken und ggf. reparieren.

• Erklären wie Dein System aufgebaut ist, auch welche physischen Datenträger die Volumegroup bilden und welche logischen Datenträger daraus gebildet werden.

• Wenn init aufgibt und eine shell startet, nennt es auch einen Grund dafür und beschreibt die Situation, in der das passiert.

Du musst schon konkrete Informationen liefern, wenn Dir jemand konkret helfen können soll.

Es ist genau das Device-Device. Aus den Release Notes

Add LUKS support. Basically a better mechanism than dd is implemented. 

Im Prinzip gibt es 3 SSDs, Windows Hauptplatte, kleine 500GB SSD mit Daten, eine 4TB SSD für Spiele. Dazu kommt eine alte Seagate Platte mit Linux die migriert werden soll. Diese Linux Platte hatte ich im Setup als LVM mit LUKS eingerichtet und mit Passwort gesichert. Im Inneren steckt ein Ext Formatierte Kubuntu 22.04.

Ich habe die alte Platte auf die neue SSD kopiert und die Quelle dann abgesteckt und neu gestartet Wenn man den PC startet und das klassische Grub Menü öffnet is alles offenbar in Ordnung, man kann Ubuntu, Windows, memtest auswählen. Allerdings kommt im Ubuntu Menüpunkt nach ner Weile die Shell.

Ich habe mal vorhin ein wenig an der Kopie rumgespielt (Ich glaube die Smartfehler 5,3 helfen auf dem original nimmer)

Ich transkribiere aus dem Ubuntu Start versuch mal grob

Loading essential drivers.. done
Running /scripts/init-premount.. done
Mounting root file system Running /scripts/local-top...
Cannot process volume group kubuntu-vg
volume group kubuntu-vg not found
Cannot process volume group kubuntu-vg
Please Unlock disk sdd3_crypt
sdd3_crypt unlocked successfully
Running /scripts/local-premount
Waiting for suspend/resume
Will now check root file system
fsck from util-linux 2.37.2
/dev/mapper/kubuntu-vg-root contains a file system with errors check forced
Inode 492 has a bad extended attribute block
/dev/mapper/Kubuntu-vgroot UNEXPECTED inconsistency run fsck manually

Wenn ich https://askubuntu.com/questions/653408/mounting-encrypted-luks-partition-from-live-cd be folge kann ich die Daten lesen und das Homeverzeichnis runter ziehen. Insofern müsste die Sache sich eigentlich booten lassen oder nich?

frostgram schrieb:

[…]

/dev/mapper/kubuntu-vg-root contains a file system with errors check forced
Inode 492 has a bad extended attribute block
/dev/mapper/Kubuntu-vgroot UNEXPECTED inconsistency run fsck manually

Du hast offenbar die Ursache für den gestörten Boot von der Originalplatte mit kopiert.

[…] Homeverzeichnis […]

… hat mit dem Boot nichts zu tun.

Insofern müsste die Sache sich eigentlich booten lassen oder nich?

Nein. Der Bootvorgang muss sich keineswegs unlogisch verhalten.

Du kannst natürlich tun und lassen, was Du willst. Die Helfer hier im Forum aber auch. Es macht nur dann Sinn, hier Hilfe zu erwarten, wenn Du auch an der Lösung Deines Problems mitarbeitest.

Die These war, wir haben eine Block der verschlüsselt ist und in dem sich die Daten befinden. Wenn sie sich entschlüsseln lassen müsste die Integrität der umliegenden Roh Daten gut genug sein.

Ich muss mir wohl noch mal die Details anschauen zum Prozess und der Aufteilung der Platte. Das LVM Luks Setup involviert nur diese eine Platte und ist nicht über mehrere aufgebaut. Das sollte die Sache vereinfachen.

So sieht das aus wenn man die Platte via Live System anschaut.

Hallo frostgram,

Dann mach doch bitte mal dies lt. Info:

/dev/mapper/Kubuntu-vgroot UNEXPECTED inconsistency run fsck manually

Gruss Lidux

Damit wären wir dann beim angehängten Bild.

Oha, auch hier wieder Bindestrich vs. zwei Bindestriche beim Device-Mapper. lsblk mit /etc/fstab vergleichen. Im Foto ist es mit zwei Bindestrichen:

• https://media-cdn.ubuntu-de.org/forum/attachments/20/26/9322362-KUbuntuBoot.jpg

In der Fehlermeldung mit nur einem Bindestrich: frostgram schrieb:

Cannot process volume group kubuntu-vg
volume group kubuntu-vg not found
Cannot process volume group kubuntu-vg

lsblk:

1
2
3
4
5
6
7
8

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sdd                                             8:48   0   1,8T  0 disk  
├─sdd1                                          8:49   0   512M  0 part  
├─sdd2                                          8:50   0   732M  0 part  
└─sdd3                                          8:51   0 930,3G  0 part  
  └─luks-d1f4f83e-6cdb-4a01-9559-c82423038b70 253:0    0 930,3G  0 crypt 
    ├─kubuntu--vg-root                        253:1    0 929,3G  0 lvm   
    └─kubuntu--vg-swap_1                      253:2    0   976M  0 lvm   

fstab aus der verschlüsselten Partition:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# /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/kubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdd2 during installation
UUID=39cb6366-f9b0-4e26-b8bc-c3208b2bf3a7 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/sdb2 during installation
UUID=DA34-5558  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/kubuntu--vg-swap_1 none            swap    sw              0       0