Dopo un aggiornamento GRUB si installa solo sll'MBR

1. Il problema è questo: uso ormai da molti anni un bootloader "esterno" (OSL2000, poco conosciuto ma con cui mi sono sempre trovato benissimo). Ovviamente lui sta sempre nell'MBR mentre in ogni partizione linux  metto i rispettivi bootloader. Così sino alla Ubuntu 10.10.
Ora accade che quando c'e' un aggiornamento che interessa Grub, questo viene sempre riscritto in /dev/sda (e non in /dev/sdaXX come naturalmente mi servirebbe).
:'(  :'(

2. la prima volta che è accaduto ho pensato di aver sbagliato io qualcosa...
Seguendo le "apposite istruzioni" per reinstallare GRUB, alla fine (dopo aver dato "grub-install /dev/sdaXX") è arrivato il seguente avviso "warn: embedding is not possible GRUB can only be installed in this setup using blocklist however blocklist are unreailable and their use is discouraged"
A questo punto ho comunque forzato (grub-install --force) l'installazione sulla partizione che volevo. L'installazione è andata a buon fine ma, come ho detto prima, non  si reinstalla più su questa stessa partizione dopo un aggiornamento.
>:( 

3. Siccome non posso pensare che non sia più possibile mantenere il GRUB di Ubuntu nella sua partizione (anche dopo un aggiornamento del kernel e conseguente modifica del GRUB) e non OBBLIGATORIAMENTE sull'MBR (in modo eccessivamente "invasivo" e affatto tipico di linux come l'ho conosciuto sino ad ora) mi chiedo se è un problema mio e se posso bypassarlo o se va considerato un bug o non so che altro  cosa...
 

4. Ultimo aspetto: siccome nell'installazione mi sono dimenticato di dirgli di NON installare su MBR, (devo dire che non ho fatto nemmeno caso se  era previsto nell'installazione) non vorrei che quell'iniziale passaggio mancato abbia condizionato il seguito...

Aspetto lumi.

Ciao!

Dopo qualche ricerca su lunchpad ho trovato qualcuno che, più o meno,  la pensa come me:
https://bugs.launchpad.net/ubuntu/+sour ... bug/445416

Inoltre google è pieno di risposte se interrogo con:
"grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea".
o con:
"GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged".

 


OK ho capito: corro dei rischi!! Ma avrò il permesso di correrli (anche dopo un aggiornamento che fa girare grub-install)  o devo accettare che sia Canonical a decidere ("scoraggiandomi" di brutto) che cosa va bene per me??

 

Del mio caso specifico non sono (ancora) venuto a capo... comunque le ricerche proseguono e vi terrò aggiornati.

Ciao!

Ciao!
Ho installato ieri la RC.
Purtroppo confermo che non è proprio possibile NON installare grub. Manca infatti il segno di spunta "Non installare nessun boot loader" tipico delle precedenti versioni di ubuntu.
Questa cosa secca parecchio anche a me, visto che io uso normalmente grub1 installato nel mbr ma con i file di sistema di grub in un'altra partizione. Stavolta, invece, mi sono sorbito per forza grub2, pertanto dopo l'installazione ho dovuto rimettere mano a grub-install per ripristinare il tutto come voglio io...

Inutile dire che uno potrebbe avere validi motivi per non voler installare il boot loader. Speriamo che aggiornino l'installer correggendo il tiro in vista della release finale.

Se vuoi comunque usare il tuo bootloader, potresti usare un workaround. Prima di installare grub, fai una copia dell'mbr con dd mettendola in un file. Dopo che grub si è installato nell'mbr puoi inserire una voce nel menu di grub che fa il chainloading con il file contenente il bootloader esterno. In questo modo, ogni volta che grub si reinstalla, il boot loader esterno dovrebbe continuare a funzionare.

Intanto grazie delle risposte! (Ormai pensavo di aver sollevato qui un argomento "peregrino"... invece no! )

Su launchpad mi avevano consigliato di usare "'sudo dpkg-reconfigure grub-pc" ma, come ho detto anche  lì (e come conferma Gibbus), temo fortemente che non sia risolutivo per il mio problema.

@gianmpu
temo che la logica del tuo workaround possa andare molto bene per utilizzare un bootloader inserito in un sistema operativo e non, come nel mio caso, per un "sofware specializzato" di terze parti.

L'aspetto "pratico" è che non mi piace affatto un sistema che - quando aggiorni certi componenti - si mette di sua volontà a riscrivermi l'MBR (operazione che giudico esposta ad un certo rischio). Ora ogni volta che succede (memore di vecchie "sorprese") devo preoccuparmi che Win7 sia ancora riavviabile   

