[Ubuntu] Installatie copieren naar nieuwe hardware

[MrDry]

Ik probeer al 2 dagen om mijn ubuntu 8.04.2 installatie naar een andere server te copieren. De oude hardware is een PIII 866 mhz en de nieuwe hardware is een Sempron LE-1150. Van i386 -> i386 dus. Ik lees overal dat dit kinderlijk eenvoudig moet zijn. Gewoon met tar volgens dit draadje .

Het in en uitpakken is uiteraard geen probleem. Maar dan begint de ellende.

Mijn fstab en menu.lst maken gebruik van UUID voor de hd's. Na het uitpakken wijzig ik deze beiden naar de UUID van mijn nieuwe harddisk. Maar na een reboot krijg ik de volgende foutmelding

ALERT! /dev/disc/by-uuid/2a15d320-d882-409f-8819-af3f257e0526 does not exist. Dropping to a shell!

Dan kom ik in een shell terecht waar ik eigenlijk niks kan. Niks mounten, niks wijzigen, geen fdisk...eigelijk niks.


Ik snap alleen niet wat deze fout veroorzaakt omdat ik fstab en menu.lst aangepast heb. Zie ik iets over het hoofd?

[Verwijderd]

Bij mij is het iig /dev/disk ipv /dev/disc. Je weet zeker dat je de juiste UUID's hebt? Deze wijzigen zodra je een partitie aanpast namelijk. UUID's kun je achterhalen met het blkid commando. Kun je anders je menu.lst en fstab eens posten.

[MrDry]

Ik heb gewoon de melding overgenomen van het scherm dus disc is een typo....

Ik weet zeker dat ik de juist UUID's heb. Ik copieer voordat ik de tar terugzet mijn menu.lst en fstab en gebruik deze opnieuw.

Menu.lst en fstab kom ik niet meer bij vanuit die shell. Dan moet ikmet een live cd aan de gang.

Maar wat ik probeer moet toch kunnen of is er een andere (lees betere) manier om je installatie te kopiëren naar nieuwe hardware?

[Verwijderd]

MrDry schreef op dinsdag 21 april 2009 @ 09:29:
Ik weet zeker dat ik de juist UUID's heb. Ik copieer voordat ik de tar terugzet mijn menu.lst en fstab en gebruik deze opnieuw.

Deze laatste zin snap ik niet helemaal. Je extract de tar op een nieuwe HD, dus de UUID's zullen nooit hetzelfde zijn als bij je oude HD.

Je zou ook gewoon de gehele UUID's weg kunnen gooien en het gewoon met device nodes kunnen doen (dus /dev/sda1 bijv.). In principe heb je die UUID's niet nodig en werkt het ook prima zonder (tenzij je een raid controller hebt die alles in de war gooit bij elke reboot).

[MrDry]

Ik heb een verse kale installatie van 8.04.2 gedaan op mn nieuwe server. Deze boot normaal. Hierna backup ik menu.lst en fstab waarna ik de tar terugzet. Aansluitend zet ik de backups van fstab en menu.lst terug. Deze horen dus bij de partitie van de nieuwe schijf.

Vandaar dat ik ook niet snap waar de melding vandaan komt. Ik krijg het gevoel dat er nog een bestand is wat naar een oude UUID verwijst.

[Verwijderd]

En als je het gewoon met device nodes doet (met e kun je grub menu regels aanpassen voor het booten)? En is 2a15d320-d882-409f-8819-af3f257e0526 een UUID van je oude schijf of van je nieuwe?

In princiepe zijn menu.lst en fstab de enige bestanden die je aan zou moeten passen.

[Verwijderd]

Die bestanden zijn waarschijnlijk makkelijk te vinden met de volgende opdracht:

code:

cd /etc/
grep -ir "het uuid nummer wat je zoekt" *

[MrDry]

Verwijderd schreef op dinsdag 21 april 2009 @ 10:39:
En als je het gewoon met device nodes doet (met e kun je grub menu regels aanpassen voor het booten)? En is 2a15d320-d882-409f-8819-af3f257e0526 een UUID van je oude schijf of van je nieuwe?

In princiepe zijn menu.lst en fstab de enige bestanden die je aan zou moeten passen.

Ik heb eerlijk gezegd niet gecontroleerd waar die UUID van is. Dat moet ik nog ff nazoeken.

[Sprite_tm]

Het zou kunnen zijn dat de uuid van je oude harde schijf nog in een initramfs-image zit. Die moet je dan even her-genereren en dan zouden de instellingen van je nieuwe HD daarin moeten komen te staan. Ik weet zo 123 niet hoe dat op Ubuntu moet, maar dat kan je vast wel vinden.

[Verwijderd]

Volgens mij kun je een nieuwe initramfs creëren dmv (kan het hier niet controleren):

$ sudo update-initramfs -u all

[ Voor 13% gewijzigd door Verwijderd op 21-04-2009 11:00 ]

[MrDry]

Dat betekend dat ik dus ff opnieuw een kale install moet doen. Tar terugzetten.

