Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Pokud bychom chtěli provádět migraci v rámci bitové kopie, tzn., číst data od začátku do konce disku, přesně tak, jak jdou za sebou a ve stejném pořadí je zapisovat i na nový disk, tak si můžeme ušetřit několik problémů, jelikož všechno toto nemusíme dělat:
K tomuto se používá několik druhů řešení, zmiňme tři:
# ddrescue, který se dokáže převalit přes vadné sektory nebo navazovat přerušenou migraci: ddrescue -f -n /dev/sda /dev/sdb log.txt # klasické dd: dd if=/dev/sda of=/dev/sdb # ne moc ideální cat: cat /dev/sda > /dev/sdb
Všechny tyto věci se udělají „sami“ (vše se zkopíruje). Ovšem má to i několik nevýhod:
Naproti tomu, ruční migrace, tzn., rozdělení disku, formátování, kopírování vybraných dat, dotváření adresářové struktury, instalace zavaděče apod. je sice složitější, ale myslím si, že i mnohem výhodnější.
Konzistence dat je celkem problém. Jde nám o to, aby když provádíme migraci živého systému, jsme měli data z určitého času. Představme si, že kopírujeme několik TiB dat z běžícího systému. V takovém případě nemůžou být kopírovaná data nikdy konzistentní, jelikož zkopírování těch dat nějakou dobu trvá (třeba několik hodin) a mezitím se hodně věcí změní, takže soubory, které kopírujeme na začátku budou starší než soubory, jež kopírujeme ke konci a rozdíl může být i několik zmíněných hodin a náš nový systém nebude úplně v pořádku.
Nejideálnější způsob migrace je takový, kdy je systém vypnutý a migraci na jinou stanici/disk provádíme z jiného než migrovaného systému (třeba z Live CD). V takovém případě nemusíme hlídat nějakou konzistenci dat. Prostě PC vypneme, nabootujeme ze záchraného CD a data zkopírujeme na jiný disk.
Člověk je ale tvor lenivý a u pracovní stanice nebo malého serveru není důvod, proč neprovést migraci přímo za běhu. V takovém případě je vhodné stopnout nějaké služby, u kterých nám záleží na konzistenci dat. Takže třeba mailserver, webserver, databázový server apod. Grafické prostředí není třeba vypínat a při migraci si klidně můžete pouštět svou oblíbenou sbírku skladeb, dívat se na film, nebo na novinky na Internetu. Jen je potřeba si dávat pozor, abychom neupravovali nějaká důležitá data.
Jelikož nemigrujeme jen tak z nudy a chceme třeba přerozdělit disk, vyzkoušet jiný souborový systém nebo nasadit LVM, tak budeme provádět ruční migraci v rámci běžícího systému (chci se při migraci dívat na film a ne koukat na čáru života kopírovaných dat).
Zmigrovat běžící systém je celkem hračka. Řekněme, že jsme si do našeho počítače přidali disk (/dev/sdb) a systém migrujeme na něj.
Nejdříve si nový disk vhodně rozdělíme a naformátujeme na – pro nás vhodný – souborový systém. Já si dost často vystačím s jednoduchým programem cfdisk:
cfdisk /dev/sdb
Osobně doporučuji pro desktop rozdělit disk minimálně na 3 oddíly: „/", “/home" a swap. Taktéž nezapomenout na možnost zarovnání: Optimalizace práce s SSD disky v Linuxu. Následně informujeme systém, aby si všiml nových změn (pokud tak již neučinil). K takovému účelu dobře postačuje program partprobe z balíku „parted“:
partprobe /dev/sdb
Partition naformátujeme (každý svým nej souborovým systémem) a nezapomeneme na swap:
mkreiserfs /dev/sdb1 mkreiserfs /dev/sdb2 mkswap /dev/sdb3
Nyní si připojíme oddíl do /mnt, abychom měli kam kopírovat data:
mkdir /mnt/newsys mount /dev/sdb1 /mnt/newsys mkdir /mnt/newsys/home mount /dev/sdb2 /mnt/newsys/home
Po zastavení služeb, u kterých nechceme, aby nám míchaly data, se pustíme do kopírování všeho, co nám přijde do cesty:
cp -av /bin/ /boot/ /dev/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /srv/ /usr/ /var/ /mnt/newsys # vytvoříme symlink "lib64 -> lib" cd /mnt/newsys ln -s lib lib64
Tady bych upozornil na jednu věc, v debianu squeeze je /lib64 hardlink na /lib a v případě, že bychom vše kopírovali najednou, tak dostaneme hlášku:
cp: pevný odkaz „/mnt/newsys/lib64“ na adresář „/mnt/newsys/lib“ nebude vytvořen
Hardlink na adresářích je nepodporovaná záležitost, nechápu tedy, kde se to v debianu vzalo. Známý má vytvořeny klasicky symlinky na všech debianech stejné verze. Já zkoušel čistou instalaci pomocí netinstall a vytvořil se mi hardlink. To, zda se jedná o hardlink lze zjistit např. pomocí utility „stat“:
root@debian:# stat /lib/ File: „/lib/“ Size: 12288 Blocks: 24 IO Block: 4096 adresář Device: 801h/2049d Inode: 40721 Links: 11 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-05-02 21:49:39.000000000 +0200 Modify: 2012-02-25 21:45:58.000000000 +0100 Change: 2012-02-25 21:45:58.000000000 +0100 root@debian:# stat /lib64/ File: „/lib64/“ Size: 12288 Blocks: 24 IO Block: 4096 adresář Device: 801h/2049d Inode: 40721 Links: 11 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-05-02 21:49:39.000000000 +0200 Modify: 2012-02-25 21:45:58.000000000 +0100 Change: 2012-02-25 21:45:58.000000000 +0100
Takže, tuto lehkou odbočku si nechám na jindy (až bude více času nebo se podělte v diskusi, jak si na tom stojí váš Debian), nyní jdeme dál.
Nekopírujeme jen tyto adresáře:
"/mnt" – nebudeme kopírovat „sami sebe do sebe“, když tam máme připojen nový disk
"/media" – podobně jako s „/mnt“, můžeme tam mít připojené nějaké medium apod. a zbytečně kopírovat něco, co nepotřebujeme, ba naopak
"/sys" a „/proc“ – obsah a hierarchii si vytváří jádro a s obsahem v těchto adresářích není, pro neznalé, dobré nijak mainupulovat
"/tmp" – je zbytečné, né-li nežádoucí, kopírovat dočasná data, která se v tomto adresáři vytvářejí
Pokud jde o adresář „/dev“, tak ten se nemusí kopírovat celý, k funkčnosti nám postačí několik málo souborů a zbytek si dovygeneruje udev sám. Ale nemá to cenu řešit, jelikož zkopírování celého adresáře nevadí (udev si to už protřídí).
Co jsme nezkopírovali, musíme dohonit. Takže začneme dovytvářet potřebné adresáře:
mkdir /mnt/newsys/tmp chmod 1777 /mnt/newsys/tmp mkdir /mnt/newsys/sys mkdir /mnt/newsys/proc mkdir /mnt/newsys/mnt mkdir /mnt/newsys/media
Z minulého dílu víme, že je oddíly dobré připojovat pomocí LABEL nebo UUID. UUID se generuje automaticky, ale LABEL nikoli. Kdo používá LABEL, musí si nyní popsat unikátními názvy filesystémy na novém disku (vizte minulý díl). Námi vymyšlené a použité LABELy, nebo v mém případě UUID, přepíšeme v boot manageru (v našem případě grub1):
/mnt/newsys/boot/grub/menu.lst ... # (0) Debian GNU/Linux title Debian GNU/Linux root (hd0,0) kernel /boot/vmlinuz26 root=UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b ro vga=795 initrd /boot/kernel26.img
a v konfiguračním souboru:
/mnt/newsys/etc/fstab # # <file system> <dir> <type> <options> <dump> <pass> devpts /dev/pts devpts defaults 0 0 shm /dev/shm tmpfs nodev,nosuid 0 0 UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b / reiserfs defaults 0 1 UUID=b35303fe-6ece-491b-8661-ded90e2f0bf8 /home reiserfs defaults 0 0 UUID=ac7b118b-f394-46bb-8a1d-458ae32b9e38 swap swap defaults 0 0
Jelikož jsme v běžícím systému a používáme GRUB stejné verze, tak netřeba dělat chroot a můžeme jej rovnou zapsat na druhý disk:
root@debian:# grub GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> root (hd1,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd1) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 17 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd1) (hd1)1+17 p (hd1,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> quit
Nyní stačí vypnout PC, vyndat první disk a voilá, fungujeme z nového disku .
Ne vždy je možné nebo nejjednodušší, připojit druhý disk do stejného počítače a provést migraci. Někdy třeba migrujeme i na jiný počítač. V takovém případě stačí na druhém počítači nabootovat nějaké Live CD (pokud migrujeme 64bit systém, tak nějaké 64bit Live CD kvůli pozdějšímu chrootu), na kterém lze spustit ssh. Poté si na vzdáleném PC provedeme úpravu a připojení partition dle bodů 1. a 2. Kopírování dat na takové PC bude vypadat následovně (kopírujeme z počítače, kde nám běží systém, nejsme tedy již přihlášeni přes ssh na systém livecd):
tar cvf - /bin/ /boot/ /dev/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /srv/ /usr/ /var/ | ssh root@192.168.1.1 "cd /mnt/newdisk && tar xvf -"
Jedná se tedy o klasický „tar over ssh“. Poté se na vzdálený pc opět přihlásíme přes ssh, dovytvoříme adresářovou strukturu (dle bodu 4.), upravíme menu.lst a fstab (dle bodu 5.). Doposud je tedy vše stejné, jako v bodech, jež jsme si uvedli. Jediný rozdíl nastává u posledního bodu, kterým je instalace zavaděče do MBR. Jelikož Live CD obsahuje jiný systém, tak bude potřeba, abychom se chrootli do zkopírovaného systému a provedli instalaci zavaděče z něj. Chroot provedeme takto:
mount -o bind /dev/ /mnt/newsys/dev mount -o bind /proc/ /mnt/newsys/proc mount -o bind /sys/ /mnt/newsys/sys chroot /mnt/newsys/
Nebo takto:
mount -t proc none /mnt/newsys/proc/ mount -t sysfs none /mnt/newsys/sys/ mount -o bind /dev/ /mnt/newsys/dev chroot /mnt/newsys/
Dále zápis GRUBu (máme jeden disk, takže hd0,0):
root@debian:# grub GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 17 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> quit
To je vše, nyní by měl systém bez problémů nabootovat.
Jak lze vidět, ve finále to není nic zabijáckého. Šest drobných kroků a je zmigrováno. Některé věci si lze dokonce i ulehčit. Třeba bod 3. a 4. lze trochu zkrátit tak, že si root oddíl připojíme do nějakého jiného adresáře a odsud root oddíl zkopírujeme na nový disk, čímž by nám vypadl bod 4.
Pro migraci lze využít i sofistikované nástroje, jakými je "partimage", nebo Clonezilla. Nejvíce napřed je CloneZilla, ale ani ta nezvládá migraci disku z většího na menší (pouze na stejně velký nebo větší).
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Jde nám o to, aby když provádíme migraci živého systému, jsme měli data z určitého času.Teda musím říct, že tato věta mi vyrazila dech. Nejsem češtinář, ale pár hrubek tu přímo bije do očí:
cd source; tar -c ./ | (cd dest/; tar -xvf -; )Při migraci souborového systému jsem jednou použil i meziuložiště v podobě druhého disku. Operace pak vypadala následovně:
cd /data tar -c ./ > /dev/sdb umount /data; mknovyfs /dev/sdaX; mount /dev/sdaX data/; cd /data/ tar -xvf /dev/sdbKdyž jsem migroval data z datového úložiště, tak mi přišlo zbytečné, abych ukládal ohromný stream dat na souborový systém, když to není potřeba... Použít celý dosk bylo logické, navíc tím odpadla režie oprací FS vrstev...
+1 (teda, az na to, ze "xvf" se pise bez "-" a mas tam navic zbytecne jeden strednik )cd source; tar -c ./ | (cd dest/; tar -xvf -; )
cd /dest; do_something
bych vřele doporučoval použít cd /dest && do_something
. Ono se to cd
nemusí vždy podařit .
U toho taru samozřejmě stačí tar c . | tar x -C dest/
# box 0 tar -cf | netcat -l -p 12345 # box 1 netcat box0 12345 | tar -xf -
# box 0 dd if=/dev/md0 bs=1480 | netcat -l -p 12345 # box 1 netcat box0 12345 | dd of=/dev/md1
tar cvf - /bin/ /boot/ /dev/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /srv/ /usr/ /var/ | ssh root@192.168.1.1 "cd /mnt/newdisk && tar xvf -"Taky jsem to tak dělal. Pak mi ve 2/3 kopírování 120GB disku spadnul net.
-p, --preserve-permissions, --same-permissions extract information about file permissions (default for superuser)Toto je asi ten důvod, proč se tím člověk nezabývá, je to prostě default a pod rootem to není třeba.