Kim Possible Italia – un sito per Kim & Ron © 2008-2023

Cultura & Studio del Disney cartoon Kim Possible, su piattaforma Wordpress html5

Problema di avvio lento di Grub 2 con Linux (il menu testuale di avvio compare solo dopo tanti minuti di attesa), sistemi gestiti da BIOS

ultimo aggiornamento 7/2/2023

 

Oggetto della guida

La casistica in questione riguarda la problematica per cui all’avvio del PC, dopo i messaggi del BIOS, il menu di Grub 2 (in seguito denominato semplicemente Grub) compare dopo parecchi secondi o addirittura minuti.

Si premette che la descrizione generale. cosi come delle possibili soluzioni, è volutamente lasciata scarna in quanto prevede di avere una minima conoscenza della materia cosi come il linguaggio è semplicistico lasciando ai siti accreditati approfondire coerentemente i concetti.

Qualche precisazione

In presenza di più S.O. installati sul PC  Grub visualizza il proprio menu di avvio, se ciò non capitasse sarebbe comunque possibile accedere al menù di avvio di Grub (tenendo premuto il tasto MAIUSC durante l’avvio), ma comunque la situazione descritta ora non si applicherebbe coerentemente al caso in esame.  Ciononostante sul come “ottenere” di default la visualizzazione del menu di grub si rinvia a specifico articolo.

Prima di procedere oltre è bene chiarire che non si deve trattare di lentezza di avvio del S.O. in se per se (tale eventualità è trattata in altro articolo), ma proprio il tempo che intercorre fra l’avvio del PC e la comparsa del menu testuale Grub (dove scegliere quale dei S.O. installati avviare).

Possibili cause

Va ricordato che non è possibile diagnosticare perfettamente le ragioni del perchè il sistema sia incorso in questa problematica, cosi come esistono senz’altro diverse possibili soluzioni.  Anzitutto può essere d’aiuto ricordare se il problema è comparso da poco, magari a seguito di alcune operazioni effettuate sul PC, a quel punto si potrebbe ritornare indietro a ritroso per ripristinare un corretto funzionamento del sistema.

Una delle possibili cause potrebbe un “difetto” nel file grub.cfg che si è “ingrossato” troppo.    In fin dei conti grub.cfg è un file di testo che lavora bene rimanendo di dimensioni piccole: basti pensare che di fronte a dimensioni di 300Kb (esatto!!! Kbyte non Mbyte!!!) si sono notate attese di quasi 1 minuto …. raddoppiate di fronte a dimensioni di 1Mb.

Questo “ingrossamento” del file farebbe si che il Grub si avvii correttamente (lo schermo rimane nero o al massimo appare un cursore lampeggiante per qualche secondo), ma che solo dopo alcuni interminabili minuti compaia il famigerato menu di avvio con l’elenco dei S.O.

Un esempio “reale” pour parler

Il perchè ciò avvenga è altrettanto ipotetico,  una causa di questo tipo può verificarsi, ad esempio, se sono installate diverse distro Linux sul medesimo PC ove quindi il Grub venga installato in ognuna, più raramente dovrebbe verificarsi con la presenza di solo una distro Linux ed una Windows

a) immaginando 3 distro Linux (A, B, C) installate sul PC  in cui “A”  il sistema di default e “B”  e “C” gli altri,  col comando update-grub (anche update-grub2) viene preparato un file che contiene le indicazioni per avviare ogni S.O.    Qualora questo update venga fatto su ogni S.O. si avrà un nuovo .cfg e alla fine l’ultimo .cfg finirà per contenere le informazioni raccolte da ognuno in modo ricorsivo…

b) si noti che invece lanciando il comando grub-install viene definito il S.O. di default,  è chiaro che l’ultimo da dove viene avviato il comando diventa il sistema default;  nell’esempio perchè il sistema default sia “A” è evidente che il grub-install sarà stato lanciato per ultimo da quel S.O….

