Wygląda na to, że mam problem z nowym mkinitcpio na ArchLinux32 i starym kernelem 4.19 (jeszcze nie zmienionym po migracji z Manjaro32 ),
Pamiętam, że wczoraj aktualizował się m.in. mkinitcpio i dziś system nie chce powstać (był komunikat o “kernel panic”).
Domyślam się że przyczyną są zmiany w Archu opisane w wątku: 'zstd' domyślnym kompresorem obrazów 'initramfs'
Dlatego w /etc/mkinitcpio.conf ustawiłem:
COMPRESSION=“gzip”
Jednak system ciągle nie wstaje. Pokazuje się “kernel panic”, jak poniżej.
Idąc na logikę, potrzebny jest krok nr 4. Tylko mała uwaga, ja o tych tematach nie wiem kompletnie nic, lepiej, żeby wypowiedział się także ktoś bardziej doświadczony w temacie. Przejdźmy do rzeczy, skoro to jest plik konfiguracyjny, który jest wykorzystywany tylko przy aktualizacji kernela to trzeba jakoś tę aktualizację wymusić, żeby zastosować nowe ustawienia. No to patrzę, pierwszy z brzegu wątek z identycznym problemem – pojawia się jakaś tajemnicza fraza o regeneracji mkninitcpio. Idę za ciosem i szybko znajduję ten wątek, zajrzałem także na Wiki, też jest całkiem zgrabne opisanie tematu. W skrócie, sprowadza się to do wydania polecenia mkinitcipio -p linux lub mkinitcpio -P.
Czy to w jakiś sposób pomoże, nie wiem, mam jednak nadzieję, że wskaże sposób w jaki szukać rozwiązania
/etc/mkinitcpio.conf jest plikiem konfiguracyjnym mkinitcpio. Nie ma znaczenia co w nim napiszemy, dopóki nie uruchomimy mkinitcpio. Dlatego, jeżeli dokonaliśmy w nim jakichś zmian (w tym przypadku, zmodyfikowałeś format kompresji) i chcemy, aby zaczęły obowiązywać, to musimy wykonać, na przykład, taką komendę:
$ sudo mkinitcpio -P
która przebuduje nam wszystkie (-P) obrazy initramfs, kompresując je w standardzie, który wybraliśmy (w tym przypadku gzip).
Restart i panic powinien minąć.
Dzięki za info. Tego się obawiałem. Ale po kolei.
Przebieg zdarzeń był następujący:
Zaktualizowałem system (w tym mkinitcpio i, o ile pamiętam, tworzyły się także obrazy initramfs, co prawdopodobnie jest źródłem obecnego problemu).
Dalej system normalnie pracował (bez restartu) jeszcze przez kilka godzin.
Po restarcie pojawił się błąd “kernel panic” (choć nie pamiętam, czy były dokładnie te same komunikaty, które pokazałem w 1. poście).
Ustawiłem wspomnianą linię w mkinitcpio.conf (z poziomu innej dystrybucji, którą mam na tym sprzęcie).
Po kolejnym restarcie pojawił się błąd “kernel panic”, który pokazałem w 1. poście.
A skoro system nie wstaje, to teraz muszę zrobić chroot’a, aby wykonać komendę sudo mkinitcpio -P i zastanawiam się jak?
O ile wiem, nie ma dostępnej wersji Live USB/CD dla Archa 32-bit, a to byłoby wskazane, aby chroot’ować najprościej, tj. poprzez arch-chroot .
Nie dysponuję także żadnym innym Live USB 32-bit (będę musiał ew. utworzyć),
Choć na szczęście mam na tym sprzęcie zainstalowane OpenSuse Tumbleweed 32-bit i mam nadzieję uda się stąd zrobić chroot’a.
Jednak w obu ostatnich dwóch przypadkach będę musiał robić ręcznie chroot’a (czego nie lubię i co niesie z sobą pewne zagrożenia).
OFFTopic
Nie wypowiadałem się w dyskusji Naprawdę istnieje wyższość Archa nad Manjaro? , ale chociażby ten przypadek, utwierdza mnie w przekonaniu o wyższości Manjaro nad topornym Archem.
Na tym leciwym sprzęcie najnowsze jądro to 4.19.
Ponieważ kiedyś nawet z nim miałem tu problem i musiałem przez jakiś czas korzystać z wcześniejszego LTE 4.14, nawet nie sprawdzałem nowszych kerneli LTE, zakładając, że będą zbyt nowoczesne na tym sprzęcie. Założenie, jak teraz wiem, było błędne, gdyż w instalowanym OpenSuse jest 5.10 i wszystko działa.
Spróbuję najpierw zrobić chroot’a z poziomu zainstalowanego OpenSuse (może się uda).
A jak nie, to zrobię Manjaro32 Live.
),
