( Piszę z awaryjnego konta - ze smartfona. Z góry przepraszam jeśli nie wyglądać będzie to składnie.)
W trakcie ostatniej aktualizacji pojawiła mi się totalna katastrofa i system nie wstaje.
W jej trakcie przełączałem ekran (w trybie Dual monitor) i system się zawiesił.
Po restarcie GRUB sygnalizował błąd – brak pliku initramfs…img .
Potem, z poziomu chroot’a zrobiłem poniższe:
Wykonałem przywracanie i aktualizację Gruba. Wtedy po kolejnym restarcie okazało się że w menu Grub nie ma wpisu o głównym systemie Manjaro, z tego korzystam.
W katalogu boot sprawdziłem, że rzeczywiście nie ma tych plików .img .
Za pomocą komendy ‘dracut --regenerate-all’ przywróciłem pliki .img ( ostatnie dwa z których korzystałem, a także pojawiły się dwa wcześniejsze).
Ponownie wykonałem przywracanie i aktualizację Gruba.
Po kolejnym restarcie, niestety ciągle brak wpisu w menu Gruba o głównym Manjaro.
Czyli po prostu przerwało aktualizację gdzieś w połowie. Zrób chroot, dokończ aktualizację systemu i powinno być git.
Być może będziesz musiał wykonać coś jeszcze – standardowo bowiem jest mkinitcpio, a nie dracut. Sam z dracutem nigdy nie eksperymentowałem, więc raczej nie będę zbyt pomocny.
gdy system mi się zawieszał, aktualizacja była W końcowej fazie, jakieś 80%. Czekałem jeszcze z 15 minut ( w tym czasie grało radio internetowe więc zakładam , że aktualizacja trwała w tle, choć jej nie widziałem).
Obecnie dokończenie aktualizacji zarówno za pomocą Pacman jak i Pamac kończy się komunikatem , że nie ma nic do zrobienia.
Przed awarią miałem dwa kernele: 515 i 61.
Po tym jak w katalogu Boot dodałem brakujące pliki, obecnie wygląda to tak: Album — Postimages
Natomiast po zmianie w tym katalogu nazwy pliku dla jądra 515 i ponowieniu komendy, pojawia się kolejny błąd o braku obrazu vmlinz dla 515 (jak w załączniku powyżej).
Może spróbuj wgrać sobie jeszcze inne jądro - na przykład najnowsze 6.6 - wtedy pamac powinien stworzyć wszystkie pliki potrzebne do rozruchu. Jeśli to postawi system na nogi, to potem usuniesz niepotrzebne jądra.
I jeszcze zawartość mojego pliku /etc/mkinitcpio.d/linux515.preset.pacsave:
# mkinitcpio preset file for the 'linux515' package
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-5.15-x86_64"
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-5.15-x86_64.img"
#default_options=""
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-5.15-x86_64-fallback.img"
fallback_options="-S autodetect"
Możesz porównać i sprawdzić, czy tam nie jest coś skopane, ale prawdopodobnie przyczyną całego problemu jest brak pliku /boot/vmlinuz-5.15-x86_64'. Być może ponowna instalacja tego kernela doprowadziłaby do utworzenia tego pliku.
Tak nie wyglądają kernele Manjaro, kernele Manjaro są generowane bez ostatniej cyferki. No i masz tam parę rzeczy nie wiadomo skąd (dracut?). Ogólnie zawartość tego katalogu powinna wyglądać mniej więcej tak:
Niestety, zarówno reinstalacja ( odpowiednio komendą ‘mhwd-kernel -i linux515’ ) kerneli 515 i 61, jaki instalacja nowego kernela 65 daje ten sam komunikat błędu:
błąd: nie podano żadnych celów ( Użyj -h aby otrzymać pomoc).
O jakie cele tu chodzi? W Helpie nic nie widzę.
Jeśli chodzi o dodane pliki .img, to co sądzicie o tym żeby cztery pliki usunąć?
Częściowy sukces.
Udało mi się, choć nie wiem dokładnie jak, zainstalować z poziomu konsoli kernel 515, a następnie po zalogowaniu się już z poziomu menadżera Kernelii Manjaro dodałem kernel 61.
W weekend to przeanalizuję i dam znać co i jak tu zrobiłem.
Natomiast teraz mam problem w zalogowaniu się do mojego głównego użytkownika, gdzie mam wszystko pokonfigurowane. Po wpisaniu poprawnego hasła, co widać po braku informacji o niepoprawnym haśle, system przez chwilę coś mieli i po chwili znowu pojawia się okno logowania.
Mogę jedynie zalogować się do innego testowego użytkownika, gdzie nie mam nic praktycznie zdefiniowane.
Jeśli chodzi o log z logowania, to nie ma tu żadnych Errorów.
Podejrzany jest wpis z 2. linii: lis 08 12:13:03 pcn lightdm[681]: gkr-pam: no password is available for user
Posługując się znaleziskami w sieci:
przeładowałem pakiety z lightdm,
zmieniłem hasło użytkownika głównego (zarówno komendą passwd, jak i z poziomu ustawień Manjaro), który powinien się automatycznie logować,
sprawdziłem poprawność zapisu w /etc/lightdm/lightdm.conf jeśli chodzi o auto login,
Raczej ślepy trop, z tego co widzę poza komunikatem w logach nie ma to żadnych skutków ubocznych.
W logu nie widzę nic podejrzanego. Do TTY jesteś w stanie się zalogować? Po wyłączeniu autologowania też? Jeśli tak to wskazywałoby to na jakiś błąd w konfiguracji lightdm. W takim wypadku odsyłam do troubleshoothingu na Arch Wiki LightDM - ArchWiki
Udało się
Problem leżał w pliku ~/.Xauthority, w katalogu głównego i niedostępnego w tamtym czasie użytkownika, o czym przekonałem się, gdy po zalogowaniu się do użytkownika testowego, przeszedłem do TTY i chciałem się zalogować do mojego głównego użytkownika. Trwało to długo (z kilka minut); po czy pojawił się komunikat błędu, że jest problem z tym plikiem.
Wtedy, zgodnie z sugestią z Wiki Archa, precyzyjnie odnoszącą się do akurat tego problemu - Infinite login loop, usunąłem ten plik (szkoda, że wcześniej nie doczytałem tej strony do końca!).
Dzięki za pomoc. Po ok 60 godzinach mogę znowu w pełni korzystać z kompa
( A w weekend podam jeszcze, jak udało mi się rozwiązać pierwszy problem z GBUBem).
Wcześniej podane błędy w trybie chroot być może (?) wynikały z tego, że chroota robiłem z poziomu drugiej, awaryjnej instalacji Manjaro 17.10, nieużywanej i nieaktualizowane przez lata (, gdzie Pacman/ Pamac operował jeszcze na plikach .xz i nie byłem tam w stanie zaktualizować/zainstalować żadnej nowej paczki, bazującej na rozszerzeniach .zst ).
Po uruchomieniu systemu z Live USB, z Manjaro 22 i kernelem 61 było tak: # mhwd-kernel -i linux515 najpierw zasygnalizowało: The following packages are out of date, please update your system first: pacman-mirrors.
Po aktualizacji mirrorów, za pomocą # mhwd-kernel -i linux515 udało się reinstalować kernel515, co przy okazji przywróciło brakujące pliki vmlinuz-.
Co ciekawe, nie udało się, będąc w chroot, uruchomionym z live USB z aktywnym kernelem 61, w analogiczny sposób przywrócić kernela 61, gdyż wyskoczył komunikat błędu:
# mhwd-kernel -i linux61
Error: You can't reinstall your current kernel
Najwyraźniej system nie rozróżnia aktywnego kernela (z Live USB) od tego, który chciałem przywrócić za pomocą chroot
