Telepített operációs rendszer költöztetése

Erről valahol írtam már, de szerintem csak hozzászólásban. Van egy picike, 11.6"-os kijelzővel rendelkező Acer notebook-om, s most raktam bele egy 256 GB-os SSD-t - ez kb. 239 GiB valójában. A feladat annyi, hogy HDD-ről SSD-re kellett költöztetni a telepített oprendszert.

Fogtam a backup HDD-met, majd egy Fedora telepítőt boot-oltam - tehát live Linuxot -, s az operációs rendszeremet file-osan a backup HDD-re másoltam rsync -avHASX kapcsolókkal. Arra érdemes figyelni, hogy a Fedora telepítője becsatolja a /dev, /proc, /run, /sys, /tmp filerendszereket is, így én alkönyvtáranként másoltam, ezeket pedig létrehoztam üresen, a /tmp-re pedig tettem sticky bitet.

Miután ez megvolt, jött a szerelés. Notebookból kiszedtem a HDD-t, betettem az SSD-t. Most megint Live telepítőt boot-oltam, persze rescue módban, hogy legyen egy shell-em. Mivel a szerkezet (U)EFI-s, így GPT kell, ezért gdisk paranccsal particionáltam, majd mkfs.vfat -F32, mkfs.ext4 és mkswap parancsokkal formáztam. Az EFI partíció (/boot/efi) 128 MB-os, a /boot 512 MB, a swap 8.1 GB, a / (root fs) 100 GB, a maradék, talán 127 GB körül pedig a /home lett. A /var-t nem szedtem külön.

Ezt követően szintén rsync -avHASX paranccsal visszamásoltam a megfelelő helyekre a backup HDD-mről az operációs rendszert. Utána lsblk -f paranccsal lekérdeztem a filerendszer UUID-eket, kijavítottam az fstab-ot, a grub.cfg-t. Ez utóbbiban a resume kernelparaméter is érdekes, hiszen az új swap-et kell megadni, meg kell mondani neki, hol keresse a Grub az oprendszert, illetve mi a root fs.

Leállítottam a gépet, kivettem a pendrive-ot, bekapcsolás után azonnal indult legnagyobb meglepetésemre. Egyedül azt érdemes megjegyezni, hogy érdemes először a selinux=0 kernelparaméterrel indítani, majd root-ként egy

: >/.autorelabel

parancsot kiadni. Bár ezt megtehetjük még a file-ok visszamásolásakor is, ekkor egyből mehet a selinuxos támogatás. Az első indulás éppen ezért sokáig fog tartani - lehet akár 10 perc is -, hiszen megtörténik a file-ok újracímkézése. Utána automatikusan újraindul, s hibátlanul fut. Mivel másoltam az rpm adatbázist is, a csomagok frissítése, telepítése is gond nélkül fog menni.

( jimmy399 v | 2017. 10. 08., v – 16:44 )

Én Arch Linux-ot tettem fel SSD-re HDD-ről, de én tar archhívumból tömörítettem ki a root FS-t és egy grub-mkconfig-gal és egy fstab frissítéssel valamint egy grub-installal le is tudtam a költözést.

Az csak az én ismereteim hiányossága, hogy nem tudom, a tar minden metaadatot képes-e tárolni. Gondolok itt socketekre, karakter device-okra, named pipe-okra, block device-okra, hardlinkekre, selinux contextekre, sparse file-okra. Az rsync megfelelő paraméterezéssel tudja ezeket.

Ha jól értem, lényegében ugyanazt csináltad, amit én. A poén, hogy UEFI-nél nincs senki földjén boot kód, tehát az MBR-ben, meg az MBR és az első partíció között - MBR sincs -, így történhetett meg, hogy még a Grub-ot sem kellett újra telepíteni a file-os másolás után.

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

a tar képes eltárolni a fájl jogosultságokat, így, szerintem simán képes soft és hard linekeket is eltárolni. A /dev /sys és egyéb rendszer specifikus kernel kiterjesztéseket eleve nem mentek, mert live linux-ról bootolok, és így a rendszer root partíciója sima partícióként látszódik közben, amikor tar-ral mentem le az fs-t fájl szinten.

( locsemege v | 2017. 10. 08., v – 19:56 )

Nem tartozik szorosan a tárgyhoz, de ha már SSD, csináltam egy ilyet is:

systemctl --now enable fstrim.timer
systemctl status fstrim.timer

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

( asm v | 2017. 10. 08., v – 20:58 )

Nem lett volna egyszerubb dd-vel atmasolni az adatot ugyanakkora vagy nagyobb particiokra, majd atmeretezni a filerendszert? Modern filerendszerek stabilan tudjak a meretnovelest (akar online is).

Nem, mert akkor a semmit is másolom, ráadásul az SSD, tehát a cél kisebb volt, mint a HDD, azaz a forrás. Tudom, lehet előbb minimálisra méretezni az fs-t, majd az új partícióba másolást követően beletágítani a partícióba. Ez is egy járható út. Hogy egyszerűbb-e, nem tudom eldönteni. Ahhoz talán több parancs kell, viszont a swap UUID-jén kívül nem kell módosítani a többi UUID-et. Bár formázni is lehet adott UUID-re, csak én nem szeretem, ha az egyedi azonosító „véletlenül” mégsem egyedi. :)

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

Nem, mert akkor a semmit is másolom...

En ennek ellenere ezt csinalom ha csak lehet. dd-vel biztos lehetek benne, hogy a masolas bitre megtortent es nem felejtettem el egyeteln opciot sem az rsynchez, ami elrontana jogosultsagokat, time stampeket, linkeket, stb, Ilyenkor nem nagyon erdekel, hogy sporolhatnek idot, foleg, hogy gepidot sporolok csak, mert a tenyleges munka minimalis dd eseten.

(A kisebb meretu SSD persze problema, igy ez lehet, hogy neked nem jo megoldas, de masoknak mukodhet.)

Ha sok kis meretu file van a filerendszeren, akkor azzal el tud szoszmogni a HDD, mire mindet felolvassa egyesevel.
Ellenben dd-vel HDD-t szekvencialisan olvasva nagy meretu blokkmerettel (bs=1M) sokkalta gyorsabb tud lenni a masolas.

Viszont ha file-okat masolsz, akkor van lehetoseged firerendszert valtani. Nehany evente erdemes atgondolni...

500 GB-os HDD-ről költöztem 256 GB-os SSD-re. Az elsődleges ok, hogy ne legyen mozgó alkatrész a gépben, mozgatáskor ne fordulhasson elő, hogy a fej beleüt a lemezbe. A sebesség növekedése kellemes mellékhatás. A tárkapacitás csökkenése nem olyan jó, de ez nem az elsődleges gépem, s annyira azért a 256 GB sem kevés.

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

( zeller | 2017. 10. 09., h – 12:46 )

yum-debug-dump, /etc /home mentése, új diszken minimál install, yum-debug-restore, /etc-ből releváns fájlok, /home full visszapakolása, régi diszk átmenetileg le nem gyalulása mellett.

Értettem minden szavad, de épp ez az, hogy új telepítésnél szerintem észnél kell lenni a konfiggal. Ha pedig mindent másolok, akkor ami eddig ment, az most is fog, ami pedig eddig félre volt konfigolva, az ezután is úgy lesz, ott egye meg a fene! :)

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