c) in teoria questa eventualità d’uso di Grub è però prevista e non dovrebbe causare simili problematiche,  quindi uno dei motivi potrebbe derivare da qualche “smanettamento” solo se improprio, in quanto tale nell’accezione stessa del termine (https://www.treccani.it/vocabolario/smanettare/)

Motivi a parte… e ora?

Come anticipato si vuol parlare volutamente in maniera semplicistica, rimandando a siti accreditati l’approfondimento della materia (a fondo pagina si trovano fonti specifiche sull’argomento).

Grub inserisce nel S.O. una cartella (generalmente in Linux è /boot) che contiene tra le altre una minisistema di avvio che attraverso un comando specifico prepara il grub.cfg che di fatto è un file di testo con tutte le informazioni utili per avviare i singoli S.O. presenti sul PC. Tale file viene letto da Grub e compone il  menu che compare come schermata di avvio.

Questo file grub.cfg non viene modificato a mano, ma è generato ex-novo e/o modificato dal comando update-grub (o anche detto update-grub2).

In particolare (con distro Linux) ad ogni aggiornamento di Kernel (e/o altro) viene inviato il comando update-grub che ricompila il file .cfg e ciò come si diceva potrebbe contribuire alla generazione della problematica osservata.

Riducendo ai minimi termini i concetti basi, Grub “lavora” avvalendosi di alcuni moduli: il file /etc/default/grub e le due cartelle grub e grub.d

In particolare la cartella grub.d contiene tutti i file che indicano a Grub come deve preparare il menu di avvio;  questi file vengono autogenerati all’installazione e vengono anche definiti script.  Di fatto per funzionare devono essere per Linux degli eseguibili (comando chmod +x),  qualora venga tolto l’attributo con chmod -x il file rimane presente (per poterlo usare in futuro), ma non viene “usato” da Grub per preparare il file .cfg

Un esempio della cartella grub.d è l’immagine sotto

Schermata di cartella /etc/grub.d

In particolare i file con prefisso 10 si occupano di far generare a Grub le voci per il proprio S.O.  mentre il file 30_os-prober si occupa di andare alla ricerca di altri S.O. presenti nelle partizioni e/o dischi.

Il file grub.cfg cosi generato, se letto con un editor,  si presenta con delle sezioni separate (ad esempio  ### BEGIN /etc/grub.d/00_header ###  , ### BEGIN /etc/grub.d/10_linux ###  e   ### BEGIN /etc/grub.d/30_os-prober ###)    al cui interno sono presenti appunto le voci generate dai singoli file sopra.

Ecco che quando update-grub comincia la ricerca dei S.O. installati se “incontra” altri S.O. Linux, dovrebbe solo “pescare” le voci di avvio direttamente nei loro grub.cfg (specificatamente nella sezione 10_______ del file medesimo)  ed in difetto ricostruire le voci da solo (e qui potrebbe essere la causa del rallentamento in oggetto).    Leggendo infatti il file grub.cfg ci si accorgerà che è diviso in sezioni proprio legate rispettivamente ad ognuno di questi file in grub.d

 

Una possibile soluzione 1

Rimanendo nel precetto dei classici “rimedi della nonna”, se ci si trovasse di fronte ad un PC con diversi S.O. Linux installati ed improvvisamente il tempo di attesa per vedere comparire il menu d’avvio di Grub fosse diventato estenuante, si potrebbe provare con una soluzione drastica e non perfetta quanto però probabilmente efficace.

Nel descrivere la soluzione_1 si tiene presente la casistica elencata nel capitolo esempio “reale” pour parler, ovvero un S.O. Linux “A” di default (quello che parte in  automatico all’accensione del PC)  e altri due S.O. Linux “B” e “C”.

La soluzione_1 in esame lascerebbe in mano alla SOLA distro Linux di default “A” il compito di cercare gli altri S.O. installati con la funzione os-prober  mentre le altre distro si limiterebbero a creare le voci cercando SOLO al loro interno.    Questo dovrebbe far si che il Grub  della distro “A” vada a leggere SOLO il file interno generato dalle altre distro che non hanno cercato che non se stesse,  evitando l’ingrossamento del file .cfg   e quindi il rallentamento lamentato ad inizio guida.

Qualora ci fosse un S.O. Windows (non previsto nella casistica) esso non verrebbe toccato da alcuna modifica (e verrebbe trovato dal Grub ove sia attivo lo script  os-osprober).

Come sempre indispensabile prima di procedere è fare un backup da poter usare in caso di problemi ed avere pronta una Live Linux che tra l’altro permette di ripristinare il Grub in maniera piuttosto semplice (seguendo ad esempio la guida wiki ubuntu a fondo pagina).

0) anzitutto verificare di trovarsi nella condizione di grub.cfg “ingrossato” esageratamente, per farlo basta andare a vedere la dimensione del file medesimo

0-bis)  avere una distro linux live funzionante pronta all’uso in caso di problemi (nel caso è possibile seguire le info wiki di ubuntu in calce)

1) accendere il PC e scegliere di avviare la distro non di default “B”

2) nella cartella /etc/grub.d  togliere l’eseguibile al file ____os-prober  con il comando chmod -x _____os-prober

3) lanciare update-grub e se tutto funziona correttamente, si noterà nel terminale che Grub ha trovato solo i kernel del S.O.  “B” e non gli altri

4) uscire dal sistema “B” con il comando di arresto del PC

5) accendere il PC e scegliere di avviare la distro non di default “C”

6) nella cartella /etc/grub.d  togliere l’eseguibile al file ____os-prober  con il comando chmod -x _____os-prober

