Přesun systému na jinou partition

Ahoj, řeším teď zdánlivě jednoduchou věc.
Mám disk na kterém jsou dvě partitions

 
fdisk -l 
/dev/sda1   *           1          41      329301   83  Linux 
/dev/sda2              42       30401   243866700   83  Linux

sda1 /boot (ext2)
sda2 / (ext2)

Připojil jsem druhý disk na kterém jsem vytvořil pouze jednu partition:

sdb1 / (ext3)

Nabootoval jsem z CD linux rescue a mountnul potřebné oddíly pro přesun systému

 
mount /dev/sda2 /mnt/old
mount /dev/sda1 /mnt/old/boot
mount /dev/sdb1 /mnt/new

Pak jsem přesunul data

 
rsync -a /mnt/old/ /mnt/new

Doplnil jsem

 
mount -o bind /dev /mnt/new/dev
mount -o bind /proc /mnt/new/proc
mount -o bind /sys /mnt/new/sys

Pak jsem se chrootoval do /mnt/new

 
chroot /mnt/new /bin/bash

Upravil jsem fstab tak, že jsem zakomentoval LABEL=/boot /boot a upravil změnu FS na ext3

 
/dev/sda1               /                       ext3    defaults        1 1
# LABEL=/boot           /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

Pak jsem zkoušel nainstalovat grub a tam jsem pohořel. Napsalo to nekorektní stage1 atd.

 
grub-install /dev/sda

Zkoušel jsem i přímo přes konzoli grub

 
grub > find /boot/grub/stage1

Výpis zněl: Soubor nenalezen

Bude to asi nějaká drobnost, kterou jsem přehlédl ale zkoušel jsem i odpojit původní disk a nabootovat z CD jen s tím novým. Mountnout ho a znovu se chrootovat - bez výsledku.

Předem díky za nápady

Nezůstalo Ti na novém disku v /etc/mtab něco jako

/dev/sda1 /boot ext2 ... 

Grub by pak hledal (podle find, který jsi psal) v /boot/boot/grub… Pokud samotný oddíl pro /boot používat nebudeš, mělo by pomoct odstranění tohoto řádku.

stderr napsal(a):

Nezůstalo Ti na novém disku v /etc/mtab něco
jako

/dev/sda1 /boot ext2 ... 

Grub

by pak hledal (podle find, který jsi psal) v
/boot/boot/grub… Pokud samotný oddíl pro /boot
používat nebudeš, mělo by pomoct odstranění
tohoto řádku.

Ahoj /etc/mtab jsem také upravil tak, že tam zůstalo

/dev/sda1 /  ext2 ... 

Ale zjistil jsem že v grub.conf je root odkazán na LABEL což bude asi ten problém. Tohle jsem přehlédl. Zkusím nastavit novému disku stejný label a nebo upravím parametr v grub.conf


root=LABEL=/

na


root=/dev/sda1

Koukám jak jednoduše člověk přehlédne tak podstanou věc … :smiley:
Vím že toto rozložení není optimální a v tomto případě to možná nedává smysl, popisuji pouze modelovou situaci na které jsem testoval jestli to vůbec takto jde nebo ne. Tuto situaci potřebuji vyřešit na soft raidu, kde mám už malé disky špatné rozložení na jednotlivé partitions - kde kvůli optimalizaci raidu a algoritmům se rozložení na několik oddílů nehodí a zároveň potřebuji změnit souborový systém. Takže reálná situace je taková, že potřebuju starý RAID 1 přesunout na nový větší s novým souborovým systémem a pouze s jednou partition :smiley:

Díky moc, výsledek sem doplním během dne.

Hmm, se mi nějak nezdá, že by si grub kontroloval parametry kernelu… To by mělo imho způsobit “jen” kernel panic při bootování. Ale třeba to vyjde. Kdyby ne, tak zkus ještě zkontrolovat ten mtab, /proc/mounts (měly by se až na rootfs shodovat) a /boot/grub/devices.map. Nebo ještě před find… zkusit definovat zařízení:

grub> device (hd0) /dev/sda

No a s raidem to bude dvojnásobná čurina :slight_smile:

/etc/mtab jsem kontroloval a mám v něm pouze dva řádky, jak na staré partition tak na nové a to:


/dev/sda1 / ext2 ...
proc /dev/proc proc ...

Pokud ale nabootuju standardně ze starého disku. Tak mtab má mnohem více řádků.
Nastavení hd0 na /dev/sda jsem provedl a stejně to píše soubor nenalezen. To jsem z toho jelen …