Sotto l'aspetto "filosofico" confermo che  non mi piace affatto un linux che nei fatti replica il comportamento di Win (così tanto criticato!!!) nella gestione dell'MBR    . Questo sistema, secondo me, deve essere cambiato: la strada maestra resta - torno a dire - avvisarmi che se metto grub su /root posso avere guai. E basta. Non vorrei riconoscere esplicitamente che, almeno su questo punto,  "aveva ragione lui...." 

L'unico lato positivo è che con l'uscita definitiva della 10.10 quella riscrittura presumo sia solo episodica, ma anche questo mi resta una magra consolazione!

Ciao_ciao.

@gianmpu
temo che la logica del tuo workaround possa andare molto bene per utilizzare un bootloader inserito in un sistema operativo e non, come nel mio caso, per un "sofware specializzato" di terze parti.

Non conosco OSL2000, ma se è un boot manager che inserisce del codice nell'mbr, la gestione dovrebbe essere indipendente dal fatto che sia osl2000 o gag o altro. Il meccanismo del chainloading, infatti, serve solo per "passare il controllo" ad un codice di cui grub non sa nulla. Una volta passato il controllo, sarà il codice di osl2000 ad eseguirsi.

Se vuoi comunque usare il tuo bootloader, potresti usare un workaround. Prima di installare grub, fai una copia dell'mbr con dd mettendola in un file. Dopo che grub si è installato nell'mbr puoi inserire una voce nel menu di grub che fa il chainloading con il file contenente il bootloader esterno. In questo modo, ogni volta che grub si reinstalla, il boot loader esterno dovrebbe continuare a funzionare.

Sì. Infatti ho sempre due copie del MBR, una contenente grub e l'altra contenente il bootloader di Win ed entrambe si riferiscono alla stessa tabella delle partizioni, in modo da ripristinare il tutto all'occorrenza con dd. In questo caso ho lasciato fare per vedere se ci fosse qualche novità in seno a grub2 e controllare che grub-install funzionasse come in grub1 (non si sa mai... visto lo scempio demenziale che hanno fatto in grub2 circa la numerazione delle partizioni e dei dischi) -> meno male funziona come in grub1.
Tra l'altro, alcune voci di menu di grub2 (quella di slackware), non caricavano il relativo OS mandandolo in kernel panic...
Comunque, devono lasciare la libertà di installare o meno il bootloader... come era prima: di default lo installava nel MBR con possibilità di modificare la destinazione e con possibilità anche di non installarlo affatto.

Non conosco OSL2000, ma se è un boot manager che inserisce del codice nell'mbr, la gestione dovrebbe essere indipendente dal fatto che sia osl2000 o gag o altro. Il meccanismo del chainloading, infatti, serve solo per "passare il controllo" ad un codice di cui grub non sa nulla. Una volta passato il controllo, sarà il codice di osl2000 ad eseguirsi.

Si, magari hai ragione sotto il profilo strettamente teorico. Però - a parte la tecnica che dovrei scoprire per "chainloadare" osl2000 - il mio punto è che sarebbe sempre il grub2 di ubuntu 10.10 a stare nell'MBR ed essere costantemente aggiornato/riscritto. Ed è proprio questo che, come dicevo, non mi piace!

Ciao

Non conosco OSL2000, ma se è un boot manager che inserisce del codice nell'mbr, la gestione dovrebbe essere indipendente dal fatto che sia osl2000 o gag o altro. Il meccanismo del chainloading, infatti, serve solo per "passare il controllo" ad un codice di cui grub non sa nulla. Una volta passato il controllo, sarà il codice di osl2000 ad eseguirsi.

Si, magari hai ragione sotto il profilo strettamente teorico. Però - a parte la tecnica che dovrei scoprire per "chainloadare" osl2000 - il mio punto è che sarebbe sempre il grub2 di ubuntu 10.10 a stare nell'MBR ed essere costantemente aggiornato/riscritto. Ed è proprio questo che, come dicevo, non mi piace!

Ciao

Il mio workaround, infatti, serviva solo per permetterti di usare comunque osl2000. Ho immaginato, infatti, che la necessità di usare uno boot loader particolare fosse dettata dall'esigenza di far partire un sistema operativo che con grub ha qualche problema. 

@gianmpu
OK, ora ho capito perfettamente il tuo punto! .
La verità invece è che ho da sempre usato quel bootloader non per il problema che tu ipotizzavi, ma solo per gestire le partizioni nel  modo che a me pare più  flessibile/conveniente. (Tipo: se aggiungo/levo/riformatto/unisco partizioni linux, non ho da preoccuparmi di gestire il grub del sistema "master"...).

