slacky.eu

Come da titolo sul mio PC attualmente ci sono: Win 10, Debian 11.1 e Slackware 64 Current. Il Grub della Debian avvia tutti sistemi operativi, solo che ho visto che la Current sta aggiornando il kernel di frequente però ho paura che se aggiorno il kernel della Slackware 64 poi non si avvia più con il grub della Debian che rispetto alla Slackware avvia anche Win. Come posso fare per fare in modo che il Grub della Debian continui a gestire l' avvio dei tre sistemi operativi aggiornando il kernel? Ho letto sul forum che un' altro frequentatore del forum si era creato dei file di avvio personali ma la mia conoscenza di Grub è quasi zero.

Il problema non si pone se in grub.cfg l'avvio del kernel è basato su collegamenti simbolici. In questo caso è infatti sufficiente aggiornare i collegamenti simbolici ad ogni aggiornamento del kernel senza dover modificare il grub.cfg.

gian_d ha scritto: ↑

dom 2 gen 2022, 13:07

Il problema non si pone se in grub.cfg l'avvio del kernel è basato su collegamenti simbolici. In questo caso è infatti sufficiente aggiornare i collegamenti simbolici ad ogni aggiornamento del kernel senza dover modificare il grub.cfg.

Se sei interessato posso mettere nero su bianco la configurazione che adotto io.