Jinak /proc/mounts je prázdný na obou discích…

Priznam se, ze sem se v popisu po chrootu ztratil. Jak muzes dela grub-install /dev/sda kdyz disk mas /dev/sdb? Predelal si device.map? Podle me na to mtab nema vliv. mtab je stary mechanismus do ktereho se zapisovali pripojene svazky, ale je to jen generovany soubor, zapisovat do nej podle me nema smysl, stejne se to prepise.
Co mas presne v grub.conf? Nemas pouzit parametr boot=/dev/sda?

Dal pozor na to, ze grub (i 2) umi startovat jen z nekterych typu souborovych systemu (podle syntaxe pouzivas jeste grub1, ten je na tom jeste hur).

Dalsi legrace te bude cekat s initramfs, ale tam ses jeste nedostal. Ten musis pregenerovat se zmenami, ktere si udelal.

Uprimne nevim proc to musi byt v jednom oddilu, proste na novem raidu ten boot oddil zvetsi - zapasil jsem s tim taky, protoze starsi verze Fedory delali oddily male (100MB musi stacit kazdemu), ted se dela 500MB a kdo vi jak dlouho to vystaci ze.

covex napsal(a):

Priznam se, ze sem se v popisu po chrootu ztratil.
Jak muzes dela grub-install /dev/sda kdyz disk mas
/dev/sdb? Predelal si device.map? Podle me na to
mtab nema vliv. mtab je stary mechanismus do
ktereho se zapisovali pripojene svazky, ale je to
jen generovany soubor, zapisovat do nej podle me
nema smysl, stejne se to prepise.
Co mas presne v grub.conf? Nemas pouzit parametr
boot=/dev/sda?

Dal pozor na to, ze grub (i 2) umi startovat jen z
nekterych typu souborovych systemu (podle syntaxe
pouzivas jeste grub1, ten je na tom jeste hur).

Dalsi legrace te bude cekat s initramfs, ale tam
ses jeste nedostal. Ten musis pregenerovat se
zmenami, ktere si udelal.

Uprimne nevim proc to musi byt v jednom oddilu,
proste na novem raidu ten boot oddil zvetsi -
zapasil jsem s tim taky, protoze starsi verze
Fedory delali oddily male (100MB musi stacit
kazdemu), ted se dela 500MB a kdo vi jak dlouho to
vystaci ze.

Ahoj psal jsem, že je to modelová situace. Potřebuji pochopit základní principy a závislosti abych mohl uskutečnit přesun na reálném softraidu, který jede na centos. Můj problém nespočívá v partition /boot jelikož na serveru ji nemám tam jsou na RAID 1 partitions:


/dev/md0   /       ext2
/dev/md1   /data   ext2

Na testování jsem měl ale systém který měl /boot jako samostatnou partition a to trochu zkomplikovalo situaci.
K tomu rozdělení oddílů na jednu parttitions jsem se rozhodl proto, že dva oddíly ze kterých se různě čte a různě zapisuje snižují výkon RAID 1. Což jsem tehdy nevěděl samozřejmě že oddíl /boot by takový vliv na výkon neměl. Navíc jsem chtěl změnit souborový systém.

Rád bych ale dokončil to co jsem začal takže teď ty odpovědi:

a) grub-install /dev/sda jsem dělal proto, že původní disk jsem mezitím odpojil a tudíž byl skutečně /dev/sda
b) device.map - obsahoval úplný nesmysl (hd0) /dev/hdb ale to jsem přepsal na /dev/sda.
c) boot=/dev/sda? mám zakomentovaný

Nakonec se mi podařilo, že mi naskočilo alespoň menu grub s výberem kernelu ale druhý stage už nenaběhl. To bude mít asi souvislost s tím initramsfs. Tam už moje znalosti končí.

Díky za reakce …

Stage bych do toho tedy asi nepletl. Grub se sklada ze stage, kdyz ti nebhne menu, pak stage1 ktery je v MBR nasel stage2, ktery je v /boot. Pokud ti zacne startovat kernel, pak byl nalezen i obraz jadra, pak teprve prikazi na radu initramfs. Initramfs pregenerujes prikazem dracut v zachrannem modu (chroot).

Díky za vysvětlení, v těchto návaznostech mam ještě mezery, proč je ale nutné přegenerovat initramfs ? A je to nutné vždy ? Jestli jsem to správně pochopil, tak pokud nemám /boot jako samostatnou partition, tak není nutné přegenerovat initramfs ? A nebo to pak má souvislost se změnou souborového systému z ext2 na jiný ?.

