Raspberry Pi4B / (64 de biți 21.04): 5.11 actualizarea kernel tree -1014-raspi / 1015-raspi apt distruge sistemul de operare

Acum am două dintre instalările mele RPi4B (Xubuntu, 64 de biți) din 21.04 într-o stare care nu poate fi pornit după o actualizare normală apt cu actualizarea arborelui kernel la 5.11.0-1014-raspi sau 5.11.0-1015-raspi. Am făcut primul raport de eroare cu privire la acel lucru cu aproximativ o săptămână în urmă, când prima dintre build-urile mele RPi4B a pornit în Rainbow of Death și i-am avertizat pe dezvoltatori că există o problemă cu asta. Am crezut că ar fi fost sigur să actualizez pe un alt RPi4B care rulează același sistem de operare, acum pornește la sublinierea doom.

Cum pot repara bootloader-ul, dacă este deloc? Orice ajutor este apreciat. Nu am nicio idee despre ce se întâmplă în întregul segment uboot și așa mai departe, și sunt sigur că nu aș vrea să reinstalez întregul sistem de operare de la zero.

Prima unitate care nu poate fi pornită arată că nu merge absolut nimic greșit în /var/log/, iată ultimul dintre jurnalele din aceea: https://paste.ubuntu.com/p/SXnzTTsNtS/

Întrebarea mea principală este; pot readuce cumva bootloader-ul la viață, deoarece asta pare să fie problema aici? Când prima unitate a fost dezafectată din cauza unei actualizări apt, am copiat datele partiției de pornire din cea care încă funcționa și am încercat să sincronizez datele, fără niciun rezultat.

Nu există absolut nicio documentație despre cum funcționează Uboot-ul Ubuntu pe RPi4B, cel puțin eu nu am găsit niciuna. Dacă cineva mă poate îndruma către Raspberry Pi 4B Documentația U-boot, aș fi foarte bucuros să o citesc. Acum nu am noroc cu două versiuni de sistem nefuncționale care au funcționat perfect înainte de actualizarea de rutină a nucleului.

Va rog un sfat. Mulțumiri.

ACTUALIZARE 1: Am primit un stick USB proaspăt, cu Ubuntu Server pe 64 de biți pentru RPi4B rpi-imagerși pornit într-un sistem nou. După ce a rulat actualizări și upgrade-uri apt, s-a actualizat și la -1015-raspi, după care am repornit și a mers în „curcubeul morții” cu patru clipi la rând (ceea ce ar indica că nu a fost găsit un bootloader).

Deci, altul mușcă praful. Speram să pot obține un bootloader funcțional în acest fel, dar nu am avut noroc.

UPDATE 2: Există acum un raport de eroare la https://bugs.launchpad.net/ubuntu/+source/linux-meta-raspi/+bug/1937924

UPDATE 3: SOLUȚIONAT Am rezolvat-o pe cont propriu, fără a fi nevoie să reinstalez, așteptând o nouă actualizare apt pentru pachetele de kernel și apoi am copiat doar datele partiției de pornire dintr-o instalare nouă în cea a sistemului de operare defect. (Vezi răspunsul de mai jos.)

Ubuntu pornește de la partiția fat32 a cardului SD. În timpul flashării noului nucleu, fișierele celui vechi sunt salvate cu .bak extensie. Deci, redenumiți-le folosind un alt Linux.

1. Montați partiția de pornire (/dev/sda1 În cazul meu)

sudo mount /dev/sda1 /mnt

2. Redenumiți toate fișierele cu .bak sufix.

sudo redenumește -f -v 's/.bak//g' /mnt/*.bak
sudo redenumește -f -v 's/.bak//g' /mnt/overlays/*.bak

Terminat!

UPD: Dacă motivul problemei dvs. este o partiție de pornire prea mică, este posibil ca această abordare să nu vă ajute.

Am remediat acest lucru pe cont propriu, doar așteptând ca o nouă actualizare a nucleului să fie disponibilă pe Ubuntu pe 64 de biți pe RPi4B. Am scris cea mai recentă imagine a Ubuntu Server pe 64 de biți pe un stick USB folosind rpi-imager și apoi a rulat configurarea inițială pe RPi4B pe acesta. Apoi am rulat o instalare pe toate cele disponibile actualizare apt / upgrade apt pachete și ne-am asigurat că pornește fără probleme după aceste actualizări.

Am copiat apoi toate cizme-Fișierele partiției de la noul server Ubuntu sănătos la sistemul de operare deteriorat cizme partiţie, excluzând meta-date, network-config și datele utilizatorului fișierele precum și cmdline.txt și config.txt.

Conectat și rugat, după un timp de fscking în patru puncte (. . . .) Ecranul Ubuntu, ambele sisteme de operare au revenit la viață! Sunt extrem de fericit acum.

Așa că da, a fost o problemă de bootloader așa cum credeam. Doar un sfat pentru a fi cu ochii pe acest potențial capcan, ca nu cumva să ajungeți în același tip de limb după o problemă legată de nucleu. actualizare apt. Faceți backup des! :o)