@tutti
pensate che le mie "preoccupazioni" sulla "frequente" riscrittura dell'MBR abbiano ragion d'essere ??       ???

Ciao!

Intanto, sempre su https://bugs.launchpad.net/ubuntu/+sour ... bug/445416 mi confermano che con 'sudo dpkg-reconfigure grub-pc' grub si reinstalla sempre su root. Appena ho voglia ci provo...

Ciao!

Ho installato ieri la RC.
Purtroppo confermo che non è proprio possibile NON installare grub. Manca infatti il segno di spunta "Non installare nessun boot loader" tipico delle precedenti versioni di ubuntu.
Questa cosa secca parecchio anche a me, visto che io uso normalmente grub1 installato nel mbr ma con i file di sistema di grub in un'altra partizione.

Anche io ho installato ieri la RC, ho scelto di installare il grub in sda6 ed ho potuto avviare Ubuntu col grub1, come sempre, con i comandi:

Codice: Seleziona tutto

title 10.10
kernel     (hd0,5)/boot/grub/core.img

Quando si sceglie, in fase di installazione, di installare il grub in una partizione logica, il grub viene installato parzialmente, viene popolata la cartella /boot/grub ma non viene scritto il primo settore della partizione (questo è possibile solo nelle partizioni primarie). Il grub1 è capace ugualmente di avviare tramite il core.img, probabilmente un altro bootloader non è in grado.

Il grub1 è capace ugualmente di avviare tramite il core.img, probabilmente un altro bootloader non è in grado.

Quello che qui si vede - e di cui ci si lamenta - è appunto che l'altro bootloader che, come dici, non è in grado di comportarsi come grub1   è proprio grub2, cioè lo standard per la 10.10....
 ???
Cioè, mi spiego meglio: è vero che grub2 si fa installare nella /root, ma poi, se si fa un aggiornamento del sistema  (il caso classico è il kernel) che prevede il lancio di "update-grub" allora ti ritrovi "d'autorità" sovrascritto l'MBR. (vedi anche la discussione su launchpad che citavo prima)
 (nono)

Ciao!

ho dato 5 minuti fa il sudo update-grub su maverick e non mi ha minimamente scalfito il mbr, è rimasto col grub1

Non so come commentare      se non rimandarti ancora una volta a quello che dicono qui:
https://bugs.launchpad.net/ubuntu/+sour ... bug/445416 (v. post #7 - #9). Tu invece mi pare che hai la situazione dei post #3 e #5.

Per capire meglio (e fare qualche ipotesi su quello che sta capitando) volevo chiederti:
1. In sede di installazione Maverick ti ha fatto scegliere dove installare? (o anche di non installare?). Devo dire che io in fase di installazione ho dimenticato questo passaggio   
3. la tua /dev/sda6 è primaria?
3. non hai mai avuto il seguente messaggio?:

Codice: Seleziona tutto

 grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged.

A fronte di quel messaggio, come dicevo prima, a me  si installa sulla boot partition (estesa) solo  forzando l'installazione stessa ("grub-install /dev/xx --force"). Da allora c'e' il fenomeno della "riscrittura" su MBR (presumo per via di quel "force" che non può fare "da solo").

Ciao!

1. In sede di installazione Maverick ti ha fatto scegliere dove installare? - SI
3. la tua /dev/sda6 è primaria? - è logica come tutte quelle > 4
3. non hai mai avuto il seguente messaggio?:-  NO - l'installazione è grafica, quindi niente messaggi

OK. Grazie mille.
A questo punto ho come la sensazione che tutto sia dipeso dal fatto che ho "scordato" di scegliere, in modalità grafica,  la partizione di installazione del bootloader al momento dell'installazione (ammesso che ci fosse la scelta nella alpha 3 di maverick che ho messo su...)


Ciao!

ho fatto 2 installazioni, sul fisso me lo sono scordato anche io, me lo aspettavo in fondo invece che all'inizio, però ho ripristinato il grub1 ed è su questo che ho fatto la prova del sudo update-grub.
Sul portatile invece ho installato il grub nella partizione logica e quindi non ho avuto bisogno di ripristinare niente, solo di modificare il menu.lst.
Comunque anche forzando il grub-install il primo settore della partizione non viene toccato, lo puoi verificare col comando

Codice: Seleziona tutto

sudo hd -v -n 512 /dev/sdaX

Scusa, Patel, non ti seguo su una cosa:
Come mai dici di aver ripristinato il grub1 quando mi pare che Maverick monti di default il grub2?
Ciao!

hai iniziato la discussione parlando di bootloader esterno, io ti ho detto che uso il grub1 e con quello gestisco l'avvio delle varie distro che ho e che hanno quasi tutte il grub2. Non era questo l'argomento della discussione ?