V initramfs je i fstab, pokud ho zmenis, musis menit i initramfs. Dale v initramfs jsou pouze ovladace pro aktualne pouzivany HW, muzes si vytvorit initramfs se vsemi moduly, je na to parametr pro dracut - ale proste pokud presunes OS na jiny HW, nemusis mit potrebne moduly ve vychozim initramfs. Muze s tim souviset i zmena FS. Nevim z ceho na co to chces menit, nicmene vechny EXT jsou u Fedory zakompilovane v jadre, ale nemusi to byt pravidlo.

Drobná oprava: fstab v initramfs není. jsou tam ale jiné drobnosti, jako mdadm.conf, což se při migraci sw raidu taky mění, takže překopat by se měl tak jako tak. Nevím, jak je to v novějších Fedorách, ale pod Centosem 5 i 6 stačí pustit mkinitrd:


mkinitrd -f -v /boot/initramfs-2.6.32-279.5.2.el6.x86_64.img 2.6.32-279.5.2.el6.x86_64

kde 2.6.32-279.5.2.el6.x86_64 je aktuální kernel.

Určitě ale pomůže, pokud sem hodíš, na čem to končí.

stderr napsal(a):

Určitě ale pomůže, pokud sem hodíš, na čem
to končí.

Dobře, reálně tedy potřebuji udělat toto:

Železo: 1U server HP Proliant DL320 G05,
System: Centos 5.8 - Linux 2.6.18-308.8.2.el5 on x86_64
Dvě šachty hotplug na SATA disky.

Jedná se o přesun systému v rámci jednoho a toho samého hardwaru na nové disky (resp. nový softraid) a jiný FS (ext3). Současný raid-1 má dvě partitions.


/dev/md0  /      (ext2)
/dev/md1  /data  (ext2)

Chtěl bych to přesunout na dva 1TB disky pod nový raid-1 pouze pod jednu partitions


/dev/md0  /      (ext3)

Nechci to přesouvat přes dd jelikož bych musel ručně upravovat tabulku oddílů zvětšovat ji, a navíc následně zvětšit souborový systém a ještě i RAID. Jednodušší varianta mě přišla to prostě jen zkopírovat postupem, který jsem uváděl výše. Díky tomu, že nemám víc šachet pro disky musím tedy současné pole degradovat. Poté start z CD linux rescue. staré pole přes assemble přejmenovat na jiné. Do druhé šachty strčit nový 1TB disk a vytvořit nové pole /dev/md0 též v degradovaném režimu. Následně zkopírovat rsysncem systém ze starého raid na nový. Upravit fstap (kde zruším partition /data) a upravim fs pro / na ext3, pak bych měl na nový degradovaný raid-1 nainstalovat grub, nevím jestli bude nutné v tomto případě měnit initrd, když se jedná o stejné železo ale kvůli změně ext2 na ext3 asi ano. Nakonec vyhodím poslední starý disk a nahradím za druhý 1TB, zkopíruji tabulku oddílu


dd if=/dev/sda /dev/sdb bs=512 count=1 

pak ho vložím do běžícího aktivního raidu a synchronizuji je.

Tak tohle je teorie. Praxe je trochu jiná alespoň dle mé zkušenosti to není tak jednoduché jak se jevilo :-D.

Pokud Vás někoho napadá nějaká jednodušší myšlenka, budu jedině rád.
Hezký den

Jo, tohle je vzdy neprijemne - menit disky, nebo cele servery, kopirovani terabytu dat atd a problem jmenem downtime. Ani ten rsync totiz neni “vsemocny”. Pokud takto kopirujes FS za behu, trva to i nekolik hodin, mezitim se ti soubory na puvodnim FS meni ovsem na novem uz ne. Navic doporucuji dobre prostudovat manual k rsyncu.

Pokud bych mel rici za sebe tak v tomto pripade bych asi sel jinou cestou - proste vymenit v raidu jeden disk za vetsi, sesynchronizovat, vyndat mensi, prekonvertovat typ FS (ext2->ext3 jde za chodu), zvetsit oddil pro data - pokud tedy nemas problem s velikosti oddilu pro /. Myslim ze mit system a data na jednom oddile neni dobry napad. Cokoli s tim budes v budoucnu delat, budes muset operovat s 1T dat, nebo vyzobavat adresare systemu. Ja bych to nespojoval.

covex napsal(a):

