Názory k článku Klonování Linuxu aneb přenášíme celý systém
-
Jo a dd nejde dělat když je klonovaný disk namountovaný. Cílový disk by měl být stejně velký nebo větší. A pokud kopírujete z disku který má nějaké problémy, je lepší kopírovat na nový zdravý souborový systém.
Pokud chcete využít více místa nového disku, musíte "upravit velikost" naklonovaného disku.A co pokud potřebuji aby měl nový disk jinak rozdělený? Třeba jinak velký swap a jinak velké oblasti. Nebo mohu chtít kopírovat jen jednu oblast a ostatní nechat jak jsou.
-
Palo (neregistrovaný)
Vy ste uz taky novi unixaci. Tolko nastrojov a programov co boli spomenute v tomto clanku som ja v zivote ani nevidel nie to este ich pouzil.
Vytvorenie bootovatelneho USB kluca sa da aj pomocou 'cat' aj 'dd' len treba vediet ako.
Ked chcem kopirovat disk tak DD je skvely nastroj 'obzvlast' na poskodene disky pretoze skopiruje mozno aj chyby ale repair potom spustam na dobrom disku po skopirovani a netrapim povodny disk ktory mozno uz o 100 citani nebude absolutne prevadzky schopny.
Ak potrebujem kopirovat obsah tak po starom sa to robilo cez 'cpio' a na iny server PIPE cez ssh na druhy server rovno do druheho cpio. Kompresiu cestou zabezpecil GZIP v PIPE pred ssh.
Ale rsync je OK, pouziva ho vela ludia a funguje uz dlho.
A na zaver ked som sa pustil uz do klasiky tak na synchronizaciu je namiesto rsync pouzitelny 'unison' (http://www.cis.upenn.edu/~bcpierce/unison/) ale na ine pouzitie, na kopirovanie je lepsi rsync preto ale pouzivam cpio takze potom rsync vobec nepotrebujem.
Takto to robim ja 'po starom' bez potreby mat program na kazdu blbost a dolezite je ze vacsina z toho funguje aj na NON linux systemoch. -
BobTheBuilderStříbrný podporovatelJeště lépe je použít ddrescue - jednak ukazuje průběh a hlavně nečitelné sektory přeskočí a pak se k nim vrátí a opakovaně je zkouší zkopírovat s menší velikostí bloku.
-
Palo (neregistrovaný)
JJ, ja som musel s 'ne' debian USB robit iba raz. Debian ide aj cat aj dd. Niekedy je treba urobit particiu nastavit ako AKTIVNU a az do nej hodit ten image (to uz tiez ide cez cat aj dd iba sa pouzije e.g. sdX1), samozrejme obcas treba nakopirovat aj MBR do prvych bajtov, nieco ako:
dd if=/dev/sda of=/dev/usb bs=446 count=1 -
Pri rozlozeni 128MB /boot jako prvni partisna a pak rootfs je muj postup zkopirovat pres dd ten zacatek, pak fdisk na upravu velikosti rootfs oddilu, mkfs.ext4, mount a na rozdil od autora pro aktualne bezici fs delam mount -o bind / /mnt/old .. a nemusim resit odkud se bere aktualni rootfs. cp -va, uz jen zmenit v /etc/fstab uuid pro rootfs, a stejne tak v novem grub.conf to uuid a je hotovo.
-
msx (neregistrovaný)
Našiel som toto:
http://wiki.ubuntu.cz/p%C5%99esun_ubuntu_na_jin%C3%BD_disk -
Myslíte tohle? http://wiki.ubuntu.cz/záloha_a_obnova_systému
Není to totéž. Vypadá to na jednodušší ale podobný způsob jak provést zálohu do jednoho tar archivu. A pak i obnovu. Neřeší ale možné a pravděpodobné potíže s bootováním nového systému v novém umístění. Tiše se zjevně předpokládá obnova na stejný disk a stejný oddíl, nebo alespoň přítomnost předchozí instalace ubuntu, kterou touhle obnovou přepíšeme. -
Honza (neregistrovaný)
Ahoj,
pokud by se nekomu hodilo, mam odzkousen nasledujici postup.
Kopirovani zivych dat je vzdy nejiste, osobne bych prvne remountnul vsechny
fs na read-only. Naslednym prikladem je mozne zklonovat bezici system do
jineho beziciho systemu (a ten zaziva prepsat):Zdrojovy server:
dd if=/dev/sda bs=1M | pv | gzip -1 | nc -v -w 2 127.0.0.1 31000
Cilovy server:
nc -l -p 31000 | gzip -d > /dev/sda
Priklad predpoklada ssh spoj s port forwardingem, pokud to jde nezabezepecenou linkou. Jinak je mozne pro nc pouzit prime IP... Remount na RO je nutny i na remote strane!!! Read only znamena je RO pro filesystem, ale nic nebrani zapisu primo na disk. Pravdepodobne po dokonceni kopirovani, bude nutny tvrdy restart - napr. pres remote konzoli, protoze nepujde pustit zadny prikaz, tj. ani reboot ;-)
Honza
-
j (neregistrovaný)
A co tahle kdybys prohledal diskuse tady na rootu? Variant je tu minimalne par desitek. Nejspolehlivejsi je asi rsync, kterej to veme vsechno, vcetne prav. Jediny co pak treba je instalnout gruba, coz se da udelat jako dalsi krok ve scriptu, pokud bys to takhle chtel kopirovat na 100 disku.
a mimochodem
/etc/udev/rules.d/70-persistent-net.rules.davno nefunguje.
-
Já ale nechci prohledávat diskuze. Chci, aby někdo, místo "hospodského pindání" v diskuzích našel koule a napsal článek, jak to udělat nejlépe.
Myslím, že root jej velice rád zveřejní. Pokud náhodou ne, a pisatel jej nebude mít kde zvežejnit, klidně jej dám k sobě s tučně napsaným "tohle napsal j (neregistrovaný). -
Trident (neregistrovaný)
Chtit muzes. To je asi tak vsechno. To ze napises chci aby..., tim se snizujes na uroven rozmazleneho decka a nebo ridiciho pracovnika - deprivanta. Tady nejsi v pozici aby jsi neco mohl chtit.
Takze pokud neco chces, tak si to zaplat. Pokud nechces platit tak nepouzivej slovo "chci", ale byl bych rad,bylo by dobre, nema nekdo lepsi reseni a podobne.Mimochodem to jak je ktera metoda efektivni se odviji od zdroju ktere mam. Je jasne ze ve spouste malych firmach kde udrzuji par keplu v datacentru asi vetou "a pak si to prenastavte na storagi a fc switchi a initnete radsi loopu" nikomu neprospeju. Akorat nas... lidi kteri nemaji zdroje a penize na proprietarni technologie. Stejne tak "udelejte si snapshot" asi taky nebude to prave kdyz urcite takova polovina linuxaku ma extX a jeste je treba potom resit partisny,bootloader.
Clanek psat nebudu protoze se mi to nevyplati a nemam hlavne cas.
-
j (neregistrovaný)
Tak deb je 100 let za vopicema, od udev nevim kolik (parkrat semeto sem psal) je z udevu (protoze ten pozraly ty idioti od systemd) vyhozenej kod, ktere umoznuje svazat MAC a ETHx.
Takze jediny co muzes, je zjistit si, jak se tvoje karty jmenujou (jsou to takovy ty hruzonazvy) a dat jim aliasy, treba jenicek a marenka. Ale dat jim ethX uz proste nemuzes.
Jop, ted sem to nasel:
2013-03-29-udev-upgrade
Title Upgrading udev to version >=200The file 70-persistent-net.rules, like the 70-persistent-cd.rules
should be removed, so if you modify, rename the file also to something
else like 70-my-network.rules to silence the deprecation warning coming
from the end of the sys-fs/udev ... -
nobody (neregistrovaný)
nechat jim davat ethX/wlan0 muzes pouzitim kernel parametru "net.ifnames=0", od verze udev 197... viz bod 4 na konci:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -
j (neregistrovaný)
Sem si zcela 100% jistej ze nelze, protoze v udev neni prislusnej kod. Ten byl s prave zminenou verzi odstranen (protoze to nebylo politicky spravne, hrabat z userspace do kernel space, a prej to "nekdy" nefungovalo). Vyzkousej si to, vem si stroj, kde mas 2 sitovky (v podobe karet) a prohazuj je do ruznych slotu (a klidne si pritom nadeklaruj pravidla). Pokazdy to bude jinak. Jediny co tim prepinacem zaridis je to, ze nebudou dostavat ty chory nazvy. Pridelit nazev podle MAC proste nelze, a to tak ze nijak. Teda pokud nebudes hackovat kernel/udev.
Na nekolika strojich sem to resil osobne, a protoze sem vazne nehodlal predelavat tisice pravidel firewalu a stovky vsemoznych scriptu, tak se mi jako (zatim) jediny reseni vyjevilo zakazat se hrabat v HW, pomodlit s ke vsemohoucimu ...(myslim toho dole) a poprehazet kabely v sitovkach tak, jak je system nasel.
-
nobody (neregistrovaný)
Ehm... dal sem si tam tri sitovky, dostali nazev eth0, eth1, eth2... a jsem tu.
Pravidlem mam dle MAC prirazeni tech nazvu, kdyz vsecny sitovky odeberu a vracim je zpatky v libovolnem poradi, dostavaji nazev prirazenej dle MAC...Jedinej rozdil vidim ten, ze pokud vrazim sitovku s MAC adresou ktera NEMA pravidlo, a sitovku ktere maji pravidla nejsou pritomny, tak jim to prirazene jmeno sebere...
To ale neni situace "nedrzi si nazvy co mely pri instalaci/konfiguraci", protoze DRZI, ale situace "posrala se mi sitovka", tak ji vyndam, vrazim jinou a ta jina prevezme jmeno po te posrane i presto ze ma jinou MAC, teda to chovani se da povazovat za rozumne ;)
-
Je to tak. Nahlásil jsem uvidíme jestli opraví v hlavním článku.
Nyní jsem se pokoušel postupovat podle vlastního návodu, kdy jsem kopíroval systém s obyčejného disku na SSD a narazil jsem na dilema, jak rozdělit nový disk. A tak mne napadá, že se podělím.
Počítač pořád bootuje přes BIOS. Vyvstává tedy otázka, jaký typ partition table použít.
V programu gparted v menu device -> create partition table připadá v úvahu msdos nebo novější GPT. Možné je oboje.ALE pokud použiji novější GPT a hodlám bootovat pomocí BIOSu musím na začátku udělat malý oddíl pár MB, aby se měl kam nahrát GRUB. Bez této speciálné oblasti typu boot_grub selže instalace GRUBu. Boot-Repair-Disk alespoň vysvětlí proč a navrhne dodatečné vytvoření této oblasti pomocí gparted , což ale trvá dlouho, protože se data musí fyzicky přemisťovat na disku, aby uvolnili začátek oblasti.
Udělat tuhle speciální oblast může být dobrý nápad už jen "pro jistotu" aby disk byl bootovatelný z jakéhokoli počítače.Pokud chci bootovat pomocí UEFI, je nutnost speciální oblasti dobře popsaná a zřejmá i v samotném článku. Oblast v tomto případě nemusí být jako první.
-
Barbucha (neregistrovaný)
Ono v dnesni dobe vzhledem ke kapacitam disku neni od veci, kdyz uz nejaky disk rozdeluju, vytvorit si EFI partition i v pripade, kdy z nejakeho duvodu bootuju pomoci BIOSu.
Je mozny pouzit takovou oblast pro GRUB misto toho maleho par MB oddilu a pozdeji napr. s novym hardwarem pak teto oblasti staci nastavit patricny typ (pripadne prevest tabulku na GPT, pouzival-li jsem z nejakeho duvodu MBR), naformatovat na FAT, vytvorit par adresaru a zacit bezbolestne bootovat pomoci UEFI.
-
Další soubor, kde se vyskytuje uuid původního disku se zdá být
/etc/uswsusp.conf
V mém případě bootování se kousnulo cca na pět minut a poté jsem dostal hlášku
"Could not stat the resume device file".Řešení je popsáno zde.
http://askubuntu.com/questions/411583/could-not-stat-the-resume-device-file
