Non è supportata dalla versione di grub in uso.joe ha scritto:GRUB_DISABLE_SUBMENU=
Considerazioni su Slackware e alternative
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
-
- Iper Master
- Messaggi: 2489
- Iscritto il: gio 10 mar 2011, 9:21
- Slackware: 15.0
- Kernel: 5.15.x-generic
- Desktop: Sway
- Distribuzione: Arch Linux
Re: Considerazioni su Slackware e alternative
-
- Iper Master
- Messaggi: 2489
- Iscritto il: gio 10 mar 2011, 9:21
- Slackware: 15.0
- Kernel: 5.15.x-generic
- Desktop: Sway
- Distribuzione: Arch Linux
Re: Considerazioni su Slackware e alternative
In effetti è un po macchinoso e dipende dalla versione di grub.conraid ha scritto:una cosa che non mi ha mai funzionato è l'ordine di boot, qualsiasi cosa scriva me lo mette poi in ordine alfabetico.
Dalla 2.0x in poi - mi pare - bisogna inserire il valore '$menuentry_id_option' della voce che t'interessa e che trovi nel tuo grub.cfg.
Esempio, se hai
Codice: Seleziona tutto
menuentry 'Slackware-14.2+ GNU/Linux, with Linux huge' --class slackware_14_2_ --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-huge-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68'
Codice: Seleziona tutto
GRUB_DEFAULT='gnulinux-huge-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68'
Codice: Seleziona tutto
submenu 'Advanced options for Slackware-14.2+ GNU/Linux' $menuentry_id_option 'gnulinux-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68' {
menuentry 'Slackware-14.2+ GNU/Linux, with Linux huge' --class slackware_14_2_ --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-huge-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68'
Codice: Seleziona tutto
GRUB_DEFAULT='gnulinux-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68>gnulinux-huge-advanced-36d4156b-6f29-4e2a-8c12-3c54ad3b7c68'
Offtopic: P.s.
Mi sa questo è diventato un topic su grub+slackware
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Sì infatti!
Eh va be', ormai continuiamo pure qui.
Ho deciso che lascio perdere gli automatismi di grub, mi creo un template tipo il 40_custom, anche statico e quando aggiungo un kernel aggiorno il grub.cfg con quello, tanto alla fine non ricompilo kernel tutti i giorni e neanche gli aggiornamenti credo siano troppo frequenti. Sì che sono abituato alla stabile, ma probabilmente anche la current non cambierà kernel tutte le settimane.
Siccome il discorso dell'automatismo non mi spiace comunque, ho indagato un attimo sulla struttura della initrd.
In pratica si può scompattare con cpio e salta fuori il file system della nostra initram.
Tra le varie dir e subdir c'è quella dei moduli del kernel:
Ne segue che data un'immagine initrd, eventualmente scompattata con gzip, possiamo estrarne il contenuto con cpio e valutare a quale versione del kernel appartiene.
Anche il file immagine del kernel, attraverso il comando file riporta la versione:
Concludendo dovremmo essere in grado di trovare i kernel delle varie partizioni.
Così come le eventuali immagini initrd presenti.
Ma soprattutto indipendentemente dal nome che hanno, siamo in grado di stabilire a quale versione del kernel fanno riferimento.
Questo comporta che riusciamo ad associare un certo kernel con una initrd giusta, o almeno coerente con la versione in questione e quindi funzionante... Non è un grosso problema poi se si trattava di un kernel "huge" che non ha bisogno di initrd, comunque non compromette l'avvio del sistema.
Per le partizioni non di sistema, os-prober capisce se c'è installato un sistema sopra, ma poi linux-boot-prober non è abbastanza "furbo" da riconoscere le initrd e associarle al kernel.
Quindi va bene os-prober, per capire su quale partizione si trovano i sistemi in multiboot con quello in uso, però poi servirà un sistema un po' più "attento" per capire cosa c'è nella dir boot di quella/e partizioni.
Per cui non ci sono santi, va montata temporaneamente e analizzata la sua dir /boot trovati kernel e relative initrd.
Infine si "compila" il template 40_custom e si genera poi il grub.cfg.
Capisco che si tratti di una reinvenzione della ruota... Però sembra un po' più rotonda rispetto al probing di grub.
Un sistema del genere permette di ottenere un grub.cfg funzionante in automatico e allo stesso tempo di nominare il kernel e relativa initrd come si vuole, indipendentemente da convenzioni della distribuzione e relativi link simbolici predisposti.
Ci saranno anche controindicazioni immagino
Eh va be', ormai continuiamo pure qui.
Ho deciso che lascio perdere gli automatismi di grub, mi creo un template tipo il 40_custom, anche statico e quando aggiungo un kernel aggiorno il grub.cfg con quello, tanto alla fine non ricompilo kernel tutti i giorni e neanche gli aggiornamenti credo siano troppo frequenti. Sì che sono abituato alla stabile, ma probabilmente anche la current non cambierà kernel tutte le settimane.
Siccome il discorso dell'automatismo non mi spiace comunque, ho indagato un attimo sulla struttura della initrd.
In pratica si può scompattare con cpio e salta fuori il file system della nostra initram.
Tra le varie dir e subdir c'è quella dei moduli del kernel:
Codice: Seleziona tutto
# /bin/ls /tmp/tmp.QrHyF8/lib/modules/
4.4.190
Anche il file immagine del kernel, attraverso il comando file riporta la versione:
Codice: Seleziona tutto
file /boot/*|grep 'Linux kernel'
/boot/vmlinuz-generic-4.4.190: Linux kernel x86 boot executable bzImage, version 4.4.190 (root@hive64.slackware.lan) #2 SMP Mon Aug 26 15:58:55
CDT 2019, RO-rootFS, swap_dev 0x4, Normal VGA
/boot/vmlinuz-huge-4.4.190: Linux kernel x86 boot executable bzImage, version 4.4.190 (root@hive64.slackware.lan) #1 SMP Mon Aug 26 15:57:46
CDT 2019, RO-rootFS, swap_dev 0x7, Normal VGA
Così come le eventuali immagini initrd presenti.
Ma soprattutto indipendentemente dal nome che hanno, siamo in grado di stabilire a quale versione del kernel fanno riferimento.
Questo comporta che riusciamo ad associare un certo kernel con una initrd giusta, o almeno coerente con la versione in questione e quindi funzionante... Non è un grosso problema poi se si trattava di un kernel "huge" che non ha bisogno di initrd, comunque non compromette l'avvio del sistema.
Per le partizioni non di sistema, os-prober capisce se c'è installato un sistema sopra, ma poi linux-boot-prober non è abbastanza "furbo" da riconoscere le initrd e associarle al kernel.
Quindi va bene os-prober, per capire su quale partizione si trovano i sistemi in multiboot con quello in uso, però poi servirà un sistema un po' più "attento" per capire cosa c'è nella dir boot di quella/e partizioni.
Per cui non ci sono santi, va montata temporaneamente e analizzata la sua dir /boot trovati kernel e relative initrd.
Infine si "compila" il template 40_custom e si genera poi il grub.cfg.
Capisco che si tratti di una reinvenzione della ruota... Però sembra un po' più rotonda rispetto al probing di grub.
Un sistema del genere permette di ottenere un grub.cfg funzionante in automatico e allo stesso tempo di nominare il kernel e relativa initrd come si vuole, indipendentemente da convenzioni della distribuzione e relativi link simbolici predisposti.
Ci saranno anche controindicazioni immagino
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: Considerazioni su Slackware e alternative
Non so se ho capito qual è il problema a cui ti riferisci. Per ordine di boot ti riferisci forse all'ordine con cui le voci vengono elencate nella schermata di Grub?conraid ha scritto:Ecco, una cosa che non mi ha mai funzionato è l'ordine di boot, qualsiasi cosa scriva me lo mette poi in ordine alfabetico. Ma avendo "saved" mi ricorda l'ultima scelta e quindi ok.
Se è quello, la soluzione è semplicissima: l'ordine è definito dal numero progressivo con cui inizia il nome del file eseguibile (con l'attributo x, per intenderci) presente in grub.d.
Ad esempio, nel mio caso ho in genere tre sistemi in tre partizioni diverse: slackware, debian e mint, anche se in questo periodo, avendo da poco cambiato i dischi, devo ancora installare la debian e mint. Ho creato tre file chiamati rispettivamente 11_slackware, 13_debian e 14_mint. Ciascuno riporta le impostazioni per il boot del sistema relativo. Il file 10_linux l'ho disabilitato (chmod a-x 10_linux), così come ho disabilitato i file 20_linux_xen, 30_os_prober, 40_custom e 41_custom. L'unico file dell'installazione di default che ho lasciato attivo è 00_header che non mi sono sognato minimamente di toccare per non combinare pasticci.
Detto questo, grub-mkconfig elabora nell'ordine 00_header, 11_slackware, 13_debian e 14_mint, ordine con cui i tre sistemi compaiono poi nella schermata di avvio di grub.
Il contenuto dei file è ridotto all'osso:
1) 11_slackware:
Codice: Seleziona tutto
#! /bin/sh
set -e
echo "Configuro Slackware di default (/dev/sda1)" >&2
cat << EOF
menuentry "Linux Slackware current (su /dev/sda1 kernel huge-5.4.xx)" --class gnu-linux --class gnu class os {
insmod part_msdos
insmod ext2
gfxpayload=1024x768x32
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 6ef306d8-fa6f-41a6-a08c-5afc701790cb
linux /boot/vmlinuz root=/dev/sda1
}
EOF
Codice: Seleziona tutto
#! /bin/sh
set -e
#echo ""
echo "Aggiungo Debian di default (/dev/sda1)" >&2
cat << EOF
menuentry "Linux Debian 10.0.0 (su /dev/sda1 kernel generic 4.19.0-5)" --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-5303c246-d32e-4c6d-949e-292be9a0ec4c' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 5303c246-d32e-4c6d-949e-292be9a0ec4c
echo 'Caricamento Linux 4.19.0-6-amd64...'
linux /boot/vmlinuz-4.19.0-6-amd64 root=UUID=5303c246-d32e-4c6d-949e-292be9a0ec4c ro quiet gfxpayload=1024x768x16
echo 'Caricamento ramdisk iniziale...'
initrd /boot/initrd.img-4.19.0-6-amd64
}
EOF
*******
Concordo poi con quanto detto rik70 in precedenza: invece di puntare ai nomi specifici dei kernel è ragionevole usare dei link simbolici. Nel mio caso è semplice perché ho solo il kernel huge e vmlinuz non viene toccato, perciò ad ogni aggiornamento del kernel la configurazione di grub resta invariata.
Tuttavia, se in boot si hanno più kernel (es. huge e generic) si usano dei link simbolici di comodo, che non verranno toccati dall'aggiornamento dei kernel, e si aggiorna all'occorrenza il link simbolico o con i comandi specifici oppure attraverso un semplice script bash da chiamare ogni volta che si sono aggiornati i kernel. In questo modo si evita di dover ogni volta riavviare grub-mkconfig
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: Considerazioni su Slackware e alternative
Non farti illusioni, ci sono periodi che Pat si diverte (?) ad aggiornare il kernel ogni giorno. La scorsa estate nell'arco di una decina di giorni aveva rilasciato 6 o 7 versioni del kernel, tant'è che un giorno aveva scritto nel changelog "sorry, no kernel today"joe ha scritto:Sì che sono abituato alla stabile, ma probabilmente anche la current non cambierà kernel tutte le settimane.
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Bé in quel caso vedrò di non buttare alle ortiche il mio scriptino in allegato.
È un automatismo che sicuramente con altre distribuzioni potrà non andar bene ma nel caso di slackware sembra funzionare (come si diceva il discrimine è solo la convenzione usata per nominare le immagini del kernel e relativa initrd, per il resto la procedura dovrebbe girare in ogni caso. In più c'è anche il discorso del probe che opportunamente rivisto potrebbe anche risolvere il discorso nomi kernel/initrd).
Se invece tutto l'accrocchio inizierà a scricchiolare seguirò il suggerimento di rik: link simbolici per i kernel stock e script-custom statici per i kernel fatti in casa ed eventuali altre distribuzioni.
È un automatismo che sicuramente con altre distribuzioni potrà non andar bene ma nel caso di slackware sembra funzionare (come si diceva il discrimine è solo la convenzione usata per nominare le immagini del kernel e relativa initrd, per il resto la procedura dovrebbe girare in ogni caso. In più c'è anche il discorso del probe che opportunamente rivisto potrebbe anche risolvere il discorso nomi kernel/initrd).
Se invece tutto l'accrocchio inizierà a scricchiolare seguirò il suggerimento di rik: link simbolici per i kernel stock e script-custom statici per i kernel fatti in casa ed eventuali altre distribuzioni.
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Mi stavo domandando un'altra cosa.
Per ora sono ancora su slackware 14.2, nonostante abbia già installato e configurato in parte la current sull'altra partizione. Ma in prospettiva tutta questa storia di grub, alla fine, dovrà essere usata dalla current e non più dalla stabile, se non altro per comodità, visto che ho intenzione di usare il sistema current come principale e la 14.2 la tengo solo per sicurezza.
Insomma, grub lanciato dalla current userà gli script che trova nella partizione della current dico bene?
Per cui anche la configurazione di /etc/default/grub farà riferimento alla versione più recente di grub.
Ma andrà anche reinstallato nella sua partizione all'inizio del disco? (grub-install per capirci) ?
Per ora sono ancora su slackware 14.2, nonostante abbia già installato e configurato in parte la current sull'altra partizione. Ma in prospettiva tutta questa storia di grub, alla fine, dovrà essere usata dalla current e non più dalla stabile, se non altro per comodità, visto che ho intenzione di usare il sistema current come principale e la 14.2 la tengo solo per sicurezza.
Insomma, grub lanciato dalla current userà gli script che trova nella partizione della current dico bene?
Per cui anche la configurazione di /etc/default/grub farà riferimento alla versione più recente di grub.
Ma andrà anche reinstallato nella sua partizione all'inizio del disco? (grub-install per capirci) ?
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: Considerazioni su Slackware e alternative
Non uso il partizionamento GPT quindi non so come funzioni la cosa. Per capirlo avevo provato a installare una debian in virtualbox con un partizionamento GPT ma, non so per quale motivo, c'erano problemi nel boot e alla fine ci ho rinunciato. Nei miei dischi ho solo partizionamenti con il mbr. Dal momento che ho solo sistemi linux preferisco continuare ad usare questa strada.
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Non cambia molto alla fine. Io ho un vecchio cassone BIOS senza UEFI.
Avevo partizionato come suggerito su una guida che ora non ricordo, avevo usato gdisk perchè ai tempi (parliamo del 2016...) fdisk non supportava GPT, invece adesso pare di sì:
Prendi con le pinze perché vado a memoria. La prima serve proprio perché stiamo usando un partizionamento GPT su scheda madre BIOS e perché un pezzo di Grub va proprio ad installarsi lì quando lanci grub-install /dev/sda.
La seconda serve potenzialmente se un domani sposto il disco su nuovo PC con scheda madre basata su UEFI.
Le restanti 3 sono semplici partizioni, una l'avevo messa per il sistema (sda3), l'altra per i dati (sda4) anche se ora l'ho svuotata e ci ho messo la slack-current ed infine l'ultima per lo swap, grande come la RAM installata 4GB.
Come vedi a parte le prime due che possono sembrare "esotiche", il resto è banale. Anzi più semplice perché in GPT non hai limitazioni relative al numero di partizioni primarie (le famose 4 primarie del formato MBR), non esiste neanche il concetto di partizione estesa per contenere altre partizioni "non primarie", poi ci sono altri vantaggi riguardanti il riconoscimento di dischi molto grandi, ma non è il caso del mio SSD da 25GB...
Ci sono anche svantaggi, ad esempio alcuni sistemi windows tipo il vecchio XP non credo che supporti GPT...
Insomma è una cosa più moderna e all'acquisto del disco, siccome era uscita la "nuova" slackware 14.2, avevo deciso di riammodernare così il partizionamento.
EDIT
Aggiungo questa piccola guida che parla anche di fdisk e del comando "g" per creare una nuova tabella partizioni in formato GPT:
https://seravo.fi/2019/partition-like-a ... and-cfdisk
Avevo partizionato come suggerito su una guida che ora non ricordo, avevo usato gdisk perchè ai tempi (parliamo del 2016...) fdisk non supportava GPT, invece adesso pare di sì:
Codice: Seleziona tutto
# fdisk -l /dev/sda
Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A176F3CE-5FBF-4682-BD67-F68331CE7D3
Dispositivo Start Fine Settori Size Tipo
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 413695 409600 200M EFI System
/dev/sda3 413696 210128895 209715200 100G Linux filesystem
/dev/sda4 210128896 480112639 269983744 128,8G Linux filesystem
/dev/sda5 480112640 488397134 8284495 4G Linux swap
La seconda serve potenzialmente se un domani sposto il disco su nuovo PC con scheda madre basata su UEFI.
Le restanti 3 sono semplici partizioni, una l'avevo messa per il sistema (sda3), l'altra per i dati (sda4) anche se ora l'ho svuotata e ci ho messo la slack-current ed infine l'ultima per lo swap, grande come la RAM installata 4GB.
Come vedi a parte le prime due che possono sembrare "esotiche", il resto è banale. Anzi più semplice perché in GPT non hai limitazioni relative al numero di partizioni primarie (le famose 4 primarie del formato MBR), non esiste neanche il concetto di partizione estesa per contenere altre partizioni "non primarie", poi ci sono altri vantaggi riguardanti il riconoscimento di dischi molto grandi, ma non è il caso del mio SSD da 25GB...
Ci sono anche svantaggi, ad esempio alcuni sistemi windows tipo il vecchio XP non credo che supporti GPT...
Insomma è una cosa più moderna e all'acquisto del disco, siccome era uscita la "nuova" slackware 14.2, avevo deciso di riammodernare così il partizionamento.
EDIT
Aggiungo questa piccola guida che parla anche di fdisk e del comando "g" per creare una nuova tabella partizioni in formato GPT:
https://seravo.fi/2019/partition-like-a ... and-cfdisk
- conraid
- Staff
- Messaggi: 13630
- Iscritto il: gio 14 lug 2005, 0:00
- Nome Cognome: Corrado Franco
- Slackware: current64
- Desktop: kde
- Località: Livorno
- Contatta:
Re: Considerazioni su Slackware e alternative
Sì, e non mi funziona, qualsiasi numero metto è come se fosse sempre 0.gian_d ha scritto:Non so se ho capito qual è il problema a cui ti riferisci. Per ordine di boot ti riferisci forse all'ordine con cui le voci vengono elencate nella schermata di Grub?conraid ha scritto:Ecco, una cosa che non mi ha mai funzionato è l'ordine di boot, qualsiasi cosa scriva me lo mette poi in ordine alfabetico. Ma avendo "saved" mi ricorda l'ultima scelta e quindi ok.
Se è quello, la soluzione è semplicissima: l'ordine è definito dal numero progressivo con cui inizia il nome del file eseguibile (con l'attributo x, per intenderci) presente in grub.d.
Uso solo la current e ho 3 kernel al boot di solito (generic, huge e uno compilato)
Come faceva notare rik70
dovrei provare, ma non c'è il rischio che la voce cambi ogni volta?rik70 ha scritto:In effetti è un po macchinoso e dipende dalla versione di grub.conraid ha scritto:una cosa che non mi ha mai funzionato è l'ordine di boot, qualsiasi cosa scriva me lo mette poi in ordine alfabetico.
Dalla 2.0x in poi - mi pare - bisogna inserire il valore '$menuentry_id_option' della voce che t'interessa e che trovi nel tuo grub.cfg.
Nel manuale comunque c'è scritto che son supportate entrambe le modalità
https://www.gnu.org/software/grub/manua ... ation.html
e se non erro dal mio pessimo inglese sembra che prima era consigliato la voce e che ora è sconsigliato, sbaglio?
- conraid
- Staff
- Messaggi: 13630
- Iscritto il: gio 14 lug 2005, 0:00
- Nome Cognome: Corrado Franco
- Slackware: current64
- Desktop: kde
- Località: Livorno
- Contatta:
Re: Considerazioni su Slackware e alternative
è y qui come ti diceva rik70, pardonjoe ha scritto:Volevo provare a far girare il 10_linux con le opzioni indicate da Corrado, per vedere se intanto si sfoltiva un po' la fazenda. Però, a me non funziona mai niente alla prima!Codice: Seleziona tutto
# grep -v "^#\|^$" /etc/default/grub GRUB_DEFAULT=saved GRUB_SAVED_DEFAULT=true GRUB_HIDDEN_TIMEOUT_QUIET=false GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=$( sed 's/Slackware /Slackware-/' /etc/slackware-version ) GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="" GRUB_GFXMODE=1024x768x32 GRUB_DISABLE_RECOVERY="true" GRUB_DISABLE_SUBMENU="true"
ho copiato un file vecchio non commentato e si vede non era solo privo di righe commentate ma anche versione errata
https://www.gnu.org/software/grub/manua ... ation.html
il file "vero" è questo
Codice: Seleziona tutto
# If you change this file, run grub-mkconfig -o /boot/grub/grub.cfg
# afterwards to update /boot/grub/grub.cfg.
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=$( sed 's/Slackware /Slackware-/' /etc/slackware-version )
GRUB_CMDLINE_LINUX_DEFAULT="video=SVIDEO-1:d ipv6.disable=1"
GRUB_CMDLINE_LINUX="vt.default_uf8=1 raid=noautodetect"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
#GRUB_GFXMODE=1024x768x32
# Font used on the graphical terminal:
#GRUB_FONT=/usr/share/grub/dejavusansmono.pf2
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entrys
GRUB_DISABLE_LINUX_RECOVERY="true"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_SUBMENU="y"
GRUB_DISABLE_OS_PROBER="true"
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Ho provato, ma come diceva rik70 qualche post fa, il fato vuole che quella direttiva non sia supportata dalla versione di grub della stabile: la 2.00.
Invece sulla current abbiamo la versione descritta nella documentazione che linkavi sopra
Ecco perché tra l'altro mi chiedevo se non fosse il caso di configurare e lavorare con grub dalla current, piuttosto che dalla stabile che sto usando ora
http://slacky.eu/forum/viewtopic.php?f= ... 01#p355089
Codice: Seleziona tutto
$ ls /var/log/packages/|grep grub
grub-2.00-x86_64-5
Codice: Seleziona tutto
$ ls /mnt/ssd/var/log/packages/|grep grub
grub-2.04-x86_64-1
http://slacky.eu/forum/viewtopic.php?f= ... 01#p355089
-
- Iper Master
- Messaggi: 2489
- Iscritto il: gio 10 mar 2011, 9:21
- Slackware: 15.0
- Kernel: 5.15.x-generic
- Desktop: Sway
- Distribuzione: Arch Linux
Re: Considerazioni su Slackware e alternative
Certo, nella misura in cui cambia la versione del kernel e rigeneri grub.cfg.conraid ha scritto:dovrei provare, ma non c'è il rischio che la voce cambi ogni volta?
Ecco il perché di tutto il discorso sull'opportunità di seguire link simbolici in assenza di nomi 'univoci' delle immagini dei kernel.
Ma può cambiare anche se cambia l'uuid del filesystem dove risiede la directory /boot, anche se questa è una situazione "estrema"(migrazione su nuovo disco con ripartizionamento/formattazione, etc.)
Sì, sembra funzionare anche con i numeri utilizzando lo stesso approccio degli id. Esempio, se hai il submenu e vuoi far partire sempre la prima voce al suo interno, dovresti scrivere:conraid ha scritto:Nel manuale comunque c'è scritto che son supportate entrambe le modalità
https://www.gnu.org/software/grub/manua ... ation.html
Codice: Seleziona tutto
GRUB_DEFAULT='1>0'
No non sbagli per le ragioni dette sopra - l'id dell'entry può cambiare. Poi propone come alternativa il metodo che usi tu - 'saved'.conraid ha scritto:se non erro dal mio pessimo inglese sembra che prima era consigliato la voce e che ora è sconsigliato, sbaglio?
Comunque adattate quello che leggete in quel manuale alla situazione che trovate nel vostro grub.cfg. Guardate ad esempio la faccenda degli ID delle entry come è differente.
Ultima modifica di rik70 il gio 9 gen 2020, 11:49, modificato 3 volte in totale.
-
- Iper Master
- Messaggi: 2489
- Iscritto il: gio 10 mar 2011, 9:21
- Slackware: 15.0
- Kernel: 5.15.x-generic
- Desktop: Sway
- Distribuzione: Arch Linux
Re: Considerazioni su Slackware e alternative
Sì, però probabilmente deve reinstallare grub.joe ha scritto:
Ecco perché tra l'altro mi chiedevo se non fosse il caso di configurare e lavorare con grub dalla current, piuttosto che dalla stabile che sto usando ora
http://slacky.eu/forum/viewtopic.php?f= ... 01#p355089
- joe
- Iper Master
- Messaggi: 3789
- Iscritto il: ven 27 apr 2007, 11:21
- Slackware: 15.0
- Kernel: 5.15.38
- Desktop: dwm
Re: Considerazioni su Slackware e alternative
Sì questo sì... Non è detto che il tutto non funzioni anche con la vecchia installazione, perché di fatto grub-makeconfig scrive solo la configurazione. Ad esempio nel caso della disabilitazione dei submenu, semplicemente verrà cambiato il grub.cfg, ma non viene toccata la parte di grub che sta nella sua partizioncina ad inizio disco. E in questo caso il grub.cfg finale dovrebbe restare coerente col funzionamento del bootloader.
Potrebbe però essere il caso che facendo girare il grub-mkconfig nuovo, la configurazione che crea sia effettivamente non più compatibile in qualche punto con il bootloader che sta sulla partizione "BIOS boot". Quindi meglio reinstallare tutto e via. Alla fine sono due comandi e impiegano mezzo secondo...
Comunque sono sempre più convinto della tua soluzione: ovvero grub.cfg "statico" contenente solo i collegamenti simbolici ai kernel stock.
Se poi si vogliono aggiungere altri kernel, compilati a mano o altre distro, allora non si può fare a meno di rigenerare il grub.cfg.
Può tornare utile l'approccio di gian_d, ovvero creare uno o più script "custom" ad hoc.
Oppure banalmente si potrebbe fare uno script che prende in input ( titolo, disco, partizione, nome_kernel, nome_initrd) e scrive la nuova entry in coda ad un ipotetico "/etc/grub.d/43_custom" derivante dal 40_custom. Anche se io a quel punto preferisco direttamente nominare lo script come 43_custom e usare una funzione add_entry da utilizzare direttamente nel corpo dello script.
Metto in allegato un esempio con lo script 42_slackware per slackware stock, in cui ho messo i link simbolici, e lo script 43_custom con un esempio di gestione di kernel esotici o distribuzioni diverse in altre partizioni. E qui il grub.cfg che salta fuori dopo aver lanciato il solito "grub mkconfig": permessi d'esecuzione al solo 00_header, 42_slackware, 43_custom.
Potrebbe però essere il caso che facendo girare il grub-mkconfig nuovo, la configurazione che crea sia effettivamente non più compatibile in qualche punto con il bootloader che sta sulla partizione "BIOS boot". Quindi meglio reinstallare tutto e via. Alla fine sono due comandi e impiegano mezzo secondo...
Comunque sono sempre più convinto della tua soluzione: ovvero grub.cfg "statico" contenente solo i collegamenti simbolici ai kernel stock.
Se poi si vogliono aggiungere altri kernel, compilati a mano o altre distro, allora non si può fare a meno di rigenerare il grub.cfg.
Può tornare utile l'approccio di gian_d, ovvero creare uno o più script "custom" ad hoc.
Oppure banalmente si potrebbe fare uno script che prende in input ( titolo, disco, partizione, nome_kernel, nome_initrd) e scrive la nuova entry in coda ad un ipotetico "/etc/grub.d/43_custom" derivante dal 40_custom. Anche se io a quel punto preferisco direttamente nominare lo script come 43_custom e usare una funzione add_entry da utilizzare direttamente nel corpo dello script.
Metto in allegato un esempio con lo script 42_slackware per slackware stock, in cui ho messo i link simbolici, e lo script 43_custom con un esempio di gestione di kernel esotici o distribuzioni diverse in altre partizioni. E qui il grub.cfg che salta fuori dopo aver lanciato il solito "grub mkconfig": permessi d'esecuzione al solo 00_header, 42_slackware, 43_custom.