Se avete problemi con l'installazione e la configurazione di Slackware64 postate qui. Non usate questo forum per argomenti che trattano la Slackware32 o generali... per quelli usate rispettivamente il forum Slackware e Gnu/Linux in genere.
Regole del forum
1) Citare sempre la versione di Slackware64 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 Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
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.
Grazie per i suggerimenti e un aggiornamento: per vedere se tutto funzionava bene ho creato un file 11_linux sulla Slackware Current creato seguendo le istruzioni sopra riportate, quindi ho lanciato
e poi ho riavviato selezionando il come disco di avvio quello della Slackware Current che si è avviato senza problemi (quindi in caso di intoppi con il grub della Debian posso sempre far partire la Slackware Current).
Ora volevo procedere sulla Debian però su 30_os_prober ho sia l' avvio della Slackware che di Win
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/nvme0n1p2)' --class windows --class os $menuentry_id_option 'osprober-efi-5EC6-270D' {
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 5EC6-270D
else
search --no-floppy --fs-uuid --set=root 5EC6-270D
fi
chainloader /efi/Microsoft/Boot/bootmgfw.efi
}
menuentry 'Slackware 15.0 x86_64 (on /dev/sdb2)' --class slackware --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-87bc07c9-35b5-4dfa-a536-d81e1155acae' {
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 87bc07c9-35b5-4dfa-a536-d81e1155acae
else
search --no-floppy --fs-uuid --set=root 87bc07c9-35b5-4dfa-a536-d81e1155acae
fi
linux /boot/vmlinuz-huge-5.15.7 root=/dev/sdb2 ro
}
submenu 'Advanced options for Slackware 15.0 x86_64 (on /dev/sdb2)' $menuentry_id_option 'osprober-gnulinux-advanced-87bc07c9-35b5-4dfa-a536-d81e1155acae' {
menuentry 'Slackware-15.0 GNU/Linux (on /dev/sdb2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-huge-5.15.7--87bc07c9-35b5-4dfa-a536-d81e1155acae' {
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 87bc07c9-35b5-4dfa-a536-d81e1155acae
else
search --no-floppy --fs-uuid --set=root 87bc07c9-35b5-4dfa-a536-d81e1155acae
fi
linux /boot/vmlinuz-huge-5.15.7 root=/dev/sdb2 ro
}
Ora disabilitando OS_PROBER mi conviene creare un file nominato 11_linux che contenga sia Win che Slackware o creare due file: uno 11_linux per Slackware e uno 12_Win per Win?
Con dei template personalizzati l'OS_PROBER è inutile, anzi, crea delle entry ridondanti. Una volta che le entry, opportunamente testate, funzionano a quel punto OS_PROBER va disabilitato. Io sono dell'opinione che sia opportuno fare file separati, uno per ciascuna entry: in caso di problemi è più agevole risalire alla criticità. Peraltro c'è un altro vantaggio: il numero del nome del file definisce l'ordine di elaborazione dello script e - di conseguenza - anche l'ordine con cui compariranno le entry nel menu di Grub. Se un giorno decidi di modificare quest'ordine è sufficiente rinominare i file con un'opportuna numerazione. Se invece hai più entry in uno stesso file devi lavorare di taglia e incolla. Con il rischio di fare pasticci.
A margine: proprio ieri ho installato la Debian 11.2, in una partizione del secondo disco. Nella fase di partizionamento ho disabilitato l'utilizzo delle partizioni EFI di tutti i dischi ad eccezione del secondo disco, perciò la Debian ha scritto su quella partizione. Dopo di che ho copiato il codice dell'entry in un file 12_debian nel grub.d della Slackware e rigenerato il grub.cfg
Per evitare di mettere mano troppo spesso a Grub ho adottato anche per la Debian l'escamotage dei simlink (dalla Slackware, la partizione della debian è montata su una directory /debian):
#! /bin/sh
set -e
echo "Configuro Debian kernel generic (/dev/sdb2)" >&2
cat << EOF
menuentry 'Linux Debian 11.2 (su /dev/sdb2 kernel generic-5.10.xx)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-758c9d7a-4ac7-4d32-a2b6-fb2f72b52ef9' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_int = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 758c9d7a-4ac7-4d32-a2b6-fb2f72b52ef9
else
search --no-floppy --fs-uuid --set=root 758c9d7a-4ac7-4d32-a2b6-fb2f72b52ef9
fi
echo 'Caricamento del kernel Linux ...'
linux /boot/vmlinuz root=UUID=758c9d7a-4ac7-4d32-a2b6-fb2f72b52ef9 ro quiet
echo 'Caricamento del ramdisk iniziale ...'
initrd /boot/initrd.img
}
In questo modo ad ogni aggiornamento del kernel sulla Debian devo solo preoccuparmi di aggiornare i due collegamenti simbolici per puntarli alla versione aggiornata. Il grub.cfg va rigenerato solo a seguito di un eventuale aggiornamento significativo di Grub sia sulla Debian sia sulla Slackware (che potrebbe richiedere la modifica di alcune impostazioni del codice delle entry)
Sei sicuro che la procedura di aggiornamento di Debian non prenda anche l'iniziativa di richiamare in automatico grub-update?
Non dovrebbe in ogni caso fare differenza visto che se ho ben capito hai disabilitato gli altri script "prober" e compagnia... comunque è bene tenerlo presente, perché quando viene eseguito grub-update, in realtà grub.cfg viene riscritto.
Non mi sono spiegato bene. Ho quattro dischi (due di backup), di cui viene avviato al boot il primo disco. Su questo è attivo il Grub della Slackware. Il Grub della Debian viene scritto invece sul secondo disco perciò quello che fa la Debian al suo aggiornamento non interferisce minimamente con il boot loader che uso come predefinito. Tuttavia avere un boot loader alternativo può essere utile per accedere eventualmente ad un sistema operativo in caso di problemi (nel caso la Debian): è sufficiente cambiare la sequenza di boot nel bios all'occorrenza.
Sì ma in quel caso remoto, utilizzerai il grub.cfg della Debian no?
Per cui l'aggiornamento di Debian deve comunque essere coerente con quello "scenario" diciamo di backup.
La coerenza potrebbe (non credo ma...) essere compromessa da eventuali automatismi in fase di aggiornamento, se durante quell'operazione (di aggiornamento) viene richiamato grub-update (che poi se non sbaglio è una sorta di wrapper al nostro grub-mkconfig.
Il senso di quello che sto dicendo vuole essere: se lavori con link simbolici anche per debian, assicurati che il sistema di aggiornamento debian non crei per qualche santo un grub.cfg (quello della Debian) non coerente coi tuoi link.
Sì, ho capito quello che vuoi dire, ma credo che questo problema non esista: i link simbolici sono chiamati in causa dal grub della Slackware che ha subito una personalizzazione ad hoc, mentre il grub dell'ambiente Debian mantiene la configurazione predefinita (eventualmente con gli aggiornamenti periodici). Il Grub della Debian richiama direttamente il kernel e la ramdisk iniziale come da configurazione predefinita.
Detto questo, nell'ipotesi che dovessi trovarmi nella necessità di accedere con il boot loader della Debian, questo funzionerebbe regolarmente con l'avvio della Debian. Quanto basta per poi operare per le eventuali riparazioni. In questo caso la Debian funzionerebbe come un sistema live che si usa all'occorrenza per mettere mano alle necessarie riparazioni. A mio parere gli aggiornamenti automatici non interferiscono negativamente. Anzi, la riconfigurazione automatica del grub della Debian è funzionale a questo scopo.
Piuttosto, una cosa che posso fare (e che farò) è quella di configurare nel grub.d della Debian un accesso corretto per la Slackware e disabilitare l'OS prober. In questo modo si ha un boot loader alternativo pienamente operativo che può subentrare al boot loader della Slackware.