[Risolto] emergency mode

salve,
ho Fedora 29 e 30 installate su due SSD diversi (per motivi vari che non sto a spiegare e poi cambierò, ma adesso non è ancora il momento per farlo).
Oggi stavo lavorando su F29 e ci ho fatto un super-aggiornamento (circa 1300 pacchetti), dato che avevo rinviato tutte le operazioni sul sistema per parecchi giorni. Mentre operava, continuavo a lavorare senza problemi in un’altra schermata (Desktop 2: ne ho messi 4 – ah, dimenticavo: utilizzo KDE). Poi mi sono fermato per svolgere altre faccende e, vista l’entità dell’upgrade, ho pensato che fosse meglio riavviare.
Dovete sapere che nel mio Grub ha la priorità F30, cioè per far partire la 29 devo selezionare un’opzione che non è quella di default (ha fatto tutto da solo il sistema quando ho installato la 30, e siccome è una soluzione pratica, che da solo non avrei saputo costruire, l’ho lasciata così).
Essendomi allontanato dalla macchina, quando è ripartita si è avviata la 30.
Insomma, quando sono tornato a sedermi, sullo schermo nero campeggiava una scritta che diceva che il sistema era in

Subito dopo riportava alcune operazioni da compiere: digitare la password di root (infatti non ho attivato sudo), oppure i comandi

journalctl -xb (per i log di sistema) reboot default (dal significato piuttosto ovvio)
Con il tag -xb ho visualizzato quello che ha fatto il sistema, ma non sono riuscito a ricavare nessuna informazione utile dalle migliaia di stringhe (colpa mia, ovviamente: magari c’è qualcosa ma non lo so vedere…).
Se riavvio, la situazione si ripresenta identica, quindi non so come uscirne e ripristinare il funzionamento corretto di Fedora 30, che non mi aveva mai dato problemi e utilizzavo ogni tanto (i dati sono salvati in un altro disco rigido e non sono distinti fra le due versioni).

HELP !?!

Non ho capito, l’emergency mode te la da la f30, che non e’ quella che avevi aggiornato pero’, corretto?
Prima di fare il mega aggiornamento della f29, sei sicuro che la f30 boot-asse correttamente? In modo da escludere l’aggiornamento dall’equazione magari.

Probabilmente hai aggiornato grub2 di f29, che ha fatto un refresh dei sistemi operativi (puoi controllare quali pacchetti hai aggiornato sulla f29 con ‘dnf history info last’ o ‘dnf history info NUMERO’).
Utilizzando altri kernel di f30 al boot, riesci ad entrarci?

Anzitutto grazie, bebo_sudo, per l’interessamento.

Poi vado con ordine:

Sì, esatto.

Sicurissimo, non mi aveva mai dato problemi dopo l’installazione.
Ma a quale ‘equazione’ ti riferisci?

Questa mi sembra una buona ipotesi (ma cosa ci devo fare?):

mentre questa è pessima [quote=bebo_sudo](puoi controllare quali pacchetti hai aggiornato sulla f29 con ‘dnf history info last’ o ‘dnf history info NUMERO’).[/quote]
Infatti (1) a cosa mi serve controllare i pacchetti aggiornati (che erano più di mille, tra l’altro) ? Invece ritengo sia meglio sapere esattamente cosa occorre trovare, per non vagare a vuoto tra centinaia di righe di programma.

Ci sono quattro opzioni: kernel 5.2.18, oppure 17 oppure 15, più il recovery. Bene, qualunque di questi seleziono per avviare, finisce sempre nella stessa schermata nera con le scritte di cui al mio post #1
:frowning:

Precisazione tecnica: sia in F29 che in F30 ho preferito fare un’installazione “vecchio stile”, cioè SENZA volumi logici e con le classiche partizioni (root, boot, home, swap).
Lo scrivo perché ho letto qui su Fedora Online un lungo thread sul medesimo problema, ma con gli LV, appunto, che ho sempre scartato.

Prendila come una licenza poetica :wink:

ritengo sia meglio sapere esattamente cosa occorre trovare, per non vagare a vuoto tra centinaia di righe di programma.[/quote]
Si stava parlando di grub, mi sembrava chiaro qual’era il programma da controllare.

# dnf history info NUMERO |grep grub

Bene. LVM per installazioni “normali” e’ comunque un overkill.

Invece, prima di arrivare all’emergency mode, noti nessuna riga strana? Tipo qualcosa relativo a fsck?

Inoltre, quando arrivi alla schermata di emergency, diventa root, e scrivi:

# journalctl -b -g error

Che tipo di errori riporta?

scusa la “latenza”, ma il PC mi serve anche per lavorare (con la F29, che sto utilizzando anche qui), quindi finché non concludo certe cose, non posso switchare a F30 (e meno male che sono su due SSD distinti!).

In generale, credo che tu sia sulla buona strada.
In dettaglio, il comando # dnf history info NUMERO | grep grub non restituisce nulla, qualunque sia il numero che inserisco al posto della VARIABILE (ho provato con 3, 10 e 100).
Prima di arrivare all’emergency mode, non vedo nulla relativo a fsck, mentre ho dovuto aggiungere un tag more al comando # journalctl -b -g error perché l’output è molto lungo.
Comunque ci sono almeno tre montaggi falliti, di cui riporto le stringhe:
(1) failed to mount home/Aiace/dati, che è una cartella creata per accedere rapidamente alle varie sottocartelle Documenti, Immagini, Musica ecc. e perciò inserita anche in etc/fstab.
A questo primo errore seguono 4 coppie di stringhe identiche, di cui trascrivo pazientemente qui solo la prima:
1.1. ACPI BIOS Error (bug) : Could not resolve symbol _SB.PCIO.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20190509/psargs-330)
1.2.ACPI Error: Aborting method _SB.PCIO.SAT0.SPT4._GTF due to previous error (_SB.PCIO.SAT0.SPT4._GTF) (2019050/psparse-529)

(2) lpc-ich Resource conflict(s) found affecting gpib-ich

(3) l’unità local-fs.target è fallita

Grazie ancora, attendo istruzioni

riapro il thread solamente per spiegare come ho risolto (e ovviamente scrivere RISOLTO nel primo post)

in qualche modo, cioè tramite accenni di bebo_sudo (che ringrazio lo stesso), ma anche dopo aver googlato un po’, ho intuito che il problema derivava dall’aver inserito nel file fstab, che è nella cartella /etc, una riga per avere disponibile immediatamente (cioè alla fine del caricamento di tutti i programmi) anche il disco con i dati, che è fisicamente diverso da quello sul quale è installato il sistema operativo.

Poiché l’avvio del sistema si interrompe e nelle indicazioni fornite a schermo, cioè nell’ambiente console, c’è la possibilità di entrare come root (digitando la password relativa), ho fatto proprio questo, poi ho aperto col semplice editor nano il file /etc/fstab, ho commentato la riga suddetta mettendoci un asterisco davanti, e ho salvato e chiuso il file.
Poi ho lanciato il comando

systemctl daemon-reload

seguendo il suggerimento fornito proprio dal sistema all’apertura del file in questione, e in ultimo ho riavviato tutto con un bel

reboot :smiley:

E così sono rientrato qui, trovandomi la bellezza di 346 aggiornamenti da fare, dato che era passato quasi un mese… Fatto questo, passerò alla 31

Un saluto a tutti e buon lavoro