Dotaz: Systemd-fsck mi při "kontrole" zničil 2 partitions najednou

Zdravím,

vypadá to, že začnu také nenávidět Lennarta Poetteringa, jak je teď v módě. Mám Debian Jessie a upgradoval jsem si HW svého PC na AMD Vishera, ovšem narazil jsem na divné chování desky. Prakticky žádné USB porty nefungovaly, síťovka se tvářila, že funguje, ale nelezly z ní pakety a SATA zařízení podivně mizela a nefungovala. Po delším googlení jsem se dozvěděl, že se u chipsetu AMD 970 musí v BIOSu zapnout (nebo vypnout u jiných výrobců) nesouvisející položka IOMMU, jejímž zapnutím se vše záhadně spraví. To už bylo bohužel pozdě.

Kvůlu snaze nalézt funkční kombinaci SATA kabelů jsem musel několikrát rebootovat (pořád mi nechtěla jet DVDRW) a ačkoliv všechny 3 moje disky byly ve fstab uvededny pomocí UUID, asi po čtvrtém restartu se systemd-fsck zbláznil a začal psát nějaké blbosti o poškozeném žurnálu a že ho teda maže. Evidentně si popletl 2 partitions mezi sebou - jedna ext4, druhá btrfs. Samozřejmě filesystém byl do té doby v naprostém v pořádku. Celé tohle jeho "léčení" trvalo jen několiv vteřin. Sice jsem se trochu vylekal, ale evidentně jsem se měl vylekat mnohem víc. Po následném rebootu už to našlo jen root partition. Zbylé dvě partitions na dvou discích s cca 300GB mých dat jsou na odpis - fotky dětí, videa apod. Sice většina zálohovaná, ale něco přeci jen chybí. Zálohoval jsem totiž také z jednoho disku na druhý a opravdu jsem nečekal, že mi Lennart odstřelí oba disky najednou. Btrfs se mi obnovit nepovedlo, ale tam nebyly tak důležitá data, tak jsem to brzo vzdal. Partition s ext4 se ještě snažím obnovit, ale zatím jsem z ní nedostal ani jeden soubor.

Je zajímavé, že Systemd dokázal během několika vteřin odstřelit partition tak, že v ní nezůstala jediná záloha superbloku. Rozumíte tomu někdo? Třeba by mi to pomohlo najít způsob jak se k datům dostat, kdybych pochopil jak to přesně udělal.

Odpovědi

[AraxoN]

Ako pri každej takejto havárii - ak je možné spraviť si binárnu kópiu disku, tak to urob ako prvé. Potom by som cez to pustil photorec.

[vodic]

Díky. dd kopii ext4 jsem si udělal hned. Na 400GB z partition s btrfs bohužel nebylo místo. Ale stejně všechny mě známé i neznámé nástroje na opravu bttfs ani vůbec nepoznaly, že to kdysi bylo btrfs, takže asi moc šancí nebylo.

Zatím všechny pokusy s obnovou superblocku, zápisem nového prázdného superblocku apod. na ext4 ztroskotaly. Ani testdisk se vůbec nechytal. V binární kopii objevil asi 8 nesmyslných partition, ale nic víc. Photorec mám v plánu zkusit večer. Ještě jsem ho nikdy nemusel použít, takže uvidím. V každém případě víc low level už asi moc jít nemůžu. Pak už snad jedině "cat zaloha.img" a vytisknout si to na firemní tiskárně :)

[AraxoN]

Na opravu FS by som rovno zabudol. Treba zachrániť súbory a prehrať ich na čistý FS. Pôvodný FS bude rozbitý nad možnosti opravy.

[vodic]

Tak prohledání zabralo. Akorát mám do Vánoc co třídit :) Většina fotek obnovena v pořádku. Video to nepřežilo snad žádné, ale ty mám zálohovaná jinde.

[Pavel 'TIGER' Růžička]

Evidentně jsem neodeslal příspěvek, takže znova ...

Zde se Lennarta musím zastat, protože tato chyba by se stala s velkou pravděpodobností i bez systemd. Ještě nikdy jsem se nesetkal s tím, že by fsck smazalo partitions. Pokouší se ji akorát opravit, pokud se mu nelíbí. To v některých případech může zdravou partitions zcela odrovnat. Stačí když blbne hardware, nebo se změní parametry chipsetu.

V žádném případě nedoporučuji opravovat onu partitions na stejném stroji, je velká pravděpodovnost, že se nakopne ještě více a už se z ní nedostane vůbec nic. Pokud to není totálně v pr...., tak nejúspěšnější nástroje pro ext jsou pořád testdisk a photorec. Jinými nástroji úspěšnost klesá.

Btrfs nepoužívám, takže nevím, jestli existuje nějaký schopný nástroj na jeho opravu.

[Heron]

Pokouší se ji akorát opravit, pokud se mu nelíbí.

