Üdv!
Adott egy épp ugrade-re váró Linux mint (4.10.0-38, 2017-es), ami valamilyen oknál fogva emergency módba bootol be.
A boot során az egyik service-nél 1 perc 30 másodpercet várakozik, és bár látszólag tovább megy (timeout- gondolom), a hiba valószínűsíthetően innen jön. A másfél perces service-nél ezek az üzenetek váltakoznak:
A start job is running for dev-sda3.device
A start job is running for dev-disk-by\x2duuid...
A start job is running for dev-disk-by\x2duuid...
, majd a másfél perc után van még jó néhány sikeres service, majd jön az emergency mód.
Itt root-ként belépve a root filesystem sikeresen csatolva van rw-ként, az adatok olvashatóak.
A journalctl -xb kimenete elég hosszú, ide töltöttem fel: https://logpaste.com/0axztl1Z .
Tudna valaki ötletet adni, hogy mi lehet a probléma? Hogyan javítható?
(Emergency módnál init 2 ugyanarra a hibára fut).
Hozzászólások
Ez szerintem probléma lehet.
Lehet, bár nekem nem túl sokat mond, azt meg főleg nem, hogy mit tudnék ezzel kezdeni.
Az efi partíció normál esetben nem feltétlen kell hogy mountolva legyen, mert az csak a boot folyamat elején kell.
Viszont, ha a /etc/fstab-ban benne van, és nem tudja mountolni, akkor a local-fs.target systemd folyamat hibára fut. A local-fs.target a multi user előfeltétele (dependency), ezért vált át emergency módba.
Próbaképp kommenteld ki az fstab-ból, lehet, hogy bebootol. Utána viszont mindenképpen meg kéne keresni, miért nem lehet mountolni, mert időnként szükséges, hogy mountolva legyen. (ha pl. valami grub, vagy egyéb update frissíteni akar ott bármit.)
Kézzel megpróbálhatod mountolni, az fstab alapján, ekkor ki kell derülni, hogy mi ment félre.
szerk:
Nem lehet, hogy sda megmakkant?:
Remelem nem a hdd-vel van gond, bar semmifele szoftveres beallitas nem tortent. Masik linux ugyanarrol a hdd-rol gond nelkul bebootol.
Megprobalom amit irtal, nem is tudom hirtelen, hogy mi van az fstabban.
swapra is van panaszkodás a logokban.
Viszont ha másik linux is van rajta, akkor az lehet a gond amit lentebb a kolléga ír.
Szerk:
Nekem úgy tűnik, ez a hibás rész. Minden más ez alatt dependency miatt fut hibára.
fstab-ban meg kéne nézni hogy létezik -e mindegyik uuid
Arra azért figyelni kell, hogy a systemd saját ügyes kis bigyókat generál az fstabból, így hiába van kiszedve onnét valami, kell neki egy
Vagy valami, egyébként ugyanúgy megförmed majd.
Aztán a megkáoszosodott uuid-k is gyanúsak,
Éééés összenézni, hogy mibaj lehet.
A net szerint ez akkor fordul elő, ha az /etc/fstab-ban nem jól vannak a meghajtók UUID-i hivatkozva. Ezt okozhatja az is, ha más Linuxot telepítettél mellé, és mondjuk annál a meglévő swap partíciót használtad, vagy ilyesmi.
Amivel én nekimennék root-ként:
blkid ; cat /etc/fstab
Megnézni, hogy az UUID-k egyeznek-e, minden felcsatolni kívánt partíciónál. Az is igaz, hogy ezt akkor ajánlom, ha a tanulás, hibaelhárítás fejlesztése a cél. Ha tényleg használni akarod a gépet, akkor nem upgrade-elsz egy ilyen régi problémás rendszert, újrahúzod az egészet a legfrissebb verzióval, adatokat előtte mented, ha nem lennének külön partíción. Gyorsabb, biztosabb.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Bár nem az én gépem, tudtommal semmiféle telepítgetés, változás nem történt egy jó hosszú ideje.
Az fstab releváns része:
Mindenesetre a /boot/efi-s sort kikommentezve elindul... .
Nyomj egy "ls -l /dev/disk/by-uuid/" -t és hasonlítsd össze az fstab-al
Szerk: vissza kéne hozni az efi partíciót is, mert ellenkező esetben előfordulhat, hogy egy update után már nem bootol be.
Akkor megoldódott? Össze kéne vetni a blkid kimenetével is, hogy van-e egyezés az összes bejegyzés között.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)