[Nem sikerült] Linux költöztetése más méretű merevlemezre

Linux-haladó

Szervusztok!

Egy korábbi topicban valaki elhintette nekem, hogy ha megjön az új merevlemezem, akkor nem feltétlen szükséges újratelepíteni az Ubuntu 13.10-et, mert elég ha átmásolom a fájlokat és feltelepítem a GRUB-ot. Ez nagyon felkeltette az érdeklődésem és mivel a futár ma hozzá a diszket, elég aktuális is.

Én azért nem igazán vagyok biztos magamban, meg néhány változtatást is eszközölni fogok, ezért némi segítséget szeretnék kérni, azaz tanácsot.

Jelenleg így néz ki a 160.0 GB méretű SAMSUNG IDE diszk, amin a rendszerem van: 

1.0 GiB   - /boot - ext2
4.0 GiB   - swap  - linux-swap
64.0 GiB  - /     - btrfs
80.05 GiB - /home - btrfs (de alig van rajta valami, pár Steames játékot kivéve)

Most azonban másként szeretném majd, az új lemezre telepíteni a rendszert. A kérdés, hogy ezt megváltoztathatom-e így, anélkül, hogy kibelezném a jelenlegi rendszert.
Így tervezem most: 


4.0 GiB   - swap          - linux-swap
64.0 GiB  - /             - ext4 (mivel ext4-ről lehet bootolni, nem akarok /bootot)
100.0 GiB - /media/Roms   - NTFS (Emulátor romok, hogy láthatóak legyenek Windows alol)
<a_tobbi> - /home         - ext4 (1TB-os diszk amúgy)

Na már most... mi minden teendőm van?
Van kéznél egy Ubuntu 13.10-es telepítő DVD, hibaellenőrizve, szóval jó.
Ezt akarom használni a művelethez majd, mert úgy hallottam, hogy futó linuxon nem megoldható.

Én így képzelem el:
MC-vel átmásolni a / tartalmát a régi diszkről az új diszk /-be, továbbá a régi /boot-ból a fájlokat az új diszk /boot-jába, ami ezúttal nem külön partíció persze. Aztán 

sudo grub-install /dev/sdx

. Eztán kéne szerkeszteni a 

/etc/fstab

fájlt, gondolom. Legalább is amennyire már kiismerem magam pingvinen, így gondolom.
Itt viszont oda kell figyelni, hogy átírjam az UUID-ket, meg a fájlrendszereket, stb. Ide tudtok valamit tanácsolni?
Esetleg kihagytam valami lépést?

Persze ha nem működik a dolog, vagy elrontom, még mindig ott az install DVD, csak már úgy belaktam a rendszert, hogy kár lenne újrahúzni...

Szerk.: Végül újrahúztam inkább a rendszert, mert az rsync nem úgy sikerült, ahogy akartam. De nem baj, legalább gyors, tiszta rendszerem van. Ezt nem fogom úgy teleszemetelni. Mindenesetre köszönöm a válaszokat!

  • 9915 megtekintés

( kea | 2013. 12. 04., sze – 09:27 )

Csináltam linuxos gépterem klónozását néhányszor. A leghatékonyabb eddig a filerendszer másolása volt, kb. 2-3 perc/gép tempóval. Picit bővebben:

Adott a (minta)telepítés egy valamilyen partíción (ide értve a méretet és a filerendszert). Ezt kellene átvinni nem szükségképpen ugyanolyan méretű és filerendszerű másik partícióra a lehető legkevesebb munkával.

A kiindulási partíción csinálj nagytakarítást (pl. /tmp), majd nézd meg, mennyi helyet foglal. Tömörítve ennél (lényegesen) kevesebbet igényel. Kell mindenesetre egy olyan eszköz/partíció, amelyen el fog férni, és ez különbözik a kiindulási (minta)telepítés partíciójától.

Mivel egy futó rendszerben vannak olyan dolgok, amelyekkel nem akarunk bajlódni, indítsd a gépet egy cd-ről vagy egy usb-ről. Csatold a kiindulási partíciót (sda1), meg azt, amelyiket üres hely van elegendő (sda2), értelemszerűen.

