Linux mint emergency módba bootol - de miért?

Linux Mint

Ü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).

  • 506 megtekintés

( Fisher v | 2023. 06. 07., sze – 19:48 )

-- The result is timeout.
jún 07 19:14:37 mintdeb systemd[1]: Dependency failed for /boot/efi.
-- Subject: Unit boot-efi.mount has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit boot-efi.mount has failed.
-- 
-- The result is dependency.
jún 07 19:14:37 mintdeb systemd[1]: Dependency failed for Local File Systems.
-- Subject: Unit local-fs.target has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Ez szerintem probléma lehet.

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?:

Jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2615 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1' is taking a long time
jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2618 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda4' is taking a long time
jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2616 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2' is taking a long time
jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2620 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda6' is taking a long time
jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2617 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3' is taking a long time
jún 07 19:14:15 mintdeb systemd-udevd[393]: seq 2619 '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5' is taking a long time
jún 07 19:14:37 mintdeb systemd[1]: dev-disk-by\x2duuid-DE1D\x2dF692.device: Job dev-disk-by\x2duuid-DE1D\x2dF692.device/start timed out.
jún 07 19:14:37 mintdeb systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-DE1D\x2dF692.device.

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

 

- Subject: Unit dev-disk-by\x2duuid-DE1D\x2dF692.device has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit dev-disk-by\x2duuid-DE1D\x2dF692.device has failed.

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

systemctl daemon-reload

Vagy valami, egyébként ugyanúgy megförmed majd.

Aztán a megkáoszosodott uuid-k is gyanúsak,

lsblk -lf

Éééés összenézni, hogy mibaj lehet.

( Raynes v | 2023. 06. 07., sze – 21:09 )

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.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

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:

 

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=a6b67362-a6af-45e0-b36b-938bfe26a055 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=DE1D-F692  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sda3 during installation
UUID=68e9741b-2564-440c-8017-75a113ab44fa none            swap    sw              0       0