Proc pouzivat System rescue?
Mam Gentoo AdminCD natlacene do usb klice a zatim jsem si s tim vystacil - plus se mi nestane ze by to melo nejaky stary jadro, jak je to rolling distro. Samosebou pouzivam Gentoo i na strojich... a aktualizuji.
Zvlastni, ze neco se zavedlo uz pred 2 lety a vy jste nebyl schopen si system aktualizovat.. a jeste se tomu divite :-)
I staré jádro je občas potřeba, když je potřeba opravit staré věci (starý hardware, starý filesystém... stalo se mi třeba s btrfs)
Mě docela naštvalo, když System Rescue odstranili staré verze z webu (někdy v době přechodu z Gentoo na Arch). Tu a tam narážím na potřebu se k něčemu vrátit a kvůli nim si musím udržovat vlastní archiv, abych měl kam sáhnout, když ta potřeba nastane.
Gentoo AdminCD obsahuje gparted a partimage? Funguje na něm mc? Funguje tam iotops. htop, bc, ssh, ntfs3g... ? Je někde seznam nástrojů. které obsahuje?
Vidím odkud ho stáhnout, ale obsah leda až ho někde nabootuju
https://www.gentoo.org/downloads/
Gentoo AdminCD - hádám - neobsahuje nástroj na resetování lokálních Windows hesel, to se mi párkrát na System Rescue hodilo. Opakovaně ho taky používám kvůli Memtestům (různým, podle stáří hardwaru).
> Gentoo AdminCD obsahuje gparted a partimage? Funguje na něm mc? Funguje tam iotops. htop, bc, ssh, ntfs3g... ? Je někde seznam nástrojů. které obsahuje?
Nemůžeš si na flashku nainstalovat normální distribuci? V dnešní době rychlostí a kapacit je to úplně v pohodě. A fstab stačí napsat s UUID a pak se to detekuje na libovolných počítačách bez problému.
aktualni AdminCD je zalozeno na hardened vetvi, seznam baliku je v Stage1 spec skriptu (Stage2 obsahuje pak deinstalaci a procisteni distribucniho buildu):
https://gitweb.gentoo.org/proj/releng.git/tree/releases/specs/amd64/hardened/admincd-stage1.spec
bc - je soucasti zakladni instalace (klasicky stage3 rootfs)
iotop, htop, openssh, ntfs3g, mc - jsou doinstalovany skrze linkovany .spec
To by taky šlo. Já teda znovu nebootoval System Rescue a udělal aktualizaci v chroot. Taky je otázka, jestli bude vaše distribuce mít ten potřebný aktuální E2fsprogs. Gentoo to má jako nestabilní ~amd64, proto jsem to neměl. V Debianu je to v testing teprve týden, v Ubuntu to má akorát Lunar 23.04, který vyšel před třemi dny.
Kde vidite ze je to v ~ pro amd64 ?
Ja instaloval nedavno nove stroje a vsude mam ten 1.47-r1
https://packages.gentoo.org/packages/sys-fs/e2fsprogs
Btw R1 revize od 1.47 v Gentoo obsahuje patch ktery tyhle nekompatibilni zmeny docasne vypina z defaultu:
/var/db/repos/gentoo/sys-fs/e2fsprogs # diff e2fsprogs-1.47.0.ebuild e2fsprogs-1.47.0-r1.ebuild -u --- e2fsprogs-1.47.0.ebuild 2023-04-09 10:10:37.000000000 +0200 +++ e2fsprogs-1.47.0-r1.ebuild 2023-04-10 11:10:39.000000000 +0200 @@ -11,7 +11,7 @@ LICENSE="GPL-2 BSD" SLOT="0" -KEYWORDS="~alpha amd64 ~arm ~arm64 hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc x86 ~amd64-linux ~x86-linux" +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux" IUSE="cron fuse nls static-libs test +tools" RESTRICT="!test? ( test )" @@ -40,6 +40,9 @@ PATCHES=( "${FILESDIR}"/${PN}-1.42.13-fix-build-cflags.patch # bug #516854 + # We can drop this metadata patch after 6 months or so to let initramfses + # upgrade. See bug #904093 and bug #904048. + "${FILESDIR}"/${PN}-1.47.0-disable-metadata_csum_seed-and-orphan_file-by-default.patch # Upstream patches (can usually removed with next version bump) )
A ty dva bugy jsou problem ktery te potkal:
https://bugs.gentoo.org/904093
https://bugs.gentoo.org/904048
Jenze ony jsou, je to asi tak, jako kdyz nekdo pouziva trabanta na prevoz desitek tun nakladu nebo kamion aby si dovez krabicku sirek.
Pokud nekdo chce cow, snapy, ... tak za to pochopitelne zaplati vykonem, ono to totiz jinak udelat nejde. A pokud to nepotrebuje, nepotrebuje mit btrfs.
Jinak zpravicka je krasnou ukazkou toho, jak nekdo myslel az vymyslel ... zapinat bydefault jakoukoli ficuru driv nez 5+ let potom, co to umi vsechny komponenty ktere to umet maji muze jedine silenec.
výkon pro databáze je pořád dost žalostný (špatný random IO, nekomprimuje malé bloky), takže pro práci nic moc. Na doma mi zase chybí raid 5. Snapshoty jsou skvělé, ale ty neustále fragmentace a s tím spojené místo jsou proti zfs prostě opruz. Dělat obnovu rozbitého btrfs je už jen taková třešnička (teda spíše granát) na dortu, proti jinám FS to je šíleně nepohodlné a složité, vývoj jde tak dopředu, že najít správnou verzi nástroje pro tvůj raw disk je dost těžké.
Od FS čekám spolehlivost a přímočarost, btrfs je snaží být za mě až moc chytrý.
> Dělat obnovu rozbitého btrfs je už jen taková třešnička (teda spíše granát) na dortu, proti jinám FS to je šíleně nepohodlné a složité
Jak se opravuje rozbité ZFS? Vždyť pro něj ani nemají fsck. (ne, "scrub je fsck" není argument, scrub jen kontroluje, že to, co se přečetlo, je to, co se předtím zapsalo, ale nedělá žádnou kontrolu, že datové struktury FS dávají smysl)
Nemaj k tomu binarni utility, a la dumpe2fs ?
(prece vyvoj neni mozne delat na live driveru a je treba delat analyzy)
Ale souhlasim ze ty FS promixoval dohromady ruzne urovne a funkcionality (raid, snapshoty, soubory, cow/trim a garbage collector) a slozit to dohromady automaticky neni uplne mozne, tak jako u jednoduchych FS ci MD/LVM se znamym driverem/alokacni strategii.
Asi je treba akceptovat urcitou miru nespolehlivosti - odhadem bych rekl ze interni struktury SSD budou padat casteji nez samotne FS. Jednak mam nasysleno 100+TB vadnych SSD a druhak je zde faktor zabugovanosti uzavreneho reseni - kdy nevite bajtu a bitu, kdy vam proprietarni uloziste udela papa.
Takze asi univerzalni reseni datove spolehlivosti... je treba mit zalohy a zalohy zaloh :)
máš pravdu, je to hodně podobné, u zfs je ale mnohem stabilnější RAW podoba (mluvím hlavně o freebsd, ZoL tolik zatím neznám), nástrojů je celá řada, binární strukturu má jednoduší, nemotá vše dohromady. Btrfs naproti tomu dělá pořád tak rychlý vývoj, že 2 roky starý nástroj v distribučním repu neumí přečíst raw disk ze stejné distribuce, u zfs se velice rychle dozvím, že volume má nepodporované properties, u btrfs to padá na různé chybové hlášky, hromadu věcí pořád přepisují a refactorují, není snadné to analyzovat ze zdrojáků.
Část zkušeností mám i z chaos testu, kdy záměrně náhodně poškozujeme při testech disk a zkoušíme ty nástroje. K běžným obnovám se člověk zase tak často nedostanu a když už, není čas navíc.