7) lanciare update-grub e se tutto funziona correttamente, si noterà nel terminale che Grub ha trovato solo i kernel del S.O.  “C” e non gli altri

8) uscire dal sistema “C” con il comando di arresto del PC

9) accendere il PC e scegliere di avviare la distro di default “A”

10) NON AGIRE assolutamente sugli scritp grub.d del sistema Linux di default

11) lanciare update-grub e se tutto funziona correttamente, si noterà nel terminale che Grub trova sia i propri kernel che quelli delle altre distro Linux installate.   Controllare che questo passaggio si concluda correttamente perchè esso garantisce il corretto riavvio del PC. 

12) nella cartella di Grub (generalmente /boot/grub) verificare che il file grub.cfg sia tornato di dimensioni “umane” di pochi Kb

13) riavviare il PC per testare che il problema oggetto della guida si sia risolto

.

Altra possibile soluzione 2

Questa è ancor più semplicistica e sebbene prove empiriche indichino che dopo due anni di applicazione non vi siano più stati più “rallentamenti” di Grub (ed i vari S.O. hanno lavorato senza alcun problema sia in aggiornamento che uso), la controindicazione rilevata in questa soluzione è la perdita delle voci specifiche relative ai S.O. non di default.

Nel descrivere la soluzione_2 si tiene presente la casistica elencata nel capitolo esempio “reale” pour parler, ovvero un S.O. Linux “A” di default (quello che parte in  automatico all’accensione del PC)  e altri due S.O. Linux “B” e “C”.

Come sempre indispensabile prima di procedere fare un backup da poter usare in caso di problemi ed avere pronta una Live Linux che tra l’altro permette di ripristinare il Grub in maniera piuttosto semplice (seguendo ad esempio la guida wiki ubuntu a fondo pagina).

0.2) anzitutto verificare di trovarsi nella condizione di grub.cfg “ingrossato” esageratamente, per farlo basta andare a vedere la dimensione del file medesimo

1.2) qualora sia cosi, procurarsi una Live di Linux necessario per i ripristini di emergenza del Grub (nel caso è possibile seguire le info wiki di ubuntu in calce) ed anche più comoda per attuare le procedure

2.2) avviare la Live Linux ed individuare per ogni singolo S.O. Linux la cartella che contiene il minisistema Grub (generalmente /boot/grub)

3.2) lasciare inalterata la cartella di Grub del S.O. di default “A”

4.2) nell’altro S.O. Linux secondario (“B”)  rinominare SOLO la cartella di grub presente in boot (es: grub diventa grub-cartella-backup); fare altrettanto con il S.O.  “C”

5.2) uscire dalla Live Linux con il comando d’arresto PC e rimuovere la Live

6.2) accendere il PC e avviare il S.O. di default

7.2) rinominare il file grub.cfg della cartella /boot/grub.cfg   (es: grub.cfg diventa grub.cfg.old)

8.2) lanciare il comando update-grub (o update-grub2) per preparare il file grub.cfg

9.2) verificare visivamente che nella cartella di boot/grub che il file grub.cfg appena creato sia di dimensioni nettamente inferiori a quello rinominato al passo 7.2)

10.2) ravviare il PC e stavolta il menu di avvio di Grub dovrebbe comparire con tempi di attesa “umani”, purtroppo il prezzo da pagare (come preannunciato) potrebbe essere che si perda la descrizione coerente degli avvii alternativi dei S.O. secondari (esempio le recovery o altri kernel): necessità comunque rara da doversi applicare rispetto al dover attendere minuti per avviare Grub…

N.B.  In caso non si ottenga il risultato desiderato con il Live Linux si potrà riportare tutto all’origine ripristinando le modifiche fatte al punto 4.2 e poi ripetere  8.2


 

Opportunità per eludere un possibile “difetto” di questa ultima soluzione e poter cosi accedere agli avvi alternativi degli altri S.O.   (escluso quello principale che invece non soffre di alcuna discrasia)

Come anticipato è raro dover accedere a tale funzione avanzata di Grub.     In ogni caso se si clicca sugli avvii avanzati del sistema principale comparirà  il classico elenco di Grub (immagine sotto) dove l’utente può selezionare agilmente le versioni alternative per avviare il S.O.    Generalmente sono due voci per ogni kernel, la prima per fare un avvio generico, l’altra di recovery

Grup-perfetto

Schermata di un Grub “perfetto”

 

Come anticipato a seguito dell’applicazione della  modifica alla soluzione 2, potrebbe accadere che per i S.O. secondari Grub restituisca un elenco di voci, nell’esempio ben tredici!   Con voci che appaiono tutte uguali e generiche (e non come le 4 sopra).      Ciononostante Grub ci ricorda (evidenziato in foto con elisse rosso) che cliccando con il tasto “e” si potranno visionare singolarmente le voci e trovare le corrispondenti linee di comando per un avvio generico o recovery e di quale kernel.