tar -C /mnt/sda1 -czf /mnt/sda2/sda1files.tgz ./*

Elindítod a másik gépet (cd/usb), a vinyót persze partícionálni (boot flag!) és formázni kell, majd csatolni valahová. Utána csatolni kell az sda1files.tgz-t tartalmazó eszközt is, és jön a lényeg, a kicsomagolás az új partíció csatolási pontjából:

tar -xzps --same-owner -f /mnt/sda2/sda1files.tgz

Fontos a -p és a --same-owner. Utána beállítod a gépnevet (/etc/HOSTNAME) és az IP-címet (átjárót stb.), szükség esetén a lilo.conf (grub) szerkesztendő és persze:

lilo

Ezután lehet újraindítani a gépet, indul az új rendszer. Nyilván a kiindulási helyen a kernelnek tartalmaznia kell mindazon opciókat, amelyekre az új helyen szükség lesz. A grafikus cuccok beállítása és esetleges egyebek utána már megy helyben vagy ssh-n távolról. Felhasználói cuccok nyilván problémamentesen másolhatók, a már működő rendszerben.

Üdvrivalgással:
KEA.

( Tom | 2013. 12. 04., sze – 09:47 )

Csináltam párszor ilyesmit, az mc nem jó mert nem tartja meg a jogosultságokat.

Live CD-röl vagy rescue CD-röl szoktam bootolni (lehetöleg ugyanaz a verzió mint amit másolni szoktam, a másolásnál nem gond, csak amikor a boot-ot meg az fstab-ot kell piszkálni az UUID-ek miatt jobb ha közel azonos a kernel+disztrib)

létrehozok egy /target könyvtárat a root-ba, felmountolgatom a /target alá az új lemez particióit ahogy majd szeretném.
létrehozok egy /source könytárat a root-ba ha a rescue nem tette meg még máshová, felmountolom a /source alá a régi lemez particiót.

(tar cp --xattrs /source) | (tar x /target)

UUID-ek átnézése az /target/etc/fstab-ban.

/target/dev, /target/proc, /target/sys ellenörzés.

mount --bind /dev /target/dev
mount --bind /proc /target/proc
mount --bind /sys /target/sys

ha ez megvan akkor chroot /target /bin/bash, grub telepítés, nagylevegö, reboot, esetleg többször livecd boot és további finomitások mig el nem indul a rendszer.

ennek elöfeltétele hogy mind a két lemez ugyanabban a gépben van, a régi lemezt biztonság kedvéért hátrább szoktam rakni a sorban hogy az új (s|h)da legyen.

UI: nekem soha nem sikerül elsöre :D

Üdv: Tom

Van egy pipa a preserve attributes. Az default be van kapcsolva. Olyankor szoktam kikapcsolni, ha ntfsre vagy samba ra másolok, mert akkor egyenként panaszkodik arra, hogy nem sikerült a megfelelő attributumokat beállítani. De defaultban tuti, hogy másolja a dátummal együtt a jogokat.

A témához pedig:

rsync -av --progress --inplace /mnt/temp1/ /mnt/temp2/ minden kívánt filerendszerre páronként (kivéve a swap ami ugye elég egy mkswap), javaslom az lvmet, és akkor nem kell az fstabba uuidket meg fix partíció számokat írni, hanem elnevezett partíciókat. A boot meg marad lvm en kívül. Utána sysresc cd ről boot: mount minden a megfelelő struktúrába /mnt/gentoo mappa alá. Utána:

mount -o bind /sys /mnt/gentoo/sys
mount -o bind /dev /mnt/gentoo/dev
mount -o bind /dev/pts /sys /mnt/gentoo/dev/pts
mount -t proc none /mnt/gentoo/proc

chroot /mnt/gentoo /bin/bash
grub-install /dev/sda

nagyvonalakban. Egyúttal nemcsak particionálni, költöztetni lehet, hanem filerendszert váltani is. lvmre áttérés előtt a megfelelő csomagok (lvm2) telepítendő stb.

Nem is a jogokkal, inkább a tulajdonossal lehet gond.
Pl ha olyan rendszerrel másolsz ahol mondjuk a mysql user id más.
akkor az új id-vel megy át ahol pl 25 id a games useré, igy a másolt
rendszeren games user a mysql, ami gond lesz.
ezért jobb az "rsync". :)

............
Nem ígérek semmit, de azt betartom!

dd-re +1, én így csináltam már többször is, sikeresen:

sda - forás winyó
sdb - cél winyó (nálam mindig csont üres volt)

trk boot cd-ről rendszer indít
semmi mountolás
dd if =/dev/sda of=/dev/sdb

Ez átmásol mindent mbr-estül-bootflagestül meg minden.

Ha a cél winyó nagyobb, mint a forrás, akkor félbeszakad a művelet az input elfogyásával, de akkor is sikeres lesz a költöztetés.
Kipróbált, bizonyított módszer (azon kívül, hogy egyszerű).

Az üres szemetet is, meg mindent... Ha a cél diszk kisebb, akkor cumi, ha partíciókat/lvm-et szeretnél módosítani, akkor dettó. LVM esetén pvmove, nem lvm esetén rsync a standard bevett gyakorlat - az előbbinél mehet teljesen normál üzemben a rendszer, az utóbbinál viszont single módban (vagy init=/bin/bash paraméterrel) bootolva kényelmes.

A rendszert akarom költöztetni, nem az üres/most épp nem használt helyet. Ha a diszkek kiosztását is át akarod variálni, szintén értelmesebb szinten kell az adatokat mozgatni, mint ahogy akkor is, ha szelektálni szeretnél az átlapátolandó adatok között, vagy épp egy diszkről költöznél többre vagy fordítva... ezekre is lehet egészen kellemes módszereket találni LVM-mel. Vagy pl. egy adott fájlrendszer növelésére plusz diszkkel csak az LVM-et tudod használni (a bemountolom alá a plusz diszk partícióit nem játszik, mert abból csak a káosz lesz - pláne, ha jellemzően egy-két nagy helyfoglalású könyvtár viszi el a tárterület döntő hányadát (próbáltunk más megoldást találni, és nem igazán sikerült)

Ja igaz, futás közben, azért az egy kicsit más történet. Eddig nem volt sejtésem róla, hogy az LVM otthoni környezetben is hasznos lehet. Amúgy hálózati op.rendszerek tantárgy keretén belül épp most ismerkedek vele. (Eddig azt gondoltam róla, hogy nagyobb rendszereknél jó főleg.) Köszi az infókat.

( locsemege v | 2013. 12. 04., sze – 11:01 )

Az NTFS-t a végére tenném, tehát a /home-mal megcserélném, hogy ne kelljen seek-elnie állandóan a (/,swap) <---> /home között.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( zslaszlo v | 2013. 12. 04., sze – 18:21 )

Sub. Hasonlót tervezek magam is. Gyüjtöm a hasznos infókat.

( Zs | 2013. 12. 04., sze – 23:41 )

clonezilla?
ha jól emlékszem, tud olyat, hogy gépen belül egyik winyóról a másikra cuccol át

( golgota | 2013. 12. 05., cs – 08:10 )

OFF

Ugye ugye mennyivel jobb az LVM, hogy csak szépen át pvmove-olsz mindent online/működés közben és kész is? :D

/OFF

( trey | 2013. 12. 05., cs – 09:11 )

Tapasztalattal megcsinálható manuálisan, de ha nem akarsz ezzel foglalkozni, sok rendszert kell így csinálnod stb. stb., akkor vannak erre kereskedelmi megoldások is.

Ilyen például az Acronis True Image terméke, amely egyrészt nem drága, másrészt pl. SSD-k mellé gyakran bundle-ben adják. Aki nem szégyell pénzt adni szoftverért, annak ez is opció lehet. Grafikus felületen lehet elvégezni a klónozást, miközben meghatározható, hogy az új layout milyen legyen. A legtöbb népszerű, gyakori linuxos fájlrendszerrel elboldogul.

--
trey @ gépház

( debby v | 2013. 12. 06., p – 04:17 )

pl: tarral és egy darabig van mentésed róla :)

új lemez particionálása
live cd boot

öreg rendszer
tar -cvpjf /home/root_backup-root.tar.bz2 /
tar -cvpjf /home/home_backup-home.tar.bz2 /home

aztán új helyen kicsomagolod update-grub - ennyi

nézz utána a tar kapcsolóinak is /cvpjf az :)jó lesz/

up:

látom van /boot partició azokat se felejtsd el bemásolni az új partíció /boot könyvtárba az uj partíción /vagyis mentsd a bootot de már ne uj partición csomagold ki, hanem a z új / particiódon..

és persze az fstabot is át kell szerkeszteni és az update grub előtt grub recheck is kell a más particiók miatt.

( sany | 2013. 12. 07., szo – 20:58 )

"mert az rsync nem úgy sikerült, ahogy akartam."
Gyakorolj!
Pl: a szűz rendszert lemented egy másik lemezre.

............
Nem ígérek semmit, de azt betartom!

Azóta a diszket lenulláztam dd-vel és beraktam egy régi gépbe, XP-t rá és ajándékba adom valakinek.
Egyébként az Rsync maga sikerült, Live rendszer alól tökéletesen látszódott. De a GRUB-ot sehogy sem tudtam megoldani. Egyébként nem is baj, mert az új rendszerem sokkal tisztább, sokkal gyorsabb lett.

Ubuntu 13.10 amd64

Aha. Csak azért kérdeztem, mert azt írtad, hogy "az rsync nem úgy sikerült, ahogy akartam"... Onnantól kezdve, hogy minden fájl a helyén van a céldiszken, a grub felpakolása némi utánaolvasással (procfs, devfs bindmount, chroot, grub telepít, örül) nem szokott gondot okozni.

Na igen, csak itt még volt annyi "nehezítés", hogy a BOOT partíció megszűnt így aztán a grub.conf-ban a (hd0,0) helyett mindent át kellett volna írni úgy, hogy a (hd0,0)/boot-ban keresse.

Azaz mondjuk "kernel /boot/vmlinuz-...." a sima "kernel /vmlinuz-..." helyett, ami akkor van, ha külön partíción van. Meg hasonló kis apróságok. Bár azt sem nagyon szereti a grub, ha a stage másfelek nem külön partíción vannak. Meg aztán szerintem egy initrd-t is kellett volna gyártani újat, stb. stb.