Dotaz: Start systému jen do emergency mode

[TechnikTom]

Přílohy:

• start.jpg (237925 bytů)
• fsck.jpg (226807 bytů)
• lsblk.jpg (169765 bytů)
• ls.jpg (234248 bytů)

Dobrý den.

Zkusíte mne prosím nasměrovat kudy se pokusit řešit problém.

Lubuntu 18.04 na šifrovaném disku.

Při startu ohlásilo, že se nepodařilo odstranit chyby soub. systému a je třeba spustit fsck ručně.

Už jsem jednou dělal, tenkrát pomohlo , nyní ne - ohlásilo to opravu nějakých bloků, ale od té doby systém najíždí jen do emergency - asi nějaký problém s právy zápisu nebo přístupu na disk.

Na stejném stroji na jiném disku mám Lubuntu 20.04, na ten šifrovaný disk se dostanu, data mám zálohovaná, takže přeinstalace je možná, ale pokud by se podařila zachránit původní instalace, byl bych rád.

Chtěl jsem sem dát dmesg, ale ve var/log vůbec není - asi kvůli nemožnosti zápisu.

Napadlo mne, že systém je připojen jen ro mode, ale dle výpisu lsblk není.

Na notebooku mám ten samý systém a práva k adresářům jsou nastavená stejně.

Ale rozdíl u obou je, že v ntbk nabízí GRUB v recovery mode kernel řady 5 ale na problémovém PC řadu 4, i když oba byly aktualizované stejně.

Jinak klasický recovery mode vůbec nenajede.

V fstab je pro daný oddíl nastaveno errors=continue.

Pokud budu přeinstalovávat, tak stejně opět 18.04, protože 20.04 je na daném stroji mnohem méně použitelné.

Odpovědi

[Max]

V emergency se připojují svazky v read only režimu a s omezenými proměnnými prostředí (proto ti většina příkazů by default nefunguje jako třeba ten journalctl.) lsblk ti neukáže, co je připojeno a jak, ten ti jen vypíše seznam blokových zařízení. Aby jsi viděl, co je připojeno a jak, k tomu slouží příkaz "mount".
Takže sem hoď výpis toho příkazu. Dále je otázkou, co to způsobilo. Nedělal jsi aktualizaci, která pak na něčem pohořela (nedostatek místa apod.)? V tom příkazu "ls" je vidět nějaká změna 31.3., ale vypovídající bude asi výpis adresáře "/boot"
Pak je otázkou, kde ten systém skutečně máš a jak to máš nastaveno. Můžeš sem hodit i výpis /etc/fstab?
Zdar Max

[TechnikTom]

Příloha:

• IMG_20220510_113012.jpg (319744 bytů)

Díka za reakci.

To došlé místo na disku už jsem v minulosti zažil, tak to jsem ověřil jako první - je volných 30GB

Systém jsem jeden den normálně ukončil a druhý den ráno už nenajel. Jestli jsem ten poslední den pouštěl nějaké aktualizace si už nepamatuji, když se objeví výzva, tak je pustím, nikdy nebyl problém. Chyba nastala tuším 19.4.

fstab:

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

/dev/mapper/sdb2_crypt / ext4 errors=continue,nofail 0 1

# /boot was on /dev/sdb1 during installation

UUID=55011f7f-0fa6-4ce9-9a64-9d4e97800139 /boot ext4 defaults,nofail 0 2

/swapfile none swap sw,nofail 0 0

Na sda1 je testovací Lubuntu 20.04, ale systém startuje z sdb ( 20.04 i teď normálně pustím z menu GRUBu běžícího z sdb )

/boot je na samostatném oddílu sdb1,

na sdb2 je šifrovaný oddíl s Lubuntu 18.04, které právě nenajíždí (na šifrovaném sdb2 je adresář boot prázdný)

na sdb3 je šifrovaný VeraCrypt oddíl, ale s tím nemá systém nic společného.

/boot:

-rw-r--r-- 1 root root 217563 bře 18 16:36 config-4.15.0-173-generic

-rw-r--r-- 1 root root 217563 bře 24 17:53 config-4.15.0-175-generic

drwxr-xr-x 5 root root 4096 bře 31 08:37 grub

-rw-r--r-- 1 root root 61339109 bře 23 07:30 initrd.img-4.15.0-173-generic

-rw-r--r-- 1 root root 61337362 bře 30 10:08 initrd.img-4.15.0-175-generic

drwx------ 2 root root 16384 čen 1 2018 lost+found