Grub-modificato

Schermata di Grub “modificato”

 

Quindi  basterà  selezionare una delle tredici voci dell’esempio sopra  e per ognuna cliccare sul  tasto “e”  per vedere apparire la descrizione del comando.
Quando verrà individuata una descrizione simile a quella dell’immagine sotto (generalmente è relativa all’ultima delle voci o una di esse), si saprà ad esempio che essa avvia il S.O. in forma “generica” con un kernel (in questo caso 5.4.0-91)

Grub con tasto e

Grub con tasto e


Appendice alla soluzione 1

Per chi volesse approfondire ci sono due programmi che permettono facilmente di avere alcune informazioni
Sono boot-script-info e grub-customizer dai repository ufficiali

Si ricordi che l’esempio prevedeva la presenza di 3 distro-linux installate su un medesimo hard disk ovviamente rispettivamente su 3 partizioni specifiche.     Il Sistema Operativo “A” è quello di default, ovvero che parte in automatico e si trova in prima fila nel menu avvio di grub; gli altri due S.O. sono “B” e “C”

Dopo l’applicazione della soluzione_1 utilizzando grub-customizer dal Sistema “A” si ottiene una schermata simile

 


Ripristino di emergenza di grub (testo estratto da wiki.ubuntu-it.org a cui si rimanda)

In ogni caso la Live Linux che in premessa si deve SEMPRE avere a portata di mano,   permetterà anche di installare Grub ex-novo nel S.O. di default che negli altri e generare un nuovo grub.cfg per ognuno di essi (che conterrà anche i sottomenu).

— inizio procedura di emergenza per il S.O. default “A” —

Avviare Ubuntu in sessione live.  Una volta caricato il sistema, individuare la partizione sulla quale è installato Ubuntu di default che nel caso si ipotizza /dev/sda1

Montare la partizione sulla quale risiede il sistema. Da terminale digitare:

sudo mount /dev/sda1 /mnt

Montare il resto dei dispositivi con il comando:

for i in dev proc sys; do sudo mount --bind /$i /mnt/$i; done

 

Eseguire il chroot con il comando:

sudo chroot /mnt

In questa maniera si sta “lavorando” sulla distro installata e non la live

Per installare Grub 2 nel MBR, digitare nel terminale il seguente comando NON UTILIZZANDO il numero della partizione, ma solo la radice :

grub-install /dev/sda   
update-grub2

Se si ricevono errori è possibile riprovare con il comando:

grub-install --recheck /dev/sda

In ogni caso il comando grub-install farà diventare di default la distro in cui si è in chroot

Uscire dal chroot premendo la combinazione di tasti Ctrl+D o eseguendo il comando:

exit

Smontare tutti i dispositivi digitando:

for i in /dev /proc /sys /; do sudo umount /mnt$i; done

Uscire dalla distro live con il comando arresta PC

—————————————- fine procedura ————————————————

— inizio procedura di emergenza per i S.O. aggiuntivi “B” e “C” ———

Avviare Ubuntu in sessione live.  Una volta caricato il sistema, individuare la partizione sulla quale è installato il S.O. “B” ad esempio /dev/sda5

Montare la partizione sulla quale risiede il sistema. Da terminale digitare:

sudo mount /dev/sda5 /mnt

Montare il resto dei dispositivi con il comando:

for i in dev proc sys; do sudo mount --bind /$i /mnt/$i; done

Eseguire il chroot con il comando:

sudo chroot /mnt

Poi:

update-grub2

Uscire dal chroot premendo la combinazione di tasti Ctrl+D o eseguendo il comando:

exit

Smontare tutti i dispositivi digitando:

for i in /dev /proc /sys /; do sudo umount /mnt$i; done

Riavviare il sistema e riavviare il PC con la Live per ripetere medesima cosa per il S.O. “C”

 


 

argomenti trattati: Grub, Linux, Ubuntu, ripristino, avvio

 

verificare sempre l’indirizzo dei siti internet e/o file scaricati utilizzando un servizio di scansione locale oppure online


Link ai detentori dei marchi citati  https://www.ubuntu-it.org ; https://www.gnu.org/software/grub/ ; https://www.microsoft.com

Fonti:  https://wiki.ubuntu-it.org/AmministrazioneSistema/Grub/Ripristino/BiosMBR ; https://wiki.ubuntu-it.org/AmministrazioneSistema/Grub/Ripristino/Uefi ;  https://wiki.ubuntu-it.org/AmministrazioneSistema/Grub ; https://www.aranzulla.it/come-ripristinare-grub-926842.html ;    https://wiki.ubuntu-it.org/AmministrazioneSistema/Grub/FileCartelle ; https://gparted.org/faq.php

 

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

Sei il visitatore n°


eXTReMe Tracker
Histats