Pokud bych mel rici za sebe tak v tomto pripade
bych asi sel jinou cestou - proste vymenit v raidu
jeden disk za vetsi, sesynchronizovat, vyndat
mensi, prekonvertovat typ FS (ext2->ext3 jde za
chodu), zvetsit oddil pro data - pokud tedy nemas
problem s velikosti oddilu pro /. Myslim ze mit
system a data na jednom oddile neni dobry napad.
Cokoli s tim budes v budoucnu delat, budes muset
operovat s 1T dat, nebo vyzobavat adresare
systemu. Ja bych to nespojoval.

Tuto variantu jsem taky uvažoval. Z pohledu počtu operací je asi nejjednodušší ale neřeší všechno. Zvětšit oddíl /data a následně FS není problém. Jenže při tom bych /dev/md1 musel stejně odpojit a tudíž by byl nedostupný. Na partition /data jsou zdroje pro virtuální webservery, smtp, pop3, imap server, schránky uživatelů atd. Navíc jak jsem psal a dočetl se, ovladač RAIDu se snaží optimalizovat čtení z pole a čte buď z prvního disku, který nic neprovádí nebo z disku od kterého naposledy požadoval přístup do nejbližší oblasti. Protože poslední oblast přístupu je uložena v informacích o každém RAID poli, nebude se tento algoritmus při více polích na jednom disku chovat moc efektivně. A to mohu v mém případě potvrdit. Přesun dat z partition / na /data je neúměrně dlouhý - rychlost okolo 16-20 MB/s - zdůrazňuji, že nejde o kopírování ale o přesun. Navíc rizika se zvětšováním oddílu a FS také nejsou nezanedbatelná.

Sám nevím pro co se rozhodnout … rozhodně to ale nechci celé instalovat znovu :-). To by bylo na týden práce a to nemluvím o downtimu :smiley:
Díky

Zalohu pro pripad, ze by se zmena velikosti oddilu nepovedla mas na starych discich. Zmena velikosti oddilu je radove rychlejsi operace nez kopirovani dat. Prekonvertovani na ext3 jde za behu a resize2fs na read-only urcite, s ext3 by mohl byt mozny i rw.

man resize2fs:
“As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 and ext4.”

S temi vykonostnimi problemy nevim jak to presne myslis. Degradace pole a zamena disku je vzdy vykonostni propad prip rekonstrukci pole. Zadne jine presuny dat, pokud se vydas touto cestou, te necekaji.

Nakonec mi to nedalo a ledy se prolomily. Otestoval jsem obě varianty a obě proběhly dobře. Někomu se může hodit 1. někomu 2. Postup zde tedy popíši uceleně a téma tím uzavřu s poděkováním všem co se zde zapojili. Postup platí pro přesuny v ramci jednoho a toho samého stroje.

1. varianta - ponechání oddílů tak jak jsou, pouze výměna disků v raidu za větší.
Nejprve tedy vyřadíme jeden z disků v raid 1 se dvěma oddíly např. (md0=/, md1=/data)


    mdadm -f /dev/md0 /dev/sdb1
    mdadm -r /dev/md0 /dev/sdb1
    mdadm -f /dev/md1 /dev/sdb2
    mdadm -r /dev/md1 /dev/sdb2
    

Vložíme nový větší disk a zkopírujeme MBR včetně bootloaderu.


    dd if=/dev/sda of=/dev/sdb bs=512 count=1
    fdisk /dev/sdb (odebereme oddíl sdb2 a vytvoříme nový s max. velikostí a zapíšeme změny)
    

Přidáme disk se všemi oddíly do RAID 1


    mdadm --add /dev/md0 /dev/sdb1
    mdadm --add /dev/md1 /dev/sdb2
    

Po kompletním rebuildu odebereme i druhý disk /dev/sda


    mdadm -f /dev/md0 /dev/sda1
    mdadm -r /dev/md0 /dev/sda1
    mdadm -f /dev/md1 /dev/sda2
    mdadm -r /dev/md1 /dev/sda2
    

Odpojíme /dev/md1 aby jsme ho mohli zvětšit na max.


    mdadm --grow /dev/md1 --size=max
    

Provedeme kontrolu FS a poté ho zvětšíme na max.


    fsck -n /dev/md1
    e2fsck -f /dev/md1
    resize2fs /dev/md1
    

Vložíme druhý stejně veliký disk, zkopírujeme opět MBR a bootloader tentokrát z /dev/sdb na /dev/sda a nové partitions vložíme do pole. Po rebuildu je to komplet.
V případě potřeby změny FS např. z ext2 na ext3 lze doplnit.


    tune2fs -j /dev/md0
    tune2fs -j /dev/md1
    vim /etc/fstab (přepsat ext2 na ext3)
    

