[RISOLTO] Aggiungere generic (di default) in un sistema che ha huge

[gian_d]

Prendo spunto da un argomento che è ancora in corso di discussione e non voglio pertanto incasinare aggiungendoci un caso specifico leggermente OT.

Contesto: uso la current con il solo kernel huge regolarmente aggiornato (attualmente 5.4. e come bootloader grub. Ho sempre usato l'huge quindi non ho alcuna esperienza con il generic. Tuttavia seguendo quella discussione mi sono convinto dell'opportunità di installare il generic, ma nello stesso tempo non vorrei combinare casini che mi costringono a fare troppi salti mortali, dal momento che ancora non ho installato altri sistemi di riserva dai quali modificare eventualmente il grub.cfg in caso di kernel panic.

In sostanza quello che voglio fare è: 1) installare il generic 2) impostarlo con kernel predefinito 3) mantenere l'huge come kernel di riserva 4) riconfigurare grub in modo da avere due opzioni, una che carichi il generic e una che carichi l'huge

Detto questo, da quel che c'è scritto in /boot/README.initrd e da quello che ho letto nel forum, se non ho preso cantonate dovrei procedere in questo modo:

1) disinstallo huge
2) installo generic e lancio mkinitrd
3) devo fare altro?
4) reinstallo huge

Questa procedura dovrebbe fare in modo che il link simbolico /boot/vmlinuz punti al generic. Confermate?

Il passo finale è quello di riconfigurare grub (e questa è una rogna che mi sbrigo da me)

A questo punto, ipotizzando di aver fatto bene le cose dovrei riuscire ad avviare da grub il generic o, in caso di qualche errore, huge come piano B. Ma, in ottemperanza alla legge di Murphy, mettiamo l'ipotesi che mi imbatta in un kernel panic in entrambi i casi. Il piano C è quello di avviare un disco di installazione e caricare il kernel huge della iso per accedere al sistema e riconfigurare grub, sperando che l'errore dipenda da quello, oppure riprovare con le installazioni del kernel (solo generic o solo huge).

In ogni caso, qualsiasi pasticcio abbia combinato, mi servirebbe la conferma sul fatto che posso comunque caricare il sistema usando il kernel di una ISO e poi rimestare come root per rimetterlo a posto, cose che ho già fatto in passato, ma solo con il kernel huge installato.

Grazie per tutti i suggerimenti (compreso eventualmente "lascia perdere i voli pindarici e resta con i piedi a terra")

[conraid]

Basta che installi generic, non c'è bisogno di disinstallare huge.
Di default dovrebbe prendere il generic come link simbolico prencipale.

Se fai casino fai finta di installare e invece di setup monti la partizione e sistemi.
Segui quesfo howto, è per glibc ma è simile la procedura.

https://rlworkman.net/howtos/glibc-recovery

[gian_d]

OK, domani provo. Comunque mi serviva la conferma di poter usare in caso di emergenza il disco di installazione, caricare il suo kernel e montare il sistema installato sull'hardisk. Di solito uso questa via quando non posso accedere dal bootloader, solo che l'ho fatto sempre caricando l'huge della ISO e montando un sistema che contiene l'huge installato. Questo non dovrebbe avere alcun effetto dal momento che l'huge caricato sulla ram è comunque quello della ISO, giusto? Quindi il fatto che ci sia un generic nel sistema dell'hardisk non cambia nulla.

[conraid]

Non cambia nulla, ma nel sistema lascia anche huge, che va anche se hai problemi con initrd.

[joe]

Ma non dovrebbe servire il CD:
- quando appare il menù di grub, muovi la freccia su o giù in modo da fermare il conto alla rovescia.
- poi leggi in basso, vedrai che ci sono le indicazioni: premi "e" per editare la voce che vuoi modificare
- ti si apre la "entry" così come è scritta in grub.cfg
- qui puoi modificarla in particolare cambiare il nome della initrd, se lo avevi messo sbagliato, oppure il nome del kernel da avviare
- quando lanci mkinitrd, magari lo lanci in modo da ottenere in output un nome significativo tipo initrd-generc.img. Così anche gli automatismi di grub-mkconfig la associano a "vmlinuz-generic" (mkinitrd -o /boot/iinitrd-generic.img)