-rw-r--r-- 1 root root 182704 led 28 2016 memtest86+.bin

-rw-r--r-- 1 root root 184380 led 28 2016 memtest86+.elf

-rw-r--r-- 1 root root 184840 led 28 2016 memtest86+_multiboot.bin

-rw------- 1 root root 4087504 bře 18 16:36 System.map-4.15.0-173-generic

-rw------- 1 root root 4087504 bře 24 17:53 System.map-4.15.0-175-generic

-rw------- 1 root root 8470176 bře 18 16:40 vmlinuz-4.15.0-173-generic

-rw------- 1 root root 8470176 bře 24 18:08 vmlinuz-4.15.0-175-generic

K příkazu mount se již nedostanu, protože nově systém najede jen do servisní konzole tty1 a nereaguje na žádného z uživatelů - po zadání uživatele nevypíše výzvu pro heslo a po chvíli provede restart "getty". Stejné je to i v tty2 atd.

Přitom /etc/passwd na disku je, mohu ho otevřít a uživatele tam vidím. ( po spuštění Lubuntu 20.04 a připojení šifrovaného disku )

Bude to něco s připojením oddílů, protože při startu píše, že se mu nepodařilo připojit mimo spousty ostatního i /boot

Proto jsem to chtěl zkusit, třeba to je nějaká maličkost, kterou nedokážu opravit.

GRUB najede a umožní vybrat systém, který chci spustit, po zadání hesla se připojí šifrovaný oddíl a až pak se objeví ty hlášky s připojováním a spouštěním ostatních věcí.

Ale asi nebudu plýtvat časem svým a ostatních a přeinstaluji to.

[Max]

/boot je na šifrovaném oddíle prázdný, protože je na prvním oddíle /dev/sdb1, který se mountuje do "/boot" adresáře.
Nejdříve se tedy připojí "/dev/mapper/sdb2_crypt" na "/" a pak "/dev/sdb1" do "/boot".

Systém ti nebootuje ani s jiným kernelem? Koukám, že by jsi měl mít na výběr dva "4.15.0-175" a "4.15.0-173".

Jinak by to chtělo ověřit z livecd , zda souhlasí záznamy ve fstab, zda souhlasí záznamy ve vygenerovaném grub.cfg, zda jdou připojit všechny oddíly a pokud ano, chroot a zkusit přegenrerovat initramfs.
Zdar Max

[TechnikTom]

Příloha:

• grub.cfg (18890 bytů)

Zkoušel jsem obě varianty přístupné z GRUB recovery a obě stejný negativní výsledek.

Všechny oddíly připojím z fukčního Lubuntu 20.04 a UUID pro /boot i připojeného šifrovaného oddílu s nefunkčním 18.04 jsou stejná s tím, co je v grub.cfg.

grub.cfg má poslední změnu 31.3. Systém ale ještě potom fungoval do 19.4. Ale našel jsem tam soubor s datem právě 19.4. s názvem "grubenv", který obsahuje patrně nějakou chybovou hlášku:

# GRUB Environment Block

recordfail=1

###########################################################################################################################

###########################################################################################################################

###########################################################################################################################

###########################################################################################################################

###########################################################################################################################

Ale teď jsem vyčetl, že by měl sloužit jen k uložení nějakých nastavení -třeba defaultní položky pro výběr menu atp. A to mi přitom funguje, protože se automaticky použije asi čvrtá položka GRUB menu tak jak jsem měl nastaveno doposud.

Ještě zkusím ten chroot, ale musím nastudovat.

Asi to bude nějaký podobný postup jako tady ne? https://wiki.debian.org/RescueLive

[ewew]

Podľa mňa ti systém prehadzuje poradie diskov. Riešenie je dať oddielom UUID alebo LABEL.

LABEL pridelíš tune2fs -L názov /dev/sdXY alebo UUID tune2fs -U UUID /dev/sdXY. Ak používaš tak odlišne verzie jadier, tak počítaj, že tam bude iné správanie.

[TechnikTom]

Tak /boot už se připojuje podle UUID, tam už nic nevymyslím a ten šifrovaný podle UUID do fstab asi dát nemůžu. Ještě zkusím ten sda s funkčním Lubuntu 20.04 fyzicky odpojit, co to udělá, plus pokusy s chroot jak radí Max.

[Max]

Těžko, pokud koukáš dobře, tak boot má UUID a šifrovaný oddíl se připojuje přes mapper, takže jedinečnost též zajištěna.
Zdar Max

[ewew]