Vervolgens fstab en menu.lst aanpassen en sudo update-initramfs -u all doen? Ik zou natuurlijk ook kunnen booten van een live cd en dan sudo update-initramfs -u all doen? Of gaat dat niet werken omdat ubuntu dan niet geboot is van hd0?

[lordgandalf]

Je kunt booten met een live cd en dan chrooten naar je niet werkende install en dan daar update-initrmafs doen

[MrDry]

Heb het gevonden. Na booten met een live cd bleek dat toch menu.lst niet goed stond. De enige oorzaak die ik me nog kan voorstellen is dat op mijn server ook een backup staat met dezelfde naam als de backup die ik gemaakt heb op mn nieuwe server. Nog niet gecontroleerd overigens. Ben blij dat ik weer verder kan....

Thanx

[ Voor 76% gewijzigd door MrDry op 22-04-2009 08:59 ]

[DeKaerften]

Als je toch al een verse install maakt om je fstab en menu.lst terug te krijgen, kun je toch ook gewoon meteen die initramfs pakken? Of gebruik je verschillende kernels in de verschillende installs?

[deadinspace]

Wat je ook kunt doen is de hele harddisk byte-voor-byte klonen naar dat andere systeem (en daarna de filesystems resizen als de nieuwe HD groter is), dan heb je deze issues wat minder snel.

Hoe tar je trouwens? Je moet wel zorgen dat je alle ownerships en permissions behoudt, en dat je dingen als /proc, /sys, /dev en weetik wat niet meetart.

[daft_dutch]

deadinspace schreef op dinsdag 21 april 2009 @ 22:55:
Wat je ook kunt doen is de hele harddisk byte-voor-byte klonen naar dat andere systeem (en daarna de filesystems resizen als de nieuwe HD groter is), dan heb je deze issues wat minder snel.

dit lukt bij mij altijd.
brand 2 keer een live cd. boot live cd in beide apparaten.

code:

nc -l -p 2345 | dd of=/dev/disk

code:

dd if=/dev/disk | nc 2345

code:

gparted 
#cd er uit reboot

typerde type in grub.

code:

#set boot partitie
#sda = hd(0,0)
root            (hd0,0)
#kernel 
kernel          /vm<tab tiep tab> root=/dev/<root partitie>
initrd          /in<tab zelfde tiep tab>
#boot

code:

update-grub

Hoe tar je trouwens? Je moet wel zorgen dat je alle ownerships en permissions behoudt, en dat je dingen als /proc, /sys, /dev en weetik wat niet meetart.

dat doet udev voor je.

[ Voor 72% gewijzigd door daft_dutch op 21-04-2009 23:09 ]

[deadinspace]

daft_dutch schreef op dinsdag 21 april 2009 @ 22:55:

code:

nc -l -p 2345 | dd of=/dev/disk

code:

dd if=/dev/disk | nc 2345

Die dd daar is een beetje overbodig (tenzij je dd regelmatig SIGUSR1 wil sturen ofzo)

nc -l -p 2345 > /dev/disk
nc nieuwebak 2345 < /dev/disk

werkt ook prima

En ik raad de -q0 optie aan voor netcat, dan sluit die tenminste vanzelf af als het klaar is.

dat doet udev voor je.

Nee, ik had het over de permissies en ownerships van alles (al was ik wel in de war met cp, tar doet dat automatisch al).

Voor wat betreft /dev ging het mij erom dat je die juist niet mee moest tarren.

[ Voor 20% gewijzigd door deadinspace op 21-04-2009 23:21 ]

[raymonvdm]

Ik heb dat probleem met die uuid ook gehad bij mijn servers. Het is iets nieuws van Ubuntu. Bij mij was de oplossing om rootdelay=90 toe te voegen aan de menu.lst

Verder kun je de uuid aanpasssen en bijvoorbeeld gewoon /dev/sda gebruiken. Zelf heb ik een server vervangen door de nieuwe te installeren en hierna met rsync de root te syncen.

[Hero of Time]

Ik heb hetzelfde een week of twee geleden nog gedaan. M'n maxtor schijf viel spontaan uit, om iets later weer aan te gaan, daar had ik dus Ubuntu op staan. Ik heb het eerst via Acronis geprobeert te clonen, maar dat lukte niet. Uiteindelijk via een LiveCD een cd -a gedaan, zodat de rechten gelijk bleven. UUID gecheckt via blkid, die aangepast in /etc/fstab en /boot/grub/menu.lst, hoppa, draaien maar. Uiteraard wel ff gezorgd dat grub ook daadwerkelijk op de schijf was geïnstalleerd. Draai daar nu prima in.
Dit is uiteraard gedaan door beide schijven, bron en bestemming, in hetzelfde systeem te hebben. Mounten in de live omgeving en werken maar.

[MrDry]

Heb het gevonden. Na booten met een live cd bleek dat toch menu.lst niet goed stond. De enige oorzaak die ik me nog kan voorstellen is dat op mijn server ook een backup staat met dezelfde naam als de backup die ik gemaakt heb op mn nieuwe server. Nog niet gecontroleerd overigens. Ben blij dat ik weer verder kan....

Thanx