La generazione del grubconfig è una scemata, in questi giorni ho fatto diverse prove è l'avrò rigenerato 1000 volte, l'importante è che ti tieni sempre quello che hai ora funzionante e backuppato.
Col kernel huge non hai problemi di kernel panic all'avvio: è fatto apposta per essere pronto al via, anche se si porta dietro qualche modulo in più.

[gian_d]

Purtroppo usare la console di grub è una mia tara: i problemi riesco a risolverli se ho la possibilità di navigare nel file system, leggere i file di configurazione o usare un comando dalla bash. Il fatto di poter leggere la "entry" non garantisce che io possa individuare l'errore. È per quello che per me è importante avere un ingresso da una porta di servizio più che avere la possibilità di scassinare la porta principale, perché non ne avrei la capacità.
In ogni modo devo decidermi uno di questi giorni a installare un sistema di riserva per lasciarmi aperte queste porte di servizio. Sono mesi che ho cambiato i dischi e ancora sto cazzeggiando con la configurazione del sistema di default.

Comunque, grazie per le dritte, domani vi farò sapere

[gian_d]

Ok, è andato liscio come l'olio. L'unico problema è la schermata di grub.
Ho disattivato 10_linux e ho invece predisposto due file per i rispettivi kernel, 11_generic e 12_huge.
grub-mkconfig li elabora regolarmente e infatti in grub.cfg compaiono due entry, ma nella schermata di grub, poi, appare solo la prima opzione, ovvero il caricamento di generic. Immagino che dovrò cambiare qualche impostazione in /etc/default/grub, probabilmente la variabile di ambiente ${next_entry}. Sicuramente è cambiato qualcosa con l'ultimo rilascio di grub ma non me ne ero reso conto perché finora avevo una sola voce.
Di nuovo, ringrazio per l'aiuto.

[joe]

Posta il grub.cfg così vediamo dove sta l'inghippo e ci capiamo meglio...
Può tornare utile a tutti credo

[gian_d]

ho combinato un pasticcio, adesso ho disinstallato grub e spostato tutti i file, riavvio e riparto da zero

Dai, questa è da manuale del perfetto utonto!
Tralascio il pasticcio che avevo combinato perché non so neppure cosa avevo combinato, sta di fatto che grub-mkconfig non andava più a causa di errori di sintassi, che però saltavano fuori solo se provavo a far leggere uno dei due file (11_generic e 12_huge), mentre la lettura di entrambi i file procedeva correttamente. Da emerito pirla ho disinstallato grub e riavviato con l'intenzione di fare il boot dalla iso.
E qui salta fuori l'ennesimo pasticcio: l'avvio dalla iso non funziona perché avevo lasciato inittab impostato per rc.4: a quel punto, avendo il drive proprietario di nvidia si blocca tutto ma non avevo la possibilità di aprire un terminale con F2 perché la tastiera non rispondeva
Al che ho provato a modificare inittab da una live di ubuntu, peggio che andar di notte: il boot dalla iso mi restituiva comunque un errore su inittab e la tastiera muta.

Alla fine ho temporaneamente risolto facendo un'istallazione minimale di un'altra slackware su una partizione libera per configurare un grub sul mbr di un altro disco. Finalmente sono riuscito ad avviare la slack di default con il kernel generic. Adesso reinstallo grub e vedo se riesco a venirne a capo. Che pirla, ci ho perso tutta la mattinata per una boiata

[gian_d]

Scovato l'inghippo, si trattava di un errore sistematico in entrambi i file 11_generic e 12_huge, la mancata chiusura con un apice della stringa nel parametro $menuentry_id_option:

Codice: Seleziona tutto

menuentry bla bla $menuentry_id_option 'gnulinux-advanced-6ef306d8-fa6f-41a6-a08c-5afc701790cb {

Questo doppio errore non veniva rilevato giustamente da grub-mkconfig, però veniva generato un grub.cfg che in sostanza imposta un'unica voce del menu, trattando come stringa l'intero blocco di 11_generic e della parte iniziale del file 12_huge.
Questo spiega anche perché grub-mkconfig generava un errore di sintassi abilitando uno solo dei due file. Mannaggia, un sacco di tempo perso per una disattenzione del piffero... :-\

