ArchLinux32 - czarny ekran po aktualizacji i restarcie

Inne dystrybucje
1

Po wczorajszej aktualizacji Arch Linux 32 ( razem 2+9 pakietów - jak pokazane w logu poniżej) i po restarcie nie uruchamia mi się środowisko graficzne (Xfce). Pokazuje się czarny ekran (migający na ułamek sekundy co ok 1 sekundę).
Spośród zaktualizowanych pakietów wytypowałem (chyba jednak błędnie) pakiet llvm-libs (wymagany przez mesa) , zrobiłem chrootowanie i przywróciłem jego poprzednią wersję (12.0.1-4.0)
Jednak to nic nie dało .

Macie jakiś pomysł, jak rozwiązać ten problem?

[2021-10-22T07:19:58+0200] [PACMAN] Running 'pacman -Syu'
[2021-10-22T07:19:58+0200] [PACMAN] synchronizing package lists
[2021-10-22T07:20:02+0200] [PACMAN] starting full system upgrade
[2021-10-22T07:20:12+0200] [ALPM] transaction started
[2021-10-22T07:20:13+0200] [ALPM] upgraded git (2.33.0-1.0 -> 2.33.1-1.0)
[2021-10-22T07:20:13+0200] [ALPM] upgraded xfce4-whiskermenu-plugin (2.6.0-1.0 -> 2.6.1-1.0)
[2021-10-22T07:20:14+0200] [ALPM] transaction completed
[2021-10-22T07:20:14+0200] [ALPM] running '20-systemd-sysusers.hook'...
[2021-10-22T07:20:14+0200] [ALPM] running '30-systemd-daemon-reload.hook'...
[2021-10-22T07:20:15+0200] [ALPM] running '30-systemd-update.hook'...
[2021-10-22T07:20:15+0200] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-10-22T10:06:52+0200] [PACMAN] Running 'pacman -Syu'
[2021-10-22T10:06:52+0200] [PACMAN] synchronizing package lists
[2021-10-22T10:06:56+0200] [PACMAN] starting full system upgrade
[2021-10-22T21:50:23+0200] [PACMAN] Running 'pacman -Syu'
[2021-10-22T21:50:23+0200] [PACMAN] synchronizing package lists
[2021-10-22T21:50:40+0200] [PACMAN] starting full system upgrade
[2021-10-22T21:53:22+0200] [ALPM] transaction started
[2021-10-22T21:53:23+0200] [ALPM] upgraded libffi (3.3-4.1 -> 3.4.2-4.0)
[2021-10-22T21:53:23+0200] [ALPM] upgraded glib2 (2.70.0-1.0 -> 2.70.0-2.5)
[2021-10-22T21:53:23+0200] [ALPM] upgraded glib2-docs (2.70.0-1.0 -> 2.70.0-2.5)
[2021-10-22T21:53:24+0200] [ALPM] upgraded guile (2.2.7-2.1 -> 2.2.7-2.4)
[2021-10-22T21:53:24+0200] [ALPM] upgraded libp11-kit (0.24.0-1.1 -> 0.24.0-2.3)
[2021-10-22T21:53:32+0200] [ALPM] upgraded llvm-libs (12.0.1-4.0 -> 12.0.1-5.1)
[2021-10-22T21:53:32+0200] [ALPM] upgraded p11-kit (0.24.0-1.1 -> 0.24.0-2.3)
[2021-10-22T21:53:44+0200] [ALPM] upgraded python (3.9.6-1.3 -> 3.9.7-2.1)
[2021-10-22T21:54:03+0200] [ALPM] upgraded python2 (2.7.18-3.0 -> 2.7.18-5.1)
[2021-10-22T21:54:04+0200] [ALPM] transaction completed
[2021-10-22T21:54:05+0200] [ALPM] running '30-systemd-update.hook'...
[2021-10-22T21:54:05+0200] [ALPM] running 'texinfo-install.hook'...
2

Przełączyć się na inne TTY i zobaczyć w logach co mu przeszkadza.

3

Próbowałem, ale Ctrl+Alt+F4 nie działa (ani inny klawisz Fn).
Jest jakiś inny sposób?

4

W takim razie spróbuj przejrzeć logi z poziomu live.

5

Czy pisząc “przejrzeć logi z poziomu live” masz na myśli chrootowanie i komendę: journalctl -b | grep error ?

Czy może można to zrobić prościej i wygodniej (bez chrootowania) z poziomu live, np. podglądając jakoś(?) pliki w /var/log/journal/ lub inne?

6

Można na pierwszy sposób, ale fakt miałem na myśli coś prostszego: journalctl --directory=/var/log/journal

1 polubienie
7

Czy dobrze rozumiem, że:
z poziomu innej dystrybucji (OpenSuse, nie Live USB) na tym PC dostanę się do logów Archa32 za pomocą komendy:
journalctl --directory=/NAZWA-KATALOGU-MONTOWANIA-DO-ARCH32/var/log/journal -b

8

Z poziomu root-a dostaniesz się wszędzie. :wink:

9

Spróbuj. systemd.unit=rescue.target

Przy starcie systemu, w czasie wyświetlania listy rozruchu wciskamy e.
Do linii zaczynającej się od:

linux /boot (…)

na końcu dopisujemy:

systemd.unit=rescue.target

i wciskamy Ctrl+x.

Że tak będę beszczelny i podlinkuję swoją wypowiedź. :slight_smile: Koła ratunkowe

1 polubienie
10

@Tomek, @aquila - dzięki za wskazówki. Obie metody są dobre i pozwalają na przeglądnięcie logów.

