Po překopírování systémového disku s dd nenaběhne systém

[karlitos]

Dobry den,

mam jeden starsi pocitac (s Fedorou 22 nebo 23) a chtel jsem z nej stahnout data a nainstalovat nejaky aktualni linux. Puvodni 64GB SSD jsem potreboval na jiny projekt, tak jsem pomoci dd zkopiroval cely disk na novy 128GB SSD disk. Po vlozeni do pocitace mi ale boot skonci v dracut shellu:

Kód: [Vybrat]

Found device Lexar_128GB_SSD system
Found device Lexar_128GB_SSD boot
Started Show Plymouth Boot Screen
Reached target Paths.
Reached target Basic System
dracut-initqueue[274]: Warning: Could not boot.
dracut-initqueue[274]: Warning: /dev/disk/by-uuid/896061ae.... does not exist.
dracut-initqueue[274]: Warning: /dev/disk/by-uuid/23ac3488.... does not exist.

Ten disk je rozpoznan jako zarizeni /dev/sda a jsou na nem 4 oddily, ktere byly na puvodnim disku:

• sda1 - EFI system
• sda2 - ext4 boot
• sda3 - ext4 - to by mel byt puvodni systemovy oddil
• sda4 - swap

Kdyz nastartuji aktualni Fedoru 32, tak mi sudo fdisk -l/b] zobrazi u oddilu /dev/sda3[

Kód: [Vybrat]

/dev/sda3 1435648 108347391 106911744 51G Linux root (x86-64)
sudo fsck /dev/sda3 mi zase zobrazi:

Kód: [Vybrat]

The superblock could not be read or does not describe a correct ext2/ext3/ext4
filesystem.
Tak ted jsem se svou latinou v koncich, budu doufat ze mi zde nekdo poradi co dal. Dekuji

[Reklama]

[Jan Fikar]

podle toho posledního výpisu není sda3 ext4, asi je to špatně nakopírované? jak jste to kopíroval?

to taky odpovídá hlášení dracut, že nemůže najít /dev/disk/by-uuid/..., jedno z toho bude asi sda3 a druhé buď swap nebo boot.

[BobTheBuilder]

Jestli to je EFI/GPT disk, tak (na rozdíl od MBR disku) dd nestačí, pokud se liší velikost. GPT má partition table na konci disku. V MBR má více méně fiktivní údaje, které mají zabránit blbému softwaru v přepsání disku.

[Ston3]

Spíše bych se podíval do /etc/fstab, vypadá to, že disk mountuje podle UUID. S novým diskem je nové i UUID.

[Jan Fikar]

pokud to kopíroval dd, tak uuid zůstane

s tím GPT je to pravda, ale je jak na začátku, tak i na konci. Ta na konci by měla jít opravit pomocí gdisk https://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table

ještě pak je otázka, jak rozšířit oddíly, aby zabraly celý nový disk; asi pomocí parted/gparted

[Reklama]

[3ugeene]

s dd jsem takto kolikrat mel taky problem. Jednou to slo, podruhy ne. Doporucuju to radsi udelat clonezillou (resp. partclone). Ale GPT ne-GPT, melo by to jet. GPT tabulky jsou skutecne dve, ta na konci, je jen zalozni a melo by to najet i bez toho. Ale v tomhle pripade se stejne delal mensi disk na vetsi, tam je to sumak.

Jinak pokud jde ten novej disk 'namountovat' v jinym systemu, zkusil bych fsck

[snuff1987]

Mas to napisane v logu...  uuid disku je zmenene.. Riesenie je nabootovat pomocou ineho systemu, chrootnut sa na tvoj filesystem a zmenit zaznamy vo fstab. Pre istotu mozes dat 'dracut -f'

[k3dAR]

Mas to napisane v logu...  uuid disku je zmenene.. Riesenie je nabootovat pomocou ineho systemu, chrootnut sa na tvoj filesystem a zmenit zaznamy vo fstab. Pre istotu mozes dat 'dracut -f'

neni to UUID disku, ale filesystemu(/dev/disk/by-uuid) a pri kopirovani pomoci DD samozrejme UUID filesystemu (i oddilu /dev/disk/by-partuuid) zustavaji, jedine co se zmeni je /dev/disk/by-id ktere je dle model-sn zarizeni, pres to ale pripojovane to nema...
(a i kdyby melo byt UUID zmenene, tak mu nebude hlasit problem fsck...)

vypada to na spatne vykopirovanej image... to recene ze GPT ma tabulku i na konci by podle me melo problem jen pokud by primarni byla poskozena, coz teoreticky pokud byla i na zdrojovem disku, ale ten si nasel na konci...

nicmene to muzes snadno overit, kdy zkusis pripojit oddil primo z toho image (pokud ten 64GB SSD uz si premazal, tak urcitei na kopii image)

Kód: [Vybrat]

kpartx -a -v ten_image.dd
mount /dev/loop0p4 /mnt/kam
kpartx vytvori loopPRVNIVOLNECISLOpCISLAODDILU pro ten image, s kteryma pak lze pracovat jako beznejma odidlama, pripojovat, fsck atd...

[_Jenda]

Mně teda kpartx vytváří /dev/mapper/loopxpy, YMMV. A jinak před mountováním bych zkusil file -Ls (jestli tam vůbec je FS, příp. jaké má UUID) a fsck -n (nebo -N?) jestli je nějak rozumně v pořádku.

[k3dAR]

Mně teda kpartx vytváří /dev/mapper/loopxpy, YMMV. A jinak před mountováním bych zkusil file -Ls (jestli tam vůbec je FS, příp. jaké má UUID) a fsck -n (nebo -N?) jestli je nějak rozumně v pořádku.

mas pravdu, diky za opravu (popletl sem to s /dev/nbdXpY) :-) btw: -N ktere jen simuluje? nebo -n ktere zapina interaktivni rezim kterej by mel byt vychozi i bez zadani prepinace? :-)

[e3k]

karlitos skopiroval si disk i s UUID stareho disku na novy. musis este zmenit UUID na UUID noveho aby ti to nabehlo.
/etc/fstab asi. alebo tam napis /dev/sda1 . 2 . 3 namiesto UUID.

[k3dAR]

karlitos skopiroval si disk i s UUID stareho disku na novy. musis este zmenit UUID na UUID noveho aby ti to nabehlo.
/etc/fstab asi. alebo tam napis /dev/sda1 . 2 . 3 namiesto UUID.

znovu NE, UUID noveho je totozne s UUID stareho, jak sam pises, skopiroval UUID ;-)
viz: https://forum.root.cz/index.php?topic=23107.msg331381#msg331381

[e3k]

jo to ale nevysvetluje: Warning: /dev/disk/by-uuid/23ac3488.... does not exist.
ja by som spustil 'lsblk -f' a skontroloval to.

[k3dAR]

jo to ale nevysvetluje: Warning: /dev/disk/by-uuid/23ac3488.... does not exist.
ja by som spustil 'lsblk -f' a skontroloval to.

to vysvetluje info v dotazu:

sudo fsck /dev/sda3 mi zase zobrazi:

Kód: [Vybrat]

The superblock could not be read or does not describe a correct ext2/ext3/ext4
filesystem.

tedy neexistujici/vadnej filesystem na 3 oddilu, overit primo pres image zda vadi u gpt ze cil byl vetsi disk sem tazateli psal...

[e3k]

ospravedlnujem sa ten superblock som prehliadol. ano to je pruser. pomohol by prikaz dd aby sme vedeli ako to kopiroval. tiez skontrolovat sata kable. pripadne pustit smartctl na oba disky. pripadne badblocks.