[gian_d]

Ne approfitto per fare un'ultima domanda: con l'aggiornamento del kernel devo rilanciare mkinitrd. L'operazione sovrascrive senza problemi il vecchio initrd oppure è opportuno rimuoverlo prima di lanciare il comando?

[conraid]

Ne approfitto per fare un'ultima domanda: con l'aggiornamento del kernel devo rilanciare mkinitrd. L'operazione sovrascrive senza problemi il vecchio initrd oppure è opportuno rimuoverlo prima di lanciare il comando?

Lo riscrive se usi lo stesso nome. Di default è initrd.gz ma appunto così ti ritrovi con kernel che non hanno i loro moduli.
Io genero quindi initrd-versione.gz e grub li trova tranquillamente, poi faccio un link simbolico per initrd.gz in modo che prenda i link simbolici del kernel.
Mi spiego.
Oggi che è uscito 5.4.10 (o quel che è vado a memoria) avrò

Codice: Seleziona tutto

initrd-5.4.10.gz
initrd-5.4.8.gz
initrd.gz -> initrd-5.4.10.gz
vmlinuz-huge-5.4.10
vmlinuz-generic-5.4.10
vmlinux-huge -> vmlinuz-huge-5.4.10
vmlinux-generic -> vmlinuz-generic-5.4.10
vmlinux -> vmlinuz-generic-5.4.10
vmlinuz-huge-5.4.8
vmlinuz-generic-5.4.8

e grub mi crea le voci per

Codice: Seleziona tutto

vmlinuz-huge-5.4.10 con initrd-5.4.10.gz
vmlinuz-generic-5.4.10 con initrd-5.4.10.gz
vmlinux-huge con initrd.gz
vmlinux-generic con initrd.gz
vmlinuz-huge-5.4.8 con initrd-5.4.8.gz
vmlinuz-generic-5.4.8 con initrd-5.4.8.gz

dei file in grub ho solo 10_* di default

ho lasciato i link simbolici anche se son doppioni così se mi dimentico di rigenerare grub dopo l'upgrade funziona ugualmente con il nuovo kernel. Non faccio upgrade (i vecchi kernel li tolgo solo quando faccio reboot) perché altrimenti mi da errore in runtime a volte non trovando i moduli giustamente. Ecco perché metto in blacklist i kernel e poi installo con uno piccolo script


uso initrd per huge perché dentro ci sono cose come intel-ucode, e magari puoi metterci cose che ti servono come tastiera italiana, etc...

[gian_d]

Ok, era come pensavo. Per ora ho solo generato il file di default (initrd.gz) a cui punta un link simbolico (initrd-generic) ma al prossimo aggiornamento ho intenzione di generare un initial ramdisk che riporti il numero della versione del kernel, anche se non uso differenti versioni del kernel e non ho kernel ricompilati. All'inizio mi capiterà di sicuro di dimenticarmi qualche volta di rigenerare l'initrd, è una questione di abitudine, perciò mettere il numero è buona cosa per non farmi sviare da eventuali errori.

Tuttavia sto pensando di fare uno script da lanciare ogni volta che c'è un aggiornamento e che mi faccia in concatenazione tutte le operazioni: l'upgradepkg dei rilasci del kernel, la generazione dell'initrd, la ricompilazione dei moduli di nvidia e virtualbox.

[gian_d]

Dimenticavo: lo script 10_linux lo trovo utilissimo come test, però non mi piace il fatto che genera una caterva di entru e sottomenu, da anni mi sono abituato ad avere dei menu minimali, perciò preferisco predisporre dei template statici e disabilitare 10_linux. Non mi hanno mai dato problemi, a parte la disavventura di oggi, e alla fine ho preso atto che con il ricorso a link simbolici non c'è bisogno aggiornare grub se non ad ogni evento straordinario

[conraid]

Io ho proprio uno script che fa tutto, installa i nuovi kernel, crea initrd, fa un link simbolico e poi crea grub.cfg

Quando poi riparto e va tutto ok con il nuovo kernel (a volte è capitato che la wifi non andasse, i tasti luminosità, etc...) lancio uno script che disinstalla i vecchi kernel e ricrea grub.cfg

Ma ora non ho il pc linux per mandartelo