Server se restartuje v nouzovém režimu, oddíl se odmítá připojit nebo jádro hlásí chyby ext4. Existuje pokušení spustit systém okamžitě. fsck na prvním nalezeném zařízení. Tomu je třeba se přesně vyhnout: oprava na nesprávném svazku nebo na souborovém systému, který je stále připojen, může poškození zhoršit.
fsck je spouštěč, který volá nástroj vhodný pro souborový systém. Před jakoukoli opravou musíte identifikovat oddíl, ověřit jeho typ, potvrdit, že se již nepoužívá, a uchovat použitelnou zálohu. Vždy začínám kontrolou bez zápisu. Oprava následuje až poté.
Identifikujte oddíl a jeho souborový systém
Nespoléhejte se pouze na jméno jako /dev/sdb1Pořadí disků se může změnit po restartu nebo přidání zařízení USB. Zobrazte typ souborového systému, UUID, model, sériové číslo a body připojení:
lsblk -o NÁZEV,VELIKOST,TYPFS,UUID,PŘIPOJOVACÍBODY,MODEL,SÉRIOVÉČÍSLO,TYP
Průvodce po lsblk v Linuxu podrobně popisuje toto ověření. Pokud pracujete s LVM, zaměřte se například na logický svazek, který obsahuje souborový systém /dev/mapper/vg_data-lv_archive, nikoli fyzický svazek LVM umístěný níže. Článek věnovaný LVM a jeho různé vrstvy nám umožňuje je rozlišovat.
Dále zkontrolujte, jak je zdroj použit:
findmnt --source /dev/nvme0n1p2
findmnt --target /mnt/dataVýstup signalizuje, že se hlasitost zvýšila. Pokud se žádný výstup neobjeví, nebuďte si jisti: znovu si přečtěte pokyny. lsblk A findmntPak zkontrolujte UUID. Výukový program na UUID souborového systému zabraňuje záměně dvou partitur s podobnými názvy.
Nikdy neopravujte připojený souborový systém
Jádro může upravovat metadata během fsck Zkuste je opravit. Dva pohledy na souborový systém se pak stanou nekonzistentními. Připojení pouze pro čtení není dostatečnou zárukou pro improvizovanou opravu: nástroj musí být použit za podmínek uvedených v jeho dokumentaci.
Pro daný objem dat zastavte služby, které jej používají, ukončete terminály umístěné v jeho adresářovém stromu a poté jej odpojte:
sudo fuser -vm /mnt/data
sudo umount /mnt/data
findmnt --source /dev/nvme0n1p2 umount Odpovídá, že cíl je zaneprázdněn, nenuťte ho. Identifikujte proces pomocí pojistka Nebo lsofpoté řádně vypněte danou službu.
Pro kořenový oddíl použijte živé médium nebo záchranné prostředí, kde tento oddíl není připojen. Pouhé přepnutí do režimu pro jednoho uživatele nebo nouzového režimu neprokazuje, že je kořenový oddíl odpojený. Na vzdáleném serveru se před restartem ujistěte, že je k dispozici konzole KVM, IPMI nebo nouzový přístup poskytovatele hostingu.
Začněte s nepsaným šekem
Následující příkaz ukazuje, který kontrolor fsck by se spustil bez provedení kontroly:
sudo fsck -N /dev/nvme0n1p2Na disassemblovaném systému ext2, ext3 nebo ext4 spusťte vynucené skenování a na všechny navrhované úpravy odpovězte „ne“:
sudo e2fsck -f -n /dev/nvme0n1p2
rc=$?
echo "Kód e2fsck: $rc"Možnost -n zachovává kontrolu pouze pro čtení. Možnost -F Kompletní kontrola je nutná, i když se souborový systém jeví jako čistý. Tato kontrola může být u velkého svazku zdlouhavá. Pokud disk hlásí chyby vstupu/výstupu, časové limity nebo odpojení, nejprve zálohujte to, co je stále čitelné, a poté zkontrolujte hardware. fsck Opravuje logickou strukturu, nikoli disk, který fyzicky selže.
Zprávy jádra mohou tento scénář potvrdit:
sudo dmesg -T | grep -Ei 'Chyba I/O|časový limit|reset|EXT4-fs|XFS|BTRFS'
sudo journalctl -k -b -p varování..upozorněníPrůvodce po chyby dmesg a jádra
Oprava svazku ext4 bez odpovědi „ano“ všude
Pokud kontrola ohlásí nesrovnalosti, ověřte zálohu, znovu potvrďte zařízení a ponechte svazek odpojený. Poté spusťte interaktivní opravu:
sudo e2fsck -f /dev/nvme0n1p2Před odesláním si každou otázku přečtěte. Vyhněte se -y Ve výchozím nastavení tato možnost akceptuje všechny opravy, a to i v případě, že situace vyžaduje zálohování svazku nebo kontrolu hardwaru před pokračováním. Na velkém oddílu je slepé provádění automatické opravy špatným kompromisem mezi rychlostí a kontrolou.
Po dokončení příkazu ihned zaznamenejte jeho výstupní kód:
rc=$?
echo "Kód e2fsck: $rc"Přečtěte si ukončovací kód fsck
Nenulový kód neznamená vždy, že oprava selhala. Hlavní hodnoty jsou následující:
nulanebyly zjištěny žádné chyby;jedenopraveny chyby;: chyby opraveny, nutný restart;čtyřineopravené chyby;osm: chyba v činnosti testeru;šestnáct: chyba v použití nebo syntaktická chyba;třicet dva: ovládání zrušeno;sto dvacet osm: chyba související se sdílenou knihovnou.
Tyto hodnoty fungují jako bity a lze je sčítat. Kód vyžaduje, aby se objem čtení/zápisu nezvyšoval, jako by bylo vše opraveno. Kód osm požadavek na kontrolu příkazu, typu souborového systému, nainstalovaných nástrojů a zobrazených zpráv.
XFS a Btrfs používají své vlastní nástroje
fsck nepoužívá stejnou metodu pro všechny souborové systémy. V případě XFS začněte s neupraveným skenováním odpojeného svazku:
sudo xfs_repair -n /dev/nvme0n1p2Oprava se poté provede pomocí , vždy bez držáku. Nepoužívejte -L Jako první pokus: resetování protokolu může vést ke ztrátě nedávných metadat.
Pro Btrfs je obezřetná kontrola explicitně určena pouze pro čtení:
sudo btrfs check --readonly /dev/nvme0n1p2Nepřidávejte --opravit FSTYPE s lsblk -f před výběrem nástroje.
Před opětovným sestavením zkontrolujte hlasitost
Po opravě ext4 spusťte kontrolu bez zápisu. Pokud je výsledek v pořádku, znovu připojte svazek a poté zkontrolujte typ, místo a nové zprávy jádra:
sudo mount /mnt/data
findmnt /mnt/data
df -hT /mnt/data
U kořenového oddílu ovládaného při spuštění zkontrolujte také stopy předchozího spuštění:
journalctl -b -1 | grep -Ei 'fsck|systém souborů|Chyba I/O|EXT4-fs|XFS|BTRFS'
systemctl --selhaloTam Manuálová stránka fsck popisuje spouštěč a jeho ukončovací kódy. Pro ext4 viz e2fsckPostupy specifické pro XFS a do Btrfs musí zůstat prioritou před generickým příkazem nalezeným náhodně.