2. varianta - přesun raid1 na nový raid1 s úpravou oddílů, změnou velikosti bloku a změnou FS
Vyřadíme jeden z disků v raid 1 se dvěma oddíly např. (md0=/, md1=/data)


    mdadm -f /dev/md0 /dev/sdb1
    mdadm -r /dev/md0 /dev/sdb1
    mdadm -f /dev/md1 /dev/sdb2
    mdadm -r /dev/md1 /dev/sdb2
    

Vložíme nový disk /dev/sdb a vytvoříme oddíly dle libosti pro příklad tedy pouze jeden /dev/sdb1. Bude se tedy jednat o přesun systému a dat pod jednu partitions RAID 1 ( /dev/md0). Restartujme PC a nabootujeme z live CD/DVD.
Přejmenujeme původní raid oddíly na jiné…


    mdadm --stop /dev/md0
    mdadm --stop /dev/md1
    mdadm --assemble /dev/md50 /dev/sda1 missing
    mdadm --assemble /dev/md51 /dev/sda2 missing
    

Aby jsme nemuseli instalovat grub tak zkopírujem MBR vč. bootloaderu a fdiskem upravíme oddíly jak potřebujeme v našem případě odstraníme /dev/sdb2 a /dev/sdb1 zvětšíme na max. a vytvoříme nový raid 1 z disku /dev/sdb


    dd if=/dev/sda of=/dev/sdb bs=512 count=1
    fdisk /dev/sdb
    mdadm --add /dev/md0 -n 2 -c 128 -l 1 /dev/sdb1 missing     {RAID1 degradovaný, velikost bloku 128k}
    mkfs.ext2 /dev/md0 {naformátujeme na ext2)
    

Připojíme starý raid a nový raid do nově vytvořených adresářů v /mnt.


    mkdir /mnt/new
    mkdir /mnt/old
    mount -t ext2 /dev/md50 /mnt/old
    mount -t ext2 /dev/md51 /mnt/old/data
    mount -t ext2 /dev/md0 /mnt/new
    

Přesuneme systém i data rsyncem a přepíšeme původní konfiguraci raid polí novou aktuální, dále upravíme původní /etc/fstab ze kterého vymažeme /dev/md1 /data ext2 …


    rsync -avx /mnt/old /mnt/new
    mdadm --examine --scan > /mnt/new/etc/mdadm.conf   {odstraníme řádky týkající se pole md50 a md51 ty potřeba nejsou}
    

Nevím jestli je to nutné pro generování nového initramfs ale raději jsem to udělal také - připojení proc,sys,dev. Poté se chroot(ujeme) do nového systému a přegenerujeme initramfs jak psal výše “stderr”


    mount -t proc   proc      /mnt//new/proc
    mount -t sysfs  sys       /mnt/new/sys
    mount -o bind   /dev      /mnt/new/dev
    chroot /mnt /bin/bash
    mkinitrd -f -v /boot/initramfs-2.x.x-x.x.x.x.x.img 2.x.x-x.x.x.x
    

Restartujeme a odpojíme poslední disk ze starého raid /dev/sda. Po restartu by měl systém sám naběhnou pouze s jednou partitions /dev/md0 připojená jako /. Přidáme druhý disk pro zkompletování pole, zkopírujeme MBR vč. bootloader, přidáme /dev/sdb1 do pole a je to.
Alespoň mě to takto fungovalo. Chybu, kterou jsem od začátku dělal při testování varianty 2 byla ta, že jsem vynechal přepsání konfiguračního souboru raid /etc/mdadm.conf, který je jak píše “stderr” uložen v initramfs - což jsem netušil. Také jsem se zbytečně trápil s instalací grub na degradované pole v mém případě opravdu zbytečně.

Jinak co se týče výkonu, je velmi znát co se týče rychlosti čtení nebo zápisu z raid jestli je raid-1 jen jako jedna partition a nebo více. Při použité jedné je výkon razantně vyšší !!! - pokud se někdo chystáte využívat softraid, tak pokud nemáte vyloženě pádný důvod to rozdělovat tak to nechte vše na jedné partition.

Obě varianty jsem úspěšně otestoval, tak jak popisuji na systému Centos 5.8. Ve fedoře to bude pravděpodobně stejné.
Ještě jednou děkuji za příspěvky a pokud jsem se někde upsal v postupu, tak mě opravte.