A to ještě tak, že jediná zápisová operace je přehrání žurnálu (což by se stalo při mountu stejně) a v případě nalezení jakéhokoliv dalšího poškození vyžadujícího zápis se standardně zeptá, zda změnu provést (lze obejít parametrem -y, což ale snad žádná distribuce nemá ve svých init skriptech při bootu).

Takže souhlasím, docela pravděpodobné je, že se ta data poškodila už při onom hw šílenství.

[vodic]

Po nabootování systém nikdy žádné problémy nevykazoval. Celá home složka byla evidentně v pořádku, všechno fungovalo. Teda mimo sítě, mizerné detekce USB a chybející mechaniky.

[Josef Kufner]

Příloha:

• exif-folderize (308 bytů)

Tu máš hračku.

[vodic]

Jeee, diky.

[Pavel Stárek]

Ano, a co jsem koukal do zdrojáků systemd-fsck který je spuštěn pomocí jednotky systemd-fsck.service, tak ten skutečně jen spustí /sbin/fsck s patřičnými parametry. Podle mne se ty filesystémy rozbily při té počáteční nestabilitě a všelijakých restartech.

[vodic]

No on byl problém s detekcí SATA hlavně v biosu, pak už to, co se nadetekovalo, normálně fungovalo. Takže když jsem načetl několikrát systém, tak to bez problémů najelo. Tam jsem otestoval DVDRW, síťovku a USB a normálně zase restartoval do biosu na další pokus, jestli nějaký další parametr nezabere. Vše ve vší počestnosti, žádné resety nebo neodpojení filesystému se nekonalo. Nemluvě o tom, že na tu partition s btrfs se během těch restarů vůbec nesahalo. Jen se po startu automaticky připojila, ale nic se tam nezapisovalo.

Skoro bych dal ruku do ohně za to, že když to napsalo, že to maže žurnál ext4, tak to psalo u partition, která byla ve skutečnosti btrfs. Ale bylo to fakt rychlé, takže na 100% to nevím.

Poslední reboot před tou pohromou jsem vlastně také nainstaloval modul r8168 od VIA, který měl síťovku podle diskuzí rozchodit. Instalační skript přegeneroval initramfs, ale nenapadá mě, jak by to mohlo souviset.

Je mi jasné, že systemd-fsck není přepsaný fsck na zelené louce, ale že jen volá už hotové nástroje. Spíš jde o to jak moc ty patřičné parametry jsou patřičné. Nehledě na to, že evidentně mazal co neměl a hlavně se mě neptal.

[Pavel 'TIGER' Růžička]

Můj osobní názor je, že to nakopla ta změna v biosu, prostě se s tím systém nevyrovnal. Je to jako kdybys měl systém nainstalován v SATA compatible módu a pak jej přehodil do AHCI, nenastartuješ vůbec. Některé změny systém prostě neunese. Na druhou stranu, co říká S.M.A.R.T. disku?

[vodic]

S.M.A.R.T. jsou bez známek problémů. Disky jsou v pořádku.

[R]

To plati akurat tak pre Windows. Debian s distribucnym jadrom s tym nema ziadny problem.

Dalej pri vadnom disku sa neznici filesystem, ale pri pokuse o citanie bude disk vracat chyby (a jadro ich vypisovat na konzolu).

[Pavel Stárek]

Tak přehození ze SATA compatible na AHCI linuxu nevadí (na rozdíl od majoritního OS ). Dokonce Fedoří kernel přepne řadič do AHCI módu, i když mám v BIOSu nastavený kompatibilní režim.

[Pavel 'TIGER' Růžička]

No já jsem měl problém na T400 s openSUSE 13.1. tam to problém byl.

[JMP]

pokud v opensuse 13.1 použijete výchozí připojování disků ve fstabu, tak je toto docela dobře možné

pokud přenastavíte připojování na UUID, tak se to už patrně neprojeví

(ale jsou to jen dohady, protože neznám vaši skutečnou situaci...)

[michich]

systemd-fsck je malý wrapper nad fsck. Parsuje relevantní volby pro fsck na kernel command lajně (fsck.*, forcefsck, fastboot) a volby dané existencí souborů v kořenovém adresáři (/fastboot, /forcefsck). Pokud nic z toho nastaveno není, spustí: /sbin/fsck -a -T -M -C<fd> <device>

(Má-li snad někdo pochybosti o "-a", upozorňuju, že tuhle volbu používaly i staré initskripty Debianu, Fedory, RHELu, … a že to není totéž co "-y".)

Pak jenom čte výstup fsck a vypisuje postup v procentech na konzoli. Po jeho dokončení zkontroluje návratový kód a buď neudělá nic, nebo provede reboot či přechod do emergency.

V žádném případě nic nemaže ani o žádném mazání nerozhoduje.

[vodic]

Ok, omlouvám se Lennartovi. Je v tom naprosto nevinně. Ale pořád nerozumím tomu, jak si fsck mohl myslet, že maže žurnál a přitom mazal úplně něco jiného.

[lertimir]