Confermo anch'io, forse hal aveva letto qualche mio precedente tentativo di configurare grub in modo semplice per le mia necessità:
1. files di configurazione grub posizionati in partizione dedicata (non è questo l'argomento del topic però)
2. grub.cfg contenente link simbolici generici piuttosto che files riferiti alla versione del kernel in uso.
3. in /boot il file del kernel "vmlinuz-ecc-ecc-versione" deve avere il suo corrispondente link simbolico "vmlinuz", questo nome deve essere lo stesso richiamato nel grub.cfg


Nella pratica:
- aggiorni il kernel quando fai l'aggiornamento della current
- l'operazione se non ricordo male dovrebbe automaticamente cancellare i vecchi link simbolici che puntavano al vecchio kernel e ricrearne di nuovi aventi stesso nome (vmlinuz), ma che punteranno alla nuova versione installata del kernel (vmlinuz-generic-5.10.4 nel mio caso specifico).
- alla fine in boot avrai una cosa del genere Spetta, nel mio caso c'è un problemino cl kernel huge: il collegamento vmlinuz-huge punta ancora al vecchio 4.4.240. D'altra parte non ho installato il kernel huge 5.10, quindi è anche giusto così alla fine, va be' comunque la cosa funziona perché il kernel huge non ha bisogno di intrd. Ora non ricordo perché ho quella situazione...
Ad ogni modo quello che conta è che ho installato il vmlinuz-generic-5.10.4 e ho il suo link simbolico vmlinuz.
In allegato ho messo il grub.cfg. Ne riporto solo un pezzo: La cosa importante relativamente alla versione che viene aggiornata è la creazione dell'initrd.
Creo la initrd relativa l nuovo kernel, nel mio caso sopra l'avevo chiamata initrd-5.10'.4.img.
E creo anche il suo link simbolico initrd-generic.img.
Nel config di grub ci sono in nomi dei link simbolici, svincolati dalla versione del kernel.
In particolare grub cercherà di avviare "vmlinuz-generic" usando come root la partizione /dev/sda3. E appoggiandosi all'initrd chiamata initrd-generic.

Quando aggiornerò il kernel "generic", dovrò ricreare la initrd e la collegherò sempre al nome initrd-generic.
Farò anche attenzione che il collegamento vmlinuz-generic punti al nuovo kernel che avrò installato.
In questo modo non dovrò ritoccare il grub.cfg.

Fin qui tutto liscio.
Il problema è che se tu dovessi aggiornare qualcosa in debian e lanciare disgraziatamente un grub-update o come si chiama in debian il comando per rigenerare grub.conf.
Allora potrai avere qualche problemino perché gli automatismi di grub possono incasinare la situazione col risultato che potresti on riuscire ad avviare slackware.
Ecco perché mi ero creato la configurazione sopra in modo "custom" e più che altro "statico", in modo che una volta scritto lo script di grub piazzato in /etc/grub.d/42_slackware, fine della storia. Ovviamente avevo anche disattivato gli altri script di grub tofliendo loro il tag di esecuzione con "chmod -x". Ho lasciato solo quello di intestazione "00_header". Questa roba nel tuo caso dovrai farla sul sistema da cui aggiorni la configurazione di grub cioè Debian, però dovrai adottare una soluzione simile anche per Debian usando anche lì dei link simbolici.

Cioè, ricapitolando: se sai quali sistemi hai sul disco e come devono essere avviati, meglio creare script più rigidi fati a mano piuttosto che lasciar fare a os_probe o altre diavolerie che richiama grub.

Se non sei capace di scrivere gli script a mano, in realtà puoi scopiazzare dal tuo grub.cfg attuale se è funzionante. Io avevo fatto così.
Poi quando aggiorni qualcosa sia da debian che da slackware, ti sistemi i link simbolici, mentre le configurazioni di grub non le toccherai mai più, a meno di altre necessità.

Non ricordo bene, ma avevo notato anch'io un problema del link simbolico vmlinuz con il kernel huge. Infatti per non lasciare nulla al caso, con lo script che ho fatto elimino ad ogni aggiornamento tutti i link simbolici e li ricreo con i target corretti.

Per quanto riguarda grub concordo sull'opportunità di preparare dei template ad hoc da mettere in grub.d: grub rileva la presenza dei sistemi operativi installati nelle varie partizioni e costruisce le relative entry, però procede per tentativi e crea un lungo elenco di entry taroccate. Ad esempio, per la Slackware ne fa parecchie, almeno 5 o 6 e non è detto che funzionino. Ma questo problema esiste in generale con tutte le versioni di grub distribuite dalle varie distro.

Il mio consiglio è di usare il grub della Debian con l'accortezza di avere in grub.d il template predisposto per la Slackware, se gli aggiornamenti della Debian sono eseguiti in automatico. In questo modo si evitano sul nascere una serie di problemini che salterebbero fuori invece con l'uso del Grub della Slackware: le entry per i sistemi Debian like sono un po' più complicate di quelle per le installazioni di Slackware.

Il kernel huge che ho io è il vecchio 4.qualcosa, mentre il 5.10 in realtà è un ricompilato da me più di recente utilizzando il config del generic. Non è se ricordo bene il generic di Pat che per la stabile è sempre il 4.qualcosa...
Infatti: Probabile che io abbia compilato il kernel 5.10 partendo da slackbuild della current o comunque da quel config. non ricordo di preciso.
Ai fini del nostro discorso il vmlinuz puoi puntarlo al kernrel che vuoi. Nel mio caso in realtà non viene poi usato nel grub.cfg, al suo posto ho distinto vmlinuz-generic e per l'huge vmlinuz-huge. L'importante è che poi si configuri grub in modo coerente insomma, deve richiamare i link giusti in base a quello che si vuole avviare, tutto lì.

A dirla tutta, il mio è anche non bellissimo tra le altre cose perché la initrd col kernel huge non serve e quella riga andrebbe anche tolta. Era saltata fuori perché avevo fatto uno script che generava a sua volta gli script di grub... Insomma era un po' un esperimento che se non ricordo male avevo riportato anche qui sul forum, ma è passato troppo tempo per ricordarmi. Segno questo che con la trovata dei link simbolici, la configurazione di grub non la tocchi più in caso di upgrade del kernel, tutto sommato mi sembra una soluzione onesta.

La configurazione di grub per debian può anche essere più elaborata ma dopo tutto dovrebbe creare alla fine un grub.cfg sempre e comunque fatto e finito. Una soluzione semplice, se non serve avere configurazioni più complicate come quelle che crea grub in automatico, è prendere spunto da quella automatica per buttarne giù una statica e andare di link simbolici anche su Debian. L'aggiornamento automatico installerà anche lì kernel initrd ecc ecc, ma a valle di quella situazione si può sempre intervenire per creare il suoi bravo set di collegamenti simbolici e avviare il sistema col vecchio grub.cfg.
Sempre che nello specifico di Debian non vi siano altri automatismi che poi possano aspettarsi una situazione diversa. Sì Debian non è Slackware, ma credo che ci si possa comunque lavorare per gestire in modo comodo il multiboot.


PS.
Avevo anche messo una partizione con la current e usavo la dir /boot della current per gestire l'avvio col suo /boot/grub/grub.cfg,ecc...
Poi ho tolto la partizione della current e non avviavo più nulla. Ovvio, una svista...
Però dopo quell'inghippo mi sono deciso a creare una piccola partizione ext2 che ospita praticamente il contenuto di /boot/grub, così anche togliendo un eventuale sistema in multiboot, si può sempre avviare da un altro sistema rimanente, in pratica non c'è più un sistema "master" che contiene la configurazione necessaria al "core" di grub, il pezzo eseguibile per capirci, installato in testa al disco o nella partizione EFI.

Grazie a tutti per l' interessamento e le risposte, ora almeno ho le idee un pò più chiare. Visto che ho un kernel huge senza initrd a questo punto posso procedere così: modifico il grub.cfg della Debian in modo che punti ai link simbolici della Slackware (ho comunque visto che ci sono già: vedi sotto): senza fare altro, poi aggiorno il kernel della Slackware e modifico il grub.cfg indirizzandolo ai link simbolici. Dopo di che quando aggiorno il kernel della Debian con il relativo grub.cfg devo rimodificarlo per la parte Slackware facendolo puntare ai link simbolici mentre se aggiorno il kernel slackware non devo fare nulla. Ho capito bene?

Il problema è l'aggiornamento, o meglio la "rigenerazione" di grub.cfg.
Il file in questione di configurazione di grub, non è pensato per essere modificato a mano. L'operazione di rigenerazione che si fa in seguito all'aggiornamento dei kernel se non configurata in modo opportuno adotta degli automatismi che prendono delle iniziative sovrascrivendo la soluzione che avevi predisposto in precedenza, perché appunto il grub.cfg viene rigenerato, cioè proprio sovrascritto e i tuoi link simbolici possono essere ignorati o tenuti in conto dall'automatismo (non so nello specifico) ma accanto a loro ti ritrovi altre 10 voci all'avvio che magari non vuoi.
Questa operazione di rigenerazione puoi anche non farla. Il problema è capire cosa decide di fare Debian quando aggiorni anche i kernel. Non mi stupirei se APT si occupasse anche di lanciare "grub-update", che è un wrapper al nostro "grub-mkconfig".

Questa roba puoi capirla meglio tenendo presente il sistema di funzionamento di grub2.
Molto in sintesi vai a vedere in /etc/grub.d/
ci sono degli script che non fanno altro che generare, proprio scrivendolo, il file di configurazione finale solitamente posto in /boot/grub/grub.cfg.

Se tu modifichi grub.cfg, quando poi fai girare, direttamente o attraverso APT, grub-update, quegli script vengono richiamati e vanno a generare un nuovo grub.cfg che sovrascriverà quello vecchio.
Ecco perché dicevo, prova a vedere se ti ci trovi togliendo tutti gli automatismi dalla configurazione di grub in Debian, andando a modificare i permessi in esecuzione sui files in /etc/grub.d/*. Rendi eseguibile quello di intestazione e basta, poi ti crei un unico script custom scopiazzando dall'attuale grub.cfg, basa la configurazione su link simbolici anche per Debian.

In questo modo quando aggiorni il kernel in debian piuttosto che in slackware, andrai solo a verificare i link simbolici puntandoli ai nuovo kernel. Senza toccare la configurazione di grub. E anche se APT vorrà lanciare grub-update, l'operazione non altererà il grub.cfg.

Non è detto che sia la soluzione migliore, ma sicuramente ti consente di avere più controllo su grub e un menu di boot più ordinato ed essenziale. In ogni caso avere sempre una live testata che funzioni a portata di mano può tornare utile quando si mette mano a queste cose. Se sbagli ad impostare qualcosa, oppure se sbaglia APT a configurare grub, hai sempre una porta di servizio per entrare e rimediare.

hal9000 ha scritto: ↑

lun 3 gen 2022, 18:56

Dopo di che quando aggiorno il kernel della Debian con il relativo grub.cfg devo rimodificarlo per la parte Slackware facendolo puntare ai link simbolici mentre se aggiorno il kernel slackware non devo fare nulla. Ho capito bene?

Una domanda: gli aggiornamenti della Debian vengono fatti in automatico con riconfigurazione automatizzata di grub.cfg? Faccio questa domanda perché ho notato che in Ubuntu grub viene riconfigurato ad ogni aggiornamento del kernel.

Se avviene questo anche con la tua Debian ti consiglio di preimpostare in grub.d un template per la Slackware. In questo modo non dovrai mettere mano a grub.cfg e ad ogni aggiornamento del kernel della Debian la entry per la Slackware viene reimpostata automaticamente senza mettere mano a grub.cfg.
Lo stesso accorgimento vale se fai l'aggiornamento alla bisogna e poi riconfiguri grub (se non ricordo male il comando dovrebbe essere sudo update-grub, che sarebbe equivalente al grub-mkconfig nella Slackware.

Nei limiti del possibile è ragionevole evitare di mettere mano direttamente in grub.cfg: una piccola distrazione può comportare problemi di boot non irreparabili ma sempre rognosi quando capitano.

Per maggiore chiarezza, nella mia macchina, che attualmente ha solo una current installata, ho un grub con tre entry, una per il kernel generic, una per il kernel huge e una per l'interfaccia UEFI. Devo ancora installare una Debian ma per il boot userò sempre il Grub di Slackware perché per me è più familiare.
In grub.d ho personalizzato gli script usati da grub-mkconfig togliendo i permessi di esecuzione a quelli che non mi interessano. La numerazione nei nomi dei file è importante perché definisce la cronologia di esecuzione degli script. Il tutto è come appare in questa immagine:


La prima entry ad essere impostata da grub-mkconfig (= update-grub nei sistemi Debian-like) è quella configurata nello script 11_generic, che ha questo codice: Questo script può essere impostato tale e quale anche in un eventuale grub.d in una distribuzione Debian. Come puoi vedere non c'è nessun riferimento alla versione del kernel perché grub accede al kernel e all'initrd attraverso dei collegamenti simbolici.

Questi collegamenti simbolici vanno reimpostati solo quando aggiorni il kernel nella Slackware, ma il Grub in un'altra distribuzione continuerà a funzionare correttamente senza metterci mano.
Spero di essere stato chiaro

Aggiungo:
se su Debian usate uno script custom per le entry Slackware, disattivate os-prober:

Naturalmente, altrimenti saltano fuori come minimo una decina di entry per la stessa distribuzione!

Grazie per le risposte, quindi se ho capito bene per la Debian: creo qui uno script 11_linux come da esempio di gian_d, tolgo i permessi di esecuzione a 10_linux e 30_os-prober aggiungo a grub e poi per far leggere la nuova configurazione. Stessa cosa anche per Slackware. Il tutto per sicurezza prima di fare i vari aggiornamenti del kernel Slackware.
Piccolo dubbio: il grub di Slackware non legge Win e al momento neanche Debian perchè installata dopo, ma se rigenero ora il grub Slackware andraà a sovrascrivere quello Debian non facendo così partire Win?
Il problema si pone perchè mia mogle usa ancora Win e tutto questo dovrebbe servire a facilitale le cose.

Se devi usare il Grub della Debian, per quale motivo devi rigenerare quello della Slackware?

In ogni modo bisogna fare chiarezza sul cosa intendi per rigenerare.

1) con il comando grub-mkconfig (sottinteso -o /boot/grub/grub.cfg) ciò che hai fatto con la Debian non viene minimamente modificato. Questo comando infatti modifica solo il grub.cfg che si trova nella directory /boot/grub della partizione in cui installata. A meno che non abbia una partizione dedicata /boot/grub che viene montata sia sulla Slackware sia sulla Debian (cosa che sconsiglio assolutamente: questa partizione va montata solo sulla distribuzione di cui si utilizza il boot loader!

2) con il comando grub-install /dev/sd* vai invece a sovrascrivere il mbr o la partizione UEFI (a seconda del tipo di partizionamento che hai fatto). Chiaramente questo comando non devi lanciarlo perché andresti a installare il grub di Slackware al posto del grub di Debian. Naturalmente se hai più di un disco nulla ti vieta di fare l'installazione di due grub, di cui sarà chiaramente attivo solo quello del disco che ha la priorità nella sequenza di boot impostata nel BIOS.

Nella precedente macchina avevo quattro dischi. In quello di default (quello lanciato dal BIOS) avevo installato il grub della Slackware, nel secondo disco c'era invece installato il grub di una Debian.
Questo perché poi copiavo il codice del grub.cfg generato dalla Debian sul template specifico in /etc/grub.d utilizzato per costruire l'entry della Debian sul grub della Slackware.