Ale UUID nie je definované pre /

[Max]

Protože se volá přes unikátní název mapperu "sdb2_crypt".
Zdar Max

[ewew]

Přílohy:

• mountfailure_11052022.jpg (242124 bytů)
• mountfailure_11052022_1.jpg (93746 bytů)
• mountfailure_11052022_2.jpg (293774 bytů)
• mountfailure_11052022_3.jpg (317892 bytů)

Na jednom VM čo mám, mi pri dvoch diskoch zlyhalo pripojenie /boot Systém prešiel do núdzového režimu. Použil som nasledovné príkazy

• lsblk - zobrazí zoznam blokových zariadení
• systemctl status -a - zobrazí stav všetkých služieb a celý žurnal

Podľa výstup z lsblk je zjavne, že došlo k zámene sda a sdb. Systemctl odôvodnil zlyhanie pripojenia /boot z dôvodu, že dané zariadenie už je pripojené na inom mieste. Z tohto vyplýva, že v prípade viacerých diskov je nutné použitie UUID alebo LABEL.

Z tohto dôvodu si myslím, že je nutné definovať UUID alebo LABEL v definícii šifrovaného oddielu, podobne ako je to u crypttab.

Prikladám fotky okna vm.

[Jendа]

Na jednom VM čo mám, mi pri dvoch diskoch zlyhalo pripojenie /boot Systém prešiel do núdzového režimu.

Příště doporučuji dávat ke všem záznamům ve fstabu volbu nofail. Není nic lepšího než když systém nenajede kvůli selhání připojení nějaké zbytné blbosti typu /boot nebo /var/www, ideálně když se při tom ani nespustí sshd a při ladění na konzoli tam je nepřerušitelné čekání.

Z tohto dôvodu si myslím, že je nutné definovať UUID alebo LABEL v definícii šifrovaného oddielu, podobne ako je to u crypttab.

Není, protože crypttab ti ten mapping udělá právě pod tím zadaným jménem. Používám to tak všude.

[ewew]

Teoretizujem nad myšlienkov, že toto robí hw. Kedže hw nijak nerieši poradie detekcie zariadení. Toto môže byť častí jav vo viacdiskovom systéme.

[ET]

* journalctl poustej pod rootem (prip. pres sudo pod tomasem)

* posli /etc/fstab, jak psal Max

[TechnikTom]

Díky.

Výsledek byl stejný pod root i sudo uživatelem.

Vždy to napsalo, že systemd není nainstalovaný ( co by za to spousta lidí dalo, jak jsem tady občas četl :o)

Při pokusu o instalaci ale napíše, že je již nainstalovaný.

Je to na jedné z těch přiložených fotek.

fstab jsem poslal v předchozím příspěvku.

[Peter Golis]

Skontroloval by som či binárka existuje, či je stále typu ELF, či má dostupné všetky knižnice a či funguje s plnou cestou:

/bin/ls -l /bin/journalctl
/usr/bin/file /bin/journalctl
/usr/bin/ldd /bin/journalctl
/bin/journalctl

[Jendа]

A pak může totéž zkusit z toho druhého systému (file /mnt/tamtendisk/bin/journalctl) a pak v chrootu.

Pozn. nevím jestli není na Ubuntu už všechno v /usr/bin a /usr/sbin, ale na tak starém asi ještě ne.

[Peter Golis]

Vtedy ešte nie, a asi nemá moc porozdelovaný disk že by mu symlinky ukazovali na nepripojený disk.

Skôr ma zaujímalo či odchádza (flash) disk, alebo chytil kryptovací ramsonware.

[Jendа]

Chtěl jsem sem dát dmesg, ale ve var/log vůbec není - asi kvůli nemožnosti zápisu.

dmesg je příkaz co vypíše aktuální log jádra. Soubor kam se ukládá obsah dmesg se jmenuje messages. Ale jestli je to readonly tak tam asi nic zapsáno nebude.

Udělal bych fsck z toho druhého systému, přecijen je lepší když to je odmountované a ne pouštět to s -f v kdovíjakém rw stavu.

Pak bych se tam chrootnul a udělal debsums -c, tím se zjistí, jestli nejsou poškozeny nějaké systémové soubory.

Pak bych zkontroloval obsah /etc/fstab a z pověrčivosti udělal update-initramfs -u. A update-grub a podíval se pak při bootu co to hledá jako /.

Ten fsck co napíše že selhal řekne jaký device kontroloval a s jakými chybami? Třeba selhala kontrola nějakého /boot, /home nebo tak, což není pro samotné naběhnutí systému důležité.

[TechnikTom]

Díky všem za snahu.

Disk je mechanický, ale také může mít chyby.

Zajímavé bylo, že ten journalctl to nenašlo, ale vzápětí šel prostým příkazem "mc" spustit MidnightCommander, byť s hláškou, že nemůže cosi kamsi zapsat.

fsck jsem pouštěl z obou systémů přímo na ten šifrovaný disk a krom toho prvního spuštění, kdy vypsalo opravu nějakých věcí, končí normálně.

Při tom prvním spuštění myslím, když psal o nějakých uvolňovaných "inode", zahlédl jsem přitom něco o chmode, chown atp. začal jsem tušit, že to nebude dobře.

Podle mne tam prostě nějaké soubory systému asi chybí.

Teď už se ani nemohu přihlásit do servisní konzole, kde start končí a asi bude jednodušší to přeinstalovat.

Sice používám Linux od dob Mandrake a Mandrivy, ale jen jako běžný uživatel, který si některé věci sice dokáže najít, ale nějak hluboké znalosti systému jsem dosud nepotřeboval a nevyužiji.

Zítra ještě zkusím s LiveCD 18.04 ty typy s chroot od vás a uvidím.

Díky všem za věnovaný čas.

[Peter Golis]

Pred reinštaláciou by som skontroloval SMART hodnoty disku, RAMku (memtest) a aj napájanie (Buď kolísalo 235V a zdroj to nevykompenzoval, alebo zdroj už nedodá toľko ako keď bol nový).

[ET]

Cau,

pokud ti nasel fsck chyby, pravdepodobne doslo k nekorektnimu vypnuti - zkontroluj pres fsck radeji i ten /boot

LiveCD nepotrebujes, muzes nabootovat z toho prvniho disku s 20.04 a opravit to z nej - sel bych tim postupem, co psal Jenda vyse, tj.: 1) chroot (namontovat / i /boot a bindnout ty ostatni adresare) 2) debsums -c 3) check /etc/fstab 4) update-initramfs -u 5) update-grub

[TechnikTom]

Takže díky všem, co mi chtěli pomoct, ale ani s cestou přes chroot jsem nebyl úspěšný.

Stále to nemůže najít soubory systémových příkazů atp.

Nakonec jsem zjistil, že to co potřebuji a spouštěl jsem v 18.04 ve Virtualboxu nyní běží přímo ve Wine s menšími systémovými nároky, tak jsem přeinstaloval na 20.04.

Sice ne dle mých představ, protože stále potřebuji jednu instalaci Lubuntu na samostatném disku v dualbootu volně přístupnou bez hesla a druhou jsem měl na šifrovaném disku, který se připojil až po výběru systému v Grubu. Ten nový instalátor to buď zašifroval celé včetně boot, takže nejdřív heslo a pak až výběr systému, nebo normální start a šifrování jen home.

Při pokusu o instalaci druhého systému na šifrovaný disk jsem skončil ve dvou různých možnostech, vždy s chybou.

Buď na tom, že instalátor vytvořil šifrovaný disk ( dokonce mne upozornil, že mám šifrovaný disk , ale ne boot ), ale s neznámým heslem ( Gparted následně ukázal připojený šifrovaný disk, dokázal ho odpojit, ale už nevzal heslo pro připojení ) Ve druhé možnosti jsem pomocí správce disků vytvořil předem šifrovaný oddíl, instalátor ho vzal, začala instalace, ale po chvíli se ukončila.

Na šifrovaném disku bylo fajn, že jsem se na něj dokázal jednoduše připojit z jiného systému, což se hodilo při přesunu nebo záchraně dat atp.

Do adresáře /home se mi zatím nějak jednoduše a intuitivně dostat nepodařilo, ale neměl jsem čas se tomu nějak víc věnovat.

[k3dAR]

btw: pokud bys instaloval v rezimu UEFI (a ne Legacy/BIOS), tak na "desifrovaci" heslo by se snad mel ptat az konretni v grubu vybranej system, pokud to nahodo tak neni, tak i tak v UEFI instalace nejdriv sifrovanej disk s hlavnim os, ten disk pak radeji vyndat, udelat nesifrovanou instalaci na ten druhej disk, vratit prvni disk, v "BIOS"/Setupu nastavit primarni ten prvni disk a start z druheho disku nesifrovany os resit pres F12 (ci co ma tvuj stroj) tlacitkem pro zozbrazeni docasneho BootMenu desky...