Scopul acestui subiect este:
pentru a determina dacă există o problemă cu nucleul 5.8.0-59, ar trebui să raportez pe launchpad, deoarece nu știu până în acel moment
pentru a cere îndrumare pentru a modifica nucleul standard de la care începe,
cum să ștergeți alte nuclee.
EDITARE: Pentru a instala dependențele pentru Kernel 5.12.14 pentru încercări ulterioare
Rulez un HP ProBook 450 G6 cu LTS 20.04.2, dar din moment ce Software Updater a instalat kernelul 5.8.0-59.66 pe acel computer, acesta intră într-un ecran complet negru când LUKS ar trebui să solicite parola.
Am așteptat o jumătate de oră să verific dacă ar apărea ceva, dar nu s-a schimbat nimic.
Nici introducerea orbește a parolei și apăsarea pe return nu a arătat niciun efect. - GREȘIT, vezi mai jos
Pot spune că sistemul și LUKS nu sunt modificate manual prea mult, cu excepția unui fișier de schimb, nu există niciun software inițializat înainte de autentificarea utilizatorului,
ca și cum rulez Gnome obișnuit, hardware-ul are doar 1 iGPU fără GPU dedicat, rulând pe drivere X11, deci cu siguranță nu există drivere GPU dedicate, cum ar fi plăcile nVidia.
De asemenea, am deconectat toate dispozitivele USB de la sistem pentru depanare, fără efect.
Cu utilizarea opțiunilor avansate de pornire și selectarea unui nucleu mai vechi, cum ar fi 5.8.0-55.62, totul funcționează conform așteptărilor, chiar și atunci când unele setări precum Dispozitiv audio și Dispozitiv cu microfon au fost modificate.
Probleme cu nucleul 5.8.0-59?
Mă opresc mai întâi aici înainte de a lua în considerare raportarea unei erori, astfel încât raportul de eroare poate fi mai bogat în informații, deoarece nu sunt sigur cum să o gestionez.
Nu sunt prea sigur ce jurnale aș putea configura sau citi dintr-o încercare de pornire, așa că ați putea să mă sfătuiți să stabilesc că problema este de partea mea cu conflictele software sau dezvoltatorul. latură?
Îndepărtarea nucleelor
Filtrarea comenzii dpkg ar trebui să funcționeze pentru a determina ce nucleu dorim să ștergem. Așa că am găsit acest exemplu https://phoenixnap.com/kb/ubuntu-remove-old-kernels
sudo dpkg ââlist | egrep âi ââcolor âlinux-image|linux-headersâ
sau
sudo dpkg ââlist | egrep âi ââcolor âlinux-image|linux-headersâ | wc âl
dar sistemul meu pare să nu aibă WC, nici parametrul --color nu funcționează pentru mine așa cum solicită CLI.
Aș aprecia în continuare ce beneficii ar avea această metodă complicată, dar pentru a termina pur și simplu treaba acum, utilizați o comandă mai simplă
dpkg --list | grep linux-image
Acest lucru determină ceva. Aș putea lucra cu.
Acum trebuie să șterg o selecție din asta.
Manualul din linkul de mai sus, sugerează ca Metodă să
Eliminați manual nucleele individuale din linia de comandă
următoarea comandă care listează din nou Kernel-urile, dar cu starea lor de instalare:
dpkg -l | coada -n +6 | grep -E 'linux-image-[0-9]+' | grep -Fv $(uname -r)
Mi-a cerut o listă, lipsind nucleul care este în uz în prezent (5.8.0-55.62...). Cred că nu sună prea greșit, deoarece nucleul este activ și rulează (?).
Acum partea distractivă: kernel-ul 5.8.0-59 pe care vreau să-l marchez pentru a-l șterge, este deja marcat ca „instalat și eligibil pentru eliminare” cu indicatorul de stare „ii”.
Deci, să încercăm mai întâi comanda autoremove:
sudo apt-get ââpurge autoremove
Verificarea din nou cu lista dpkg anterioară, dacă nucleul este acum starea „rc” sau încă „ii” dovedește că Kernel-ul 5.8.0-59 încă există și este marcat „ii”. Mhhhh... Nu a funcționat așa cum ar trebui.
Deci încercăm să o facem manual:
sudo dpkg ââpurge linux-image-5.8.0-59-generic
sau
sudo dpkg ââpurge remove linux-image-5.8.0-59-generic
dar acest lucru îndeamnă
dpkg: eroare: nevoie de o opțiune de acțiune
Cea mai bună presupunere ar fi că acest cod de eroare a fost solicitat, deoarece nu a mai rămas niciun alt nucleu în sistem, cu excepția 5.8.0-55.62, dar nu știu sigur.
Sunt blocat in acel moment:
Nu știu cum să elimin manual nucleul dorit.
De asemenea, nu sunt sigur cum este făcută lista de nuclee - este doar generată de imaginile disponibile sau există vreo listă de modificat?
--- Actualizări cronologice:
Kernel 5.8.0-63.71
Actualizare: Mașina a fost actualizată la kernel-ul 5.8.0-63.71 și ecranul gol a persistat.
Un alt utilizator, confirmând problema
Un alt utilizator a raportat aceeași problemă pe cele două echipamente ale sale HP ProBook 450 G7. Din păcate, l-a postat ca răspuns la întrebarea mea și a fost votat negativ/șters, așa că acum răspunsul lui a dispărut! Mulțumesc pentru această grozavă Housekeeping @Mods, ar fi fost grozav să-l ajut pe utilizator și să copiați/lipiți răspunsul său în secțiunea de comentarii.
După cum am menționat, folosesc unele HP ProBook 450 G6, deci este generația anterioară. Hardware-ul este diferit, dar ambele sunt procesoare Intel și iGPU. Software-ul/Setările HP pot interfera, de asemenea, deoarece multe aparate HP sunt raportate cu probleme similare.
Firmware (UEFI)
Am verificat cel mai nou firmware HP ProBook 450 G6 și Intel și am făcut upgrade de la 1.08.0 la cel mai nou firmware R71 1.16.0 până la această dată. Acest lucru pare să nu aibă niciun efect.
Sfat pentru utilizatorii Linux care au nevoie să își actualizeze firmware-ul: HP oferă numai instalatori Windows pentru fișiere.
Dacă nu aveți Windows sau VM sau Wine nativ, nu puteți accesa aceste fișiere.
De îndată ce VM/Wine instalează fișierele, puteți să răsfoiți directorul de instalare (Calea standard este în C:\SWSetup\XXXXXX), să creați un stick USB FAT32 și să creați manual structura folderului „EFI\HP\BIOS\New” și plasați fișierul .bin acolo, deoarece acesta este tot ceea ce face instalatorul.
Dacă nu aveți Windows nativ, rutarea dispozitivului USB către Wine/VM poate fi dificilă, așa că prin acest indiciu sper că v-am economisit ceva timp.
TPM
IRC #ubuntu Utilizatorul TJ- recomandat să porniți Grub - Linia de comandă și „rmmod tpm” pentru a testa dacă problema se datorează TPM.
Se pare că această comandă nu a funcționat, deoarece TPM era încă activ:
https://pastebin.com/c4UeXXsa
S-a încercat și dezactivarea globală a TPM în firmware-ul UEFI:
Jurnalul ar trebui să fie cel corect, dar afirmă că TPM a fost activat. Voi efectua un alt log la următoarea repornire din nou:
https://pastebin.com/fjK8TVVL
- Dar va trebui să refac asta și să verific jurnalul dacă TPM a fost dezactivat cu succes.
update-grub
update-grub a fost efectuat, fără efect.
Pornirea modului de recuperare
Am încercat să pornesc modurile de recuperare ale Kernel-ului 5.8.0-59 și -63: Pornirea în recuperare, și apoi pornirea „complet”, funcționează. IGPU/ecranul nu este operat de driverul obișnuit prin aceasta (care poate fi motivul pentru care ecranul nu s-a oprit de data aceasta), deoarece, de exemplu, Night Light nu funcționează cu asta și s-a dezvăluit o privire rapidă în pagina Setări Gnome Despre unele GPU/driver diferite
Pornirea cu introducerea oarbă a parolei - funcționează
Am încercat să pornesc din nou Kernel-ul -59 și am introdus LUKS și parola de utilizator orb.
Pentru că nu aveam un al doilea monitor, am încercat să pornesc o aplicație muzicală și a funcționat. Deci computerul a inițializat cu succes nucleul și a pornit cu succes în cea mai mare parte, nucleul are doar câteva probleme cu ecranul/gpu-ul din câte știm! (Alți utilizatori cu hardware similar și rapoarte de erori, descriu un port de ecran extern funcțional)
Iată un jurnal jurnalctl -b al acestuia:
https://pastebin.com/uTAUG6XH
și pentru compararea cu o pornire „reușită” cu Screen/GPU de Kernel 5.8.0-55:
https://pastebin.com/6qzCSKPR
Nu am comparat jurnalele profesional, dar utilizatorul IRC #ubuntu tomreyn a notat această linie:
gnome-shell[1530]: Nu s-a putut seta gama CRTC: drmModeCrtcSetGamma activat
CRTC 51 a eșuat: permisiunea refuzată
Este nevoie de investigații profesionale suplimentare dincolo de contribuția mea de utilizator.
Kernel 5.12.14
A fost recomandat aici https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1934647 pentru a încerca nucleul 5.12.14.
Am descărcat fișierele și dpkg le-a instalat, dar lipsea o anumită dependență: cred că numele repertoriului era lib6c și avea nevoie de un upgrade de la 2.1 la 2.3 sau ceva de genul ăsta.
Dar actualizarea cu apt-get install -f, apt-get update && upgrade, apt --fix-broken install nu a putut efectua upgrade-ul.
Am efectuat o ștergere automată care elimina unul dintre cele 4 fișiere de kernel cu actualizarea de dependență lipsă.
update-grub după aceea, totuși,
celelalte 3 sâmburi
În mod evident, pornirea din nou cu noul nucleu nu a fost posibilă și a solicitat ceva, cum ar fi Kernel, Ramdisk sau initd, ceea ce este de înțeles deoarece are nevoie de fișierul kernel eliminat automat și de dependențele cerute de acesta.
Acum mă întâlnesc în aceeași situație ca cea menționată mai sus: eliminarea manuală a nucleelor solicită aceeași „acțiune necesară” ca cea menționată mai sus. Fie trebuie să găsesc motivul pentru această solicitare de eroare, fie trebuie să instalez fișierul lipsă și să actualizez dependența.
Diagnosticare
Vreau să ofer jurnalele de diagnosticare suplimentare, dar nu sunt sigur de ce:
Așa că nu ezitați să mă sfătuiți ce jurnaluri vă place să vedeți în comentarii și poate să îmi citați comanda. Mulțumiri