Protože celý systém měl chybné informace z HW. Jak psal Tiger, pokud máš změnu mezi legacy SATA a AHCI tak ani nenabootuješ.

Mě se před 14 dny stalo, že jsem sáhnul kamarádovi do BIOSu, protože při startu se mu objevovala hláška, že jsou špatně indikované drivy a at zmáčkne F1 na pokračování nebo jde do BIOSu. dlouho mačkal F1, tak jsem se proaktivně nabídl, že mu to opravím. Tak jsem v biosu loadnul "Filesave configuration" a systém ani nenajel, jen blikající kurzor. (Má tam XP.) Live distro flash najelo normálně. Druhý pokus byl v biosu loadnout "Optimized configuration" to XP začaly najíždět a v polovině nájezdu udělaly HW restart. Podobně dopadly, když jsem zvolil nabootovat do rezimu jen příkazové řádky, protože při přístím bootu indikovaly neúplný start a nahodily známe menu. Linuxové live distro na druhou stranu disk a oddíly vidělo a v pohodě s něj četlo. Win z instalačního disku v recovery consoli ani neidentifikovaly typ oddílu. Strávil jsem několik dalších hodin pokusy o opravu a finálně jsem systém opravil bootem do recovery konsole a fixmbr, fixboot a chkdsk to zprovoznily.

I když je to windowsí případ, vidím obdobu v tom, že zásah do BIOSu změnil komunikaci (nebo jen někde něco) tak, že stávající instalace se s tím diskem nedomluvila. Live distro mělo vše potřebné na správnou domluvu s diskem a teprve mnohem později se mi podařilo opravit existující instalaci tak, aby se s diskem domluvila.

[vodic]

To celé beru, ale z initramfs se načtou moduly pro HW řadičů disku (Debian v defaultu má v initrd moduly prakticky pro všechno, takže i po prohození SATA a AHCI to najede) a díky tomu se objeví jednotlivé partitions. Pak se na ně pustí fsck. I kdyby se jednou najelo v IDE modu a pak v SATA modu, tak se pro HW načtou příslušné moduly a jede se normálně dál. Není důvod, aby to jednou najelo a podruhé to zmasakrovalo filesystémy.

Problém nastane jedině v případě, že je initrd vytvořen vyloženě na míru konkrétnímu HW s minimem modulů. To samozřejmě některé distribuce dělají, protože se tím urychlí načtení initrd, protože je mnohem menší. Pak to opravdu po prohození SATA vs IDE nenajede, ale jen proto, že v initrd není k dispozici příslušný modul pro HW a tak jádro ten HW ve výsledku nevidí. Pak se musí přegenerovat initrd, aby se do něj přidaly nově potřebné moduly a zbytečné vyházely. Ale rozhodně to není tak, že by si to myslelo "Aha, minule to bylo AHCI, tak teď to je zaručeně taky AHCI, tak tady něco přepíšu, protože tak bych to v případě AHCI měl udělat."

Takže nesouhlasím s tím, že systém měl chybné informace z HW. Při každém startu de dělá detekce HW znova.

[R]

Presne tak.

Aj v Debiane sa da urobit initramfs "na mieru" - staci nastavit v /etc/initramfs-tools/initramfs.conf MODULES=dep. Default je MODULES=most, tzn. initramfs nezavisly na konkretnom HW.

[lertimir]

Obávám se že si protiřečíte. Tvrzení

Takže nesouhlasím s tím, že systém měl chybné informace z HW. Při každém startu de dělá detekce HW znova.

a tvrzení z otázky

Po delším googlení jsem se dozvěděl, že se u chipsetu AMD 970 musí v BIOSu zapnout (nebo vypnout u jiných výrobců) nesouvisející položka IOMMU, jejímž zapnutím se vše záhadně spraví.

Zapnutí, nebo vypnutí IOMMU je způsob informací z HW. Změní adresaci mezi zařízením a pamětí. A i když je převážně pro virtualizaci přístupu na grafické karty tak disk je také DMA zařízení a IOMMU ten překlad logických adres na fyzické adresy ovlivňuje nebo může ovlivňovat. Jen spekuluji, ale dokážu si představit, že systém v nějaké situaci píše data do jiných částí paměti, než ze kterým se data přes DMA zapíšou do disku. Protože má chybnou informaci nebo chybné nastavení.

[ByCzech]

Osobně si myslím, tak jak to tady už také zaznělo, že chyba je někde na straně HW, systemd či fsck jsou v tom nevinně. Už ty úvodní symptomy, které popisujete - USB porty nefungovaly, síťovka se "tvářila", že funguje, ale nezlezly z ní pakety, SATA zařízení podivně mizela a nefungovala - by mě osobně vedly hledat HW problémy.

Mám dotaz(y), nezůstaly vám náhodou při upgrade původní paměti? Nebo část původních pamětí? Nemáte chybně seskládaný HW (správně nasazený chladič CPU ap.)? Máte poslední verzi BIOSu?