Telepített Linux költöztetése...

...másik gépre. Ma egy Debian Squeeze -t költöztettem így, de más disztrókra is alkalmazható.

1) Indítsuk el a költöztetni kívánt rendszert
2) Indítsunk egy terminált root -ként (

gksu gnome-terminal

/ 

kdesu konsole

/ egyéb, tetszés szerint)
3) Csatlakoztassunk egy elegendő szabad hellyel* rendelkező külső eszközt (pendrive, winchester)
4) mount -oljuk az eszközt a /mnt alá
5) 

nice 5 tar cfz /mnt/mukodolinux.tar.gz / --exclude "/dev/*" --exclude "/proc/*" --exclude "/sys/*" --exclude "/tmp/*"

6) umount -oljuk a külső eszközt, majd válasszuk le
7) Indítsuk el egy live cd** -ről a célgépet
8) Indítsunk egy root shellt vagy terminált root -ként
9) mount -oljuk a /mnt alá azt a partíciót, ahová a rendszerünket mozgatni kívánjuk***
10) Csatlakoztassuk a külső eszközt, amire készítettük a másolatot a működő rendszerünkről, majd mount -oljuk a /media alá az eszközt
11) 

tar xfz /media/mukodolinux.tar.gz /mnt

12) 

mount -o bind /dev /mnt/dev

13) 

chroot /mnt

14) 

grub-install /dev/sda

#****
15) 

update-grub2

16) Módosítsuk a /etc/fstab fájlt (blkid segít kitalálni a UUID -ket, ha azokkal dolgozunk)
16) 

logout

17) Válasszuk le a külső eszközt
18) 

reboot

19) Élvezzük a korábban beállított és megszokott rendszerünket az új/másik gépen :)

*: elegendő hely: egy telepített Debian, ami nálam kb. 4.9 GB helyet foglal, gzip -pel tömörítve kb. 2.0 GB
**: a live cd legyen ugyanolyan architektúrájú, mint a mozgatni kívánt rendszer.. tehát ha egy x86_64 Linuxot mozgatsz, a live cd is ilyen legyen! Viszont a live cd lehet teljesen más disztró is, pl. én egy Fedorát használtam a Debian költöztetésénél, mert az volt kéznél. Tehát az architektúra a fontos (a chroot miatt).
***: legyen minimum annyi hely ezen a partíción, mint amennyi helyet foglal kicsomagolva a rendszer; s a fájlrendszer olyan legyen, ami lehetőleg megegyezik az eredetivel
****: sda helyett más is lehet az eszköz! pl. sdb, sdc... ha nem vagy biztos benne, akkor (c)fdisk -kel nézd meg, melyiket keresed

( bambano | 2011. 03. 06., v – 23:58 )

bár kétségtelen tény, hogy a tar manja mintha obfuscálva lenne, de ha már ilyet írsz, miért nem próbálod ki a jó megoldást?

A b-t választom:P

"--exclude "/proc/*" ez a paraméterezés szétütheti a bash parancsbufferét, ergo ez így nem jó. a másik, hogy bármennyire is nem ezt írja a manual meg az összes doksi, próba cseresznye után az derül ki, hogy megfelel a --exclude /proc formátum és a várt eredményt adja.

( zeller | 2011. 03. 07., h – 00:19 )

Na nincsenek usereid, meg nem érdekes, hogy a logfájlok nem lesznek konzisztensek, akkor csináld. MInden egyéb esetben meg NE így. Ha single módban indulsz, akkor talán...

Desktop esetben pont nem ezek a dolgok szoktak eloterbe kerulni. Ezert nem foglalkoztam ezzel bovebben, mert desktopon a logok konzisztenciaja senkit nem zavar, a db szerver vagy a multiuser meg nem tipikus felhasznalas. Az sqlite-t meg nem erdekli, hogy ki, mikor backupolja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( hrgy84 | 2011. 03. 07., h – 02:00 )

Ez _nem_ jo modszer. Az alabbiak a hibai:
- Pid fajlokat nem kezeli
- Cache-k nincsenek uritve (egy apt-get clean -t mindenkepp illik elengedni)
- Socketek meg leteznek a rendszerben, es sokminden tokon tudja szurni magat ilyesmi miatt
- Jogosultsagok elvesz(het)nek, --numeric-owner kotelezo kapcsolo.
- Lassu, feleslegesen tomorit.
- Fstab-bal nem foglalkozik, a vegen nem mukodo rendszer a vegeredmeny (a tevedesek elkerulese vegett: az UUID _random_)

A helyes modszer:
- Regi rendszeren takaritas, /tmp, apt-get clean, apt-get autoclean
- Uj lemez berak (amin mar van ugyanolyan particios tabla, mint a regin, esetleg mas meretekkel, de a particionevek ugyanazok
- LiveCD elindit
- /mnt/old ala regi rendszer felcsatol, /mnt/new ala uj rendszer felcsatol
- rsync -va --numeric-ids /mnt/old/ /mnt/new/
- a /mnt/new ala be kell mountolni a /proc es /sys fajlrendszereket (!!!)
- belepsz chroot-tal az uj rendszerbe
- fstabot, grub konfigot atirod, hogy a jo UUID-u diskekre mutasson, vagy komplette csereled az UUID hivatkozasokat LABEL hivatkozasokra
(ekkor a mkfs -nek meg _kell_ adni a -L kapcsoloval a cimket).
- grub-install, mint a leirasban (itt elsosorban a sorrend fontos)
- update-grub2
- levalasztasok
- halt
- uj disk kivesz, uj gepbe atrak
- boot
- Elvez, mint fent.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

>>- Cache-k nincsenek uritve (egy apt-get clean -t mindenkepp illik elengedni)
Nálam ált. ürítve van a cache...

>>- Jogosultsagok elvesz(het)nek, --numeric-owner kotelezo kapcsolo.
Fölösleges, mert ugyanaz a group/passwd fájl lesz a másik gépen is.

>>- Lassu, feleslegesen tomorit.
Mi van, ha nincs elég hely?

>>- Fstab-bal nem foglalkozik, a vegen nem mukodo rendszer a vegeredmeny (a tevedesek elkerulese vegett: az UUID _random_)
16) Módosítsuk a /etc/fstab fájlt (blkid segít kitalálni a UUID -ket, ha azokkal dolgozunk)

>>- Regi rendszeren takaritas, /tmp
--exclude "/tmp/*"

>>- Uj lemez berak (amin mar van ugyanolyan particios tabla, mint a regin, esetleg mas meretekkel, de a particionevek ugyanazok
Pont az volt a cél, hogy ne kelljen szétbarmolni semmit, ne kelljen kiszedni a célgépből a lemezt.

>>- a /mnt/new ala be kell mountolni a /proc es /sys fajlrendszereket (!!!)
Nem, a grup-install és az update-grub2 működik ezek nélkül is tökéletesen.

Amit leírtam, az működik. Tegnap csináltam. 10 perc volt a tgz tömörítés, nem csesződött el semmi, az egész költözés 20 perc (sem) volt.

"Fölösleges, mert ugyanaz a group/passwd fájl lesz a másik gépen is."
Ehhm... de a kitomorites soran a livecd-n nem, es ez a lenyeg, mivel nevre hivatkozol, az ID-k elmaszhatnak.
"16) Módosítsuk a /etc/fstab fájlt (blkid segít kitalálni a UUID -ket, ha azokkal dolgozunk)"
Elsosorban sorrendproblemaim vannak ezzel. Sok rendszer a grub frissitesekor gyart maganak initrd-t is, igy az fstab-ot mindenkeppen a grub elott kell elvegezni. Illetoleg sok grub updater script az fstabra tamaszkodik.

"Nem, a grup-install és az update-grub2 működik ezek nélkül is tökéletesen."
Tegyuk hozza, debianon/ubuntun. Ez nem altalanos, es egyebkent ugy tudom, hogy a /proc/mounts kellene eleg sok mindennek.

En elhiszem, hogy mukodik, en viszont nagyipari meretekben csinaltam ilyen migraciokat, es tudom, hogy ha az ember egy picit nem figyel oda, akkor eleg nagy szopasok vannak vele.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Fedora volt a live rendszer, amin kicsomagoltam a targézát és Debian, amin be. :)
Btw, userid:groupid alapján csomagolta be a tar majd ki is a rendszert, anélkül, hogy mondtam volna neki. Amint rábootoltam az átmásolt rendszerre, minden ahhoz a júzerhez tartozott, mint az eredeti rendszeren.

De ez nem azert volt, mert numerikusan csomagolt a tar, hanem azert,mert a fedoraban nem volt subchee user, igy mindig elovette a ID-t is. Itt alapvetoen a hiba _lehetosege_ az, amit mindig el kell kerulni. En jartam mar ugy, hogy a mysql user pont letezett a kicsomagolo rendszer alatt, de tok mas ID-vel, mint a becsomagolon. Mivel nem ID alapu volt a tarlabda, fogta, es ezt az idegen ID-t hasznalta fol erre a celra. A celrendszeren meg felorat debugoltam, hogy ugyan mi a francert kuld a mysql permdenied uzeneteket allandoan. Na, ezert kell a numerikus ID.
Lehet, hogy most mukodott, az is lehet, hogy tovabbi otszaz alkalommal mukodni fog, de amikor az otszazegyedik alkalommal ott allsz egy bootolhatatlan rendszerrel, es tehetetlenul kinlodsz, majd raebredsz, hogy nem olyan hulyeseg a jot jo elore megszokni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

>>>>- Uj lemez berak (amin mar van ugyanolyan particios tabla, mint a regin, esetleg mas meretekkel, de a particionevek ugyanazok
>> Pont az volt a cél, hogy ne kelljen szétbarmolni semmit, ne kelljen kiszedni a célgépből a lemezt.

Az rsync működik hálózaton keresztül is - új gépen livecd, diszket /mnt/new alá összerak, aztán rsync szerver indul, a költöztetendő rendszerben "rsync ... --numeric-ids ..." és hajrá.

Majd amikor rejtelyes nem-indulo dbus, meg avahi, meg egyeb hibak vannak, kuldhetem oket hozzad, o, mester?

Egyebkent alapvetoen igazad - lenne, ha itt nem egy olyan modszerrol lenne szo, amit a topicnyito megprobal amolyan altalanos "mindenre jo, meg a nathara is" modszernak eladni. Ez a modszer elsosorban desktopok eseteben jo, es elsosorban nem bonyolult rendszereknel, ahol a rendszeruserek is kevesen vannak, meg ahol nincsenek pipe/socket fajlok, meg ilyen hulyesegek. El kell keseritselek: a legtobb rendszer nem ilyen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( kmARC v | 2011. 03. 07., h – 08:13 )

És ez az egyetlen eset, amikor a desktoplinux-féle "minden bootoláskor tekintsük tök idegennek a gépet és ismerjünk fel mindent újra, nem mintha ebből nem lehetne így az ezredik indításnál már valami profilozást készíteni"-filozófia a felhasználó javára van. Úgy az esetek, 0.000000001 ezrelék részében. :)

( uid_2716 | 2011. 03. 07., h – 19:52 )

Amellett, amit mások megjegyeztek:

SELinux-os (enforcing) rendszert nem hasznos olyan tarral / paraméterezéssel / LiveCD-vel költöztetni, amely nem viszi át a security context-et.

A költöztető eszköz legyen titkosítva (LUKS, truecrypt), vagy legalább a tar-t nyomjuk még át a gpg-n, valami nem triviális szimmetrikus kulccsal.

A tömörítésnek történetesen van értelme, csak nem biztos, hogy a gzip-pel. A pigz -1 már hasznos lehet, de szerintem a legjobb a tamp erre a célra. Ha olyan gyors a tömörítőnk, hogy a tömörített kimenet írása még mindig IO-bound, akkor a tömörítés színtiszta nyereség, ugyanis amellett, hogy a mentés -- lásd előbb -- IO-korlátos, még meg is spórolunk néhány MB-t a kiírandó adathalmazból, vagyis időt nyerünk. CPU-korlátos tömörítést erre a célra használni zsákutca (kivéve, ha helyszűkében vagyunk). A gpg CPU-igényét itt figyelembe kell venni.

Nyilvánvaló, hogy mielőtt elutazunk a másik géphez, egyszer lecsatoljuk, majd visszacsatoljuk a hordozót (fizikailag is, ha nem hálózaton csináljuk), és leellenőrizzük a mentésünket.

Azert ezt a szintu paranoiat mar kezeltetni illik :-)

Viccen kivul: egy egyszer hasznalatos koltozteto csomagot nincs ertelme titkositani, vagy ha van is, akkor is valami nagyon alap titkositassal csak, mert maskepp az sem lesz IO-bound, es amit a tomesnel nyersz, azt a titkositasnal veszted (barmily hihetetlen: hasonlo fogalmakrol van szo, a kettonek a matematikaja sokban megegyezik - abban biztosan, hogy mindketto szamitasigenyes). En azt mondom, hogy inkabb tomjon az ember, mert a gpg kevesebb helyet takarit meg, mint a tomorites.

A hordozo le- es felcsatolasa akkor indokolt, ha nem bizunk meg a hordozoban, es a koltozteto csomagot sokaig tarolni akarjuk. Jelenleg meg a legocskabb pendrive is alkalmas annyi ideig valo adattarolasra, amig az ember elutazik a masik rendszerhez - ez mondjuk legfeljebb ket nap. Ennyi ido alatt meg nem szokott adat serulni a teszkogazdasagos pendriveken sem.

Desktop eseteben talan keves esetben jon elo az enforcing SELinux, foleg azert, mert az X miatt mindenfele securityba repeszagyuval kell lukakat utni ahhoz, hogy utana egy mukodo rendszert kapjunk.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

egy egyszer hasznalatos koltozteto csomagot nincs ertelme titkositani

Én itt egy elkallódó, vagy elvesző pendrive-ra gondolok, amellyel fél évvel ezelőtt költöztettünk egyet, és azóta nem írtuk tele. Vagy egy hordozható vinyóra, amellyel két éve költöztettünk egyet, nem írtuk tele, aztán elromlik és szervizbe visszük. Ha titkosítva mentesz, azzal "jogot szerzel" arra, hogy azonnal megfeledkezhess a költöztetés tényéről.

mert maskepp az sem lesz IO-bound, es amit a tomesnel nyersz, azt a titkositasnal veszted

Ez jogos észrevétel, azonban a számok nem aggasztóak; énnálam ebből: 

gpg -c -z0 --cipher-algo AES256

42.5 MB/s sebességgel jön az anyag, ami azért eléggé leveri még egy pendrive írási sebességét. Mindez egy magon, tehát egy tamp vagy egy lzop elfér a többi/másik magon.

Ennyi ido alatt meg nem szokott adat serulni a teszkogazdasagos pendriveken sem.

Valószínűleg tényleg nem, de ha már az íráskor volt valami hw-probléma, azt nem árt még távozás előtt észrevenni. Nemcsak a hardvertől tartok egyébként, hanem programhibától is. Az "integrációs teszt" az igazi teszt :)

Desktop eseteben talan keves esetben jon elo az enforcing SELinux

Fedorán alapértelmezett, tudtommal.

foleg azert, mert az X miatt mindenfele securityba repeszagyuval kell lukakat utni ahhoz, hogy utana egy mukodo rendszert kapjunk

Ezt megoldják a policy megfelelő összerakásával. Az persze lehet, hogy az X-hez tartozó szabályhalmaz valóban repeszágyúnak minősül, mindenesetre a visszaállítás után érdemes lehet továbbra is megfelelni ugyanannak a policy-nak.

( zolpet | 2011. 03. 15., k – 18:13 )

Bonyolultnak tűnik a dd-hez képest. :)
(subscribe)