Ostatni log (jak poniżej) wskazuje na problemy z leciwym dyskiem, w którym coś się posypało, tym razem na partycji z Arch32 (która kiedyś była sprawdzana i była OK).
journalctl --directory=/NAZWA-KATALOGU-MONTOWANIA-DO-ARCH32/var/log/journal -b | grep error

paź 23 04:19:34 archlinux kernel: EXT4-fs (sda7): warning: mounting fs with errors, running e2fsck is recommended
paź 23 04:19:59 archlinux alsactl[500]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel at 0xfebfc000 irq 24)
paź 23 04:19:59 archlinux alsactl[500]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
paź 23 02:24:50 archlinux kernel: EXT4-fs (sda7): error count since last fsck: 9
paź 23 02:24:50 archlinux kernel: EXT4-fs (sda7): initial error at time 1631308308: ext4_lookup:1784: inode 1966241
paź 23 02:24:50 archlinux kernel: EXT4-fs (sda7): last error at time 1632255048: ext4_lookup:1784: inode 1966241

Teraz stoję przed dylematem, w jaki sposób najbezpieczniej naprawić tą partycję, w miarę możliwości jej nie niszcząc.

  • W wiki Archa nie znalazłem żadnego jasnego i kompletnego opisu.
  • W moich notatkach sprzed lat mam zapisaną procedurę:
# Sprawdzany dysk lub partycja (tu: sdc lub sdc1 ) musi być odmontowana !!! :
sudo badblocks -v -s /dev/sdc > badblocks.log  lub sudo badblocks -v -s /dev/sdc1 > badblocks.log
# Marking bad blocks (marked blocks will be ignored by the system in future):
sudo e2fsck -l badblocks.log /dev/sdc lub sudo e2fsck -l badblocks.log /dev/sdc1
  • Zrobiłem testowo operację sprawdzania innej, testowej partycji za pomocą GParted, który to soft pokazał przejrzysty log tej operacji z komendami trochę innymi niż powyższe ( e2fsck -f -y -v -C 0 '/dev/sda3' oraz resize2fs -p '/dev/sda3' ), choć zbieżnymi z artykułem z 2014 roku

Skłaniam się do skorzystania z GParted, bazując na renomie tego softu i zastosowanych tam, jak sądzę, najnowszych i bezpiecznych rozwiązaniach.

Czy ktoś ma jakieś inne pomysły, uwagi w tej kwestii?

Edit:
Wykonałem naprawianie partycji za pomocą GParted i trochę błędów zostało znalezionych i naprawionych oraz zaktualizowałem GRUBa. Jednak ciągle po restarcie mam ten sam czarny ekran.

Obecnie nie ma już błędów związanych z systemem plików, natomiast pozostały jeszcze dwa , z którymi nie wiem co dalej zrobić. Pakiet alsa-lib był ostatnio aktualizowany kilka miesięcy temu, a awarię mam od 2 dni, więc raczej ten pakiet nie powinien być żródłem tej awarii. Szczególnie, że dotyczy on dźwięków, które jeszcze 2 dni temu działały, a problem u mnie ma związek z obrazem/systemem.

paź 24 20:51:46 archlinux alsactl[452]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel at 0xfebfc000 irq 25)
paź 24 20:51:46 archlinux alsactl[452]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6

Ktoś ma jakiś pomysł albo wiedzę?

11

Przelotnie udało mi się rozwiązać problem, poprzez przywrócenie ostatnio upgradowanych 9 pakietów do ich poprzedniej wersji.

Niestety, krótko nacieszyłem się działającym systemem.
Pojawiła się kolejna, trochę większa aktualizacja (42 pakiety, w tym te 9, które cofnąłem do poprzedniej wersji). Ponieważ nowych pakietów było 33, zaryzykowałem, licząc, że jest wśród nich trwałe rozwiązanie problemu czarnego ekranu.
Niestety wykonanie aktualizacji skutkowało ponownym czarnym ekranem.
A gdy znowu cofnąłem wersję tych wcześniejszych 9 pakietów, to tym razem nie udało się uruchomić systemu i znowu jest czarny ekran :frowning:

Analizując raz jeszcze te ostatnie 9 problematycznych pakietów, zauważyłem, że większość z nich wymaga zależności libffi, która też była tu zmieniana (3.3-4.1 → 3.4.2-4.0) i być może to jest źródłem problemu.

Jak sprawdziłem na głównym forum Archa, pakiet ten jest ostatnio wymieniany jako źródło różnych problemów, więc jest szansa, że developerzy naprawią wkrótce ten pakiet.

Póki co pozostaje mi obyć się bez Archa32 i poczekać (na szczęście mam alternatywę na tym sprzęcie - OpenSuse).
Mam nadzieję, że w ciągu tygodnia znajdzie się jakieś rozwiązanie. A jeśli nie, to pożegnam się z ostatnio bardzo problematycznym i kulejącym Archem32 i poszukam jakieś stabilnej 32-bitowej alternatywy.

12

Po dwóch tygodniach zmagań udało mi się w końcu przywrócić Archa32.

W międzyczasie zainstalowałem polecany pakiet libffi33 (będący protezą libffi w Archu32 i mający naprawić liczne błędy związane z tym pakietem), jednak nie przyniosło to u mnie poprawy.

Dopiero instalacja kolejnej partii (ok 40) pakietów, gdzie większość to było pakiety mające w nazwie “python” (którego zależnością jest libffi), przywróciła ArchLinux32.

Była to najdłuższa - 2 tygodniowa - przerwa bez działającego Archa32 i już byłem zdeterminowany, aby go usunąć i zamienić na MX Linux. Ale… Wychodzi na to, że jeszcze trochę będę korzystał z Archa32, który jest przyzwoitym, a przede wszystkim szybkim systemem - o ile działa :wink:

1 polubienie