Newsgroup: it.comp.os.linux.iniziare
Titolo: Installare o non installare Grub

Ho la Debian buster, da cui scrivo, in /dev/sda1 e adesso installo
la Debian bullseye in /dev/sdb1.
 
Temo di fare errori perche' ho una minima (2 anni fa) esperienza
al riguardo di Grub2 (sarei sicuro con LILO, ma oramai e' morto
e sepolto), percio' chiedo aiuto per non fare passi falsi.
 
1. Quando termino l'installazione della nuova bullseye e l'installer
mi chiede d'installare grub, posso dirgli di no e poi sistemare tutto
col grub che ho qui nella vecchia buster?
 
2. Cosa devo fare con grub, qui nella vecchia buster, per aggiungere
la nuova bullseye al menu' di grub e fargli scrivere il settore di boot
della nuova partizione?
 
Ciao a tutti e grazie per l'attenzione
 
-- 
Yoda
 

 
 
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 non dovrebbe essere necessario.
 
Si' probabilmente non occorre, anche se il caso mio e' differente.
Vuol dire che diro' di no e poi vedro' cosa fare ciao e grazie
 
-- 
Yoda
 


Questo e` un buon metodo per avere un
sistema che non parte piu`.
 
Tieni pronto un DVD / USB live.
 
In ogni caso, domanda collaterale, a cosa
ti serve avere un dual boot Debian?
 
Perche` se devi fare delle prove, la cosa
migliore e` usare una macchina virtuale,
tipo VirtualBox.
Questo evita parecchi problemi.
 
Se vi sono altre ragioni, allora potrebbe
anche andar bene, ma cercherei di evitare,
se possibile.
 
bye,
 
-- 
 
piergiorgio

 se possibile.
 
condivido
 

"update-grub" cerca tutti i sistemi avviabili e crea il menu di boot

 "update-grub" cerca tutti i sistemi avviabili e crea il menu di boot
 
Si', pero' all'ultimo momento ho scelto d'installare grub per questi
due motivi:
1. E' la versione ultima (sulla buster non c'e' quel pacchetto)
2. L'installazione di alcuni pacchetti alla fine chiama grub, dunque
non so cosa sarebbe successo se non l'avesse trovato.
 
Grazie a tutti e ciao
 
Postilla.
Ho lanciato maledizioni infinite quando grub ha scandagliato tutti
i MIEI cinque dischi fissi -- maledetta Uindous! -- trovando sei
distro da avviare (gia' dalla jessie e tutte morte e defunte).
 
Allora -- astutissimo -- gli ho messo questa riga nel file
/etc/default/grub
GRUB_DISABLE_OS_PROBER="true"
e dato update-grub.
 
Niente da fare, e' scomparso anche l'avvio della buster!
Allora -- disperato -- ho rimosso la directory /boot in ognuna delle
cinque distro morte e ridato update-grub.
 
E adesso grub e' pefettamente ok.. anche se rompe l'anima
scandagliando ogni volta i MIEI 7 tera di filesystem e riempendomi
la pagina di "raid raid raid.." anche se da me di raid non ce n'e'
neppure l'ombra.
(ma gia' la trovo prima o poi la direttiva per fargli cercare solo
dove gli dico io!)
 
-- 
Yoda
 

 se possibile.
 
Avevo dimenticato questo seguito tuo, rispondo
adesso.
Semplicemente io voglio passare dalla buster
alla bullseye.
Per fare cio', mi viene meglio fare una nuova
installazione piuttosto che dist-upgrade ciao
 
 
Postilla. Oltre al fatto che risulta piu' veloce e pulita (con
l'upgrade certe directory non vuote occorre rimuoverle poi a mano),
personalmente ho anche questi due motivi aggiuntivi per installare
ex novo:
1. Qui ho, installato, il task Server di stampa che ultimamente m'ha
reso inutilizzabile la Brother laser, invece di stampare manda tutto
in coda di stampa. Non m'e' riuscito in alcun modo di sistemarlo!
Pero' ho visto con piacere che questo task adesso l'hanno tolto.
 
2. Avevo smanettato tempo fa con un programma (che non ricordo) per
testare e/o settare la tastiera. Sono finito coi led che non c'e'
piu' alcun modo per far si' che corrispondano allo stato -- e il
bello (si fa per dire) e' che tutto questo l'avevo fatto come user!
 
-- 
Yoda
 

 bello (si fa per dire) e' che tutto questo l'avevo fatto come user!
 
Sempre con il dovuto rispetto, questi sembrano
commenti da utente Windows...
 
bye,
 
-- 
 
piergiorgio

 dove gli dico io!)
 
Se noti, in /etc/grub.d/ c'è anche il file 40_custom
 
Se non vuoi usare os-prober, puoi appunto aggiungere nel file
/etc/grub.d/40_custom
sotto le righe già presenti, i menuentry per gli altri tuoi sistemi, 
oppure creare nuovi file eseguibili sulla falsariga di 40_custom, ad 
esempio 11_Wheezy , 12_Jessie , 13_Stretch , ecc.
 
(La numerazione è importante perché troverai poi gli OS listati nel menu 
di Grub in quell'ordine.)
 
Questa è una guida di Ubuntu, ma spero possa esserti d'aiuto come base 
di partenza per capire come vanno scritti quei file:
 
https://help.ubuntu.com/community/Grub2/CustomMenus
 
 

Addi' 16 giu 2022 08:07:55, Piergiorgio Sartor scrive:

Per la stampa c'e' un solo e unico tool nella GUI, quindi c'e' poco
da fare o dire, d'altra parte da riga di comando stampa benissimo.
 
Per i diodi invece dovrei riprendere il discorso quando e se ritrovo
(nell'history) il comando incriminato, se no adesso risulta solo un
parlare a vavera; comunque non credere che io non conosca a memoria
comandi come setled e simili per le tty ciao e grazie
 
-- 
Yoda
 

 comandi come setled e simili per le tty ciao e grazie
 
Quello che voglio dire e` che installare
un sistema ex-novo, solo perche` un paio
di cose non funzionano e` piuttosto, come
dire, estremo in Linux.
 
Puo` succedere, ma di solito si riesce a
risolvere "online".
 
bye,
 
-- 
 
piergiorgio

 percio' chiedo aiuto per non fare passi falsi.
]zac[
 
Dipende da troppe cose.
 
Personalmente tendo a installare grub2 nella partizione di avvio/boot (o 
se è un diverso disco nell'MBR del secondo disco) del nuovo sistema.
 
E modificare a mano (se non viene rilevato in automatico) la 
configurazione del boot loader principale (che sia linux/windows/altro) 
per inserire il solo passaggio ai grub2 secondari.
 
Qualcosa tipo
 
...............
	search ................
...............
	parttool ${root} hidden-
        drivemap -s (hd0) ${root}
        chainloader +1
...............

Addi' 18 giu 2022 19:16:07, Giuseppe Della Bianca scrive:

Fino alla nuova installazione della bullseye avevo un solo grub
(sottinteso che e' sempre e solo grub2) in /dev/sda1 = EFI System
di 500 mega, che aveva "visto" un solo OS da avviare in /dev/sda2,
per questi due motivi:
- all'installazione avevo staccato i cavi a tutti gli altri hd
- poi, riattaccati, avevo aggiunto: GRUB_DISABLE_OS_PROBER="true"
al file /etc/default/grub.
 
Ora ho installato la bullseye in /dev/sde1 e l'installer, quando ha
installato grub, ha montato la EFI in /boot della root di /dev/sde1.
 
PRIMO PUNTO DI DUBBIO
Dunque mi succede questo, che la EFI viene montata sia dalla buster,
sia dalla bullseye come subdir di /boot della root-partition che di
volta in volta avvio (sda2 o sde1).
E questo non lo so se e' cosa giusta.
 
SECONDO PUNTO DI DUBBIO
Nella nuova bullseye non ho potuto impedire che grub cercasse per
avviare anche la vecchia buster, pena l'impossibilita' d'avviare
la vecchia.
Nella vecchia buster invece grub ha ancora la direttiva che lo
disabilita: GRUB_DISABLE_OS_PROBER="true".
Devo lasciarla o devo toglierla?
 
* * *
 
Mi attira molto quel che hai scritto, con LILO facevo proprio cosi':
- un solo LILO nel MBR del disco C d'avvio del BIOS, che vedeva ogni
altra distro (ne avevo 4 o 5) come "other"
- quindi un LILO in ogni boot record della partizione di boot (non
Master!) d'ognuna delle altre distro.
 
Qui con grub come faccio a distinguere il grub principale dai grub
secondari? ciao e grazie!
 
-- 
Yoda
 

 secondari? ciao e grazie!
 
E' appunto per evitare confusione che tendo a tenere completamente 
separati i vari grub dal boot principale.
 
Ma questo vuol dire che tocca anche forzare l'installer ad un 
partizionamento manuale e dirgli quali sono le nuove partizioni di boot e 
di sistema e dove installare il boot loader (bisogna farsi un po' di 
esperienza e provare riprovare con le distribuzioni specifiche).
 
L'alternativa è lasciare fare all'installar, quindi avere una sola 
partizione di boot, un solo grub, ecc. .
 
O avere dischi separati, in questa maniera si possono anche fare prove di 
boot in maniera progressiva.
 
Personalmente lascio sempre attivo il os prober, per le cose manuali c'è 
lo script nn_custom di grub, e uso sempre gli UID delle partizioni e dei 
dischi (sono gli unici sicuri e stabili) e non i nomi dei device di linux 
o del bios (li uso solo come risorsa per risolvere temporaneamente 
problemi di boot).
 
Sinceramente a distanza è molto difficile aiutare per problemi di boot se 
non con consigli/suggerimenti generici.
 
 
 

 partizione di boot, un solo grub, ecc.
 
Ma se ho grub solo -diciamo- nella buster, cosa succede quando nella
bullseye installo un pacchetto che alla fine aggiorna lanciando
"update-grub" di un grub che non c'e'?
 
-- 
Yoda
 

 chiamato dall'UEFI-BIOS all'avvio? ciao e grazie!
 
-- 
bye, Yoda
 

 chiamato dall'UEFI-BIOS all'avvio? ciao e grazie!
 
Ora lo so, per verifica diretta.
Nella EFI il file grub.cfg da' l'UUID del disco fisso dove risiede
il boot manager, che sarebbe il grub principale.
E' solo il grub principale che deve cercare gli OS da avviare,
tutti gli altri grub devono avere la riga:
GRUB_DISABLE_OS_PROBER="true"
nel file /etc/default/grub, altrimenti si duplicano inutilmente le
scelte per l'avvio; sono solo dei boot loader.
 
Aggiungo un'info. Da me e' diventato automaticamente principale il
grub installato per ultimo. Questo puo' essere per il motivo che il
precedente aveva la direttiva GRUB_DISABLE_OS_PROBER abilitata, ma
per il momento non posso saperlo.
Ho anche la quasi certezza che si possa configurare tutto secondo
i propri gusti ed esigenze.
Se scopro altro, lo scrivo - magari puo' servire (a me certamente,
perche' mi dimentico tutto).
 
-- 
bye, Yoda
 

 perche' mi dimentico tutto).
 
Ho aggiunto adesso in /etc/default/grub (d'ogni grub, prima nel
secondario, poi nel principale) la riga:
GRUB_DISABLE_SUBMENU="y"
cosi' il menu' diventa piu' chiaro e semplice.
 
-- 
bye, Yoda
 

 dove gli dico io!)
 
Trovata!
GRUB_OS_PROBER_SKIP_LIST="UUID UUID UUID..."
 
quindi per me, nel mio caso, e' un massacro: piu' di cinquanta UUID
da determinare e trascrivere in /etc/default/grub -> ERGO ci rinuncio!
 
-- 
bye, Yoda
 

blkid
 
echo $(blkid | grep UUID | sed -e 's/.* UUID="\(.*\)/\1/; s/".*//')
 
 
Il Sat, 25 Jun 2022 06:48:02 -0000 (UTC), Yoda ha scritto:
 
]zac[


 echo $(blkid | grep UUID | sed -e 's/.* UUID="\(.*\)/\1/; s/".*//')
 
!! grazie!! qui da me con la Debian la manpagina di blkid mi dice
subito e in grassetto che:
-cite-
It  is  recommended  to  use  lsblk(8) command to get information about
block devices, or lsblk --fs to get  an  overview  of  filesystems,  or
findmnt(8) to search in already mounted filesystems.
-/cite-
 
quindi e' una pacchia, perche' lsblk puo' darlo user e allora senza
stare troppo attenti, eccolo subito per prova sul piu' vecchio hd:
 
$: lsblk -o KNAME,UUID,FSTYPE /dev/sdc
KNAME UUID                                 FSTYPE
sdc
sdc1  5053a63e-4e8b-4217-ac17-858bc9dd7073 ext2
sdc2  23c0a6cd-3ce0-4ad2-b69f-863f0e652b06 ext2
sdc3  9f4b1eae-0ac8-407b-b879-4a326e7987ff ext2
sdc4
sdc5  a78696d3-3e9b-449c-a9ff-7e656f2ac777 swap
sdc6  d4fdb9e5-4947-4cf7-a598-732fc9881fd2 ext2
sdc7  792ef789-492a-4c64-ba89-97c744982e32 ext2
sdc8  a4a8c06c-a595-42e5-b62f-140f2a780a2d ext2
sdc9  94f06cb3-4caf-4e13-ab6a-451b63873377 ext2
sdc10 07df3550-d95a-4180-b7ab-9d98741f04c6 ext2
sdc11 794e46d4-a311-4f72-88bd-aa94d5b6f85e ext2
sdc12 b1799999-5386-41b4-9eeb-a912a1298f03 ext2
sdc13 0254ff13-73f3-414c-aaf3-92ca0279151b ext2
sdc14 db489736-2d2f-4ab6-9b5e-37f109bfd2e2 ext2
 
* * *
 
M'hai dato anche un'altra dritta con la riga di comando di sed,
posso evitare di ripetere ogni volta il "-e", basta il ";" a patto
di restare entro gli apici semplici. Io avrei scritto:
-e 's/.* UUID="\(.*\)/\1/' -e 's/".*//'
 
invece di:
-e 's/.* UUID="\(.*\)/\1/; s/".*//'
 
e quando le sostituzioni sono molte fa molta differenza.
Ciao e ancora grazie!!
 
-- 
Yoda
 

 Ciao e ancora grazie!!
 
Prego, di niente, a te.
 
 
 
P.S. Spiacente per il discorso del boot primario che chiamano altri grub, 
ma il processo di boot non è banale, e a distanza le probabilità di non 
avere un sistema che si avvia sono alte (anche perché per le operazioni 
manuali da fare).