Problemi con MBR e s.o. proprietario

[shodan]

Ciao a tutti,

apro questo thread per avere una qualche opione sulla soluzione di un problema che sto affrontando.

Quello che devo fare è poter copiare una partizione contenente un s.o. proprietario, chiamato "Prologue", su un altro HD, in modo da poter farlo funzionare su un altro PC e/o tenerlo come copia di backup.
Ho avviato il PC con un livecd linux e ho dato un'occhiata alla tabella delle partizioni, che posso riassumere in:
-) hda1 - partizione win98 - FAT32 - circa 3GB - montata in /mnt/vfat;
-) hda2 - partizione prologue - filesystem sconosciuto - circa 700MB.
Il filesystem della seconda partizione ha id f5; cercando su google ho trovato che è un filesystem multi-volume il cui nome è TwinServer.

Putroppo non esistono driver che permettano a linux di montarlo; di conseguenza per poter copiare la partizione ho usato il caro vecchio dd. La sintassi del comando è stata: dd if=/dev/hda2 of=/mnt/vfat/image.img bs=<numero di byte per cilindro> count=<numero di cilindri della partizione>
Fatto questo ho ottenuto un file image.img che ho copiato su un altro PC; ho quindi cercato di ripristinare la partizione su un nuovo HD. Per farlo ho prima creato una partizione hdc1 da circa 700MB e quindi ho dato il comando dd if=image.img of=/dev/hdc1 (il nuovo disco è hdc). Fatto questo pare tutto OK, quindi riavvio. Al riavvio però il s.o. non viene trovato.

Dato che sulla macchina originale per avviare Prologue era necessario cambiare la partizione attiva tramite fdisk (da dos), la mia domanda è: ma win98 nell'MBR ci scrive un boot loader e non il kernel vero e proprio, giusto? Altrimenti come sarebbe possibile caricare il kernel contenuto in una partizione piuttosto che quello contenuto in un'altra? E ancora: il metodo di copia che ho utilizzato è corretto? Ho sbagliato qualcosa?

Ipotizzando che abbia fatto tutto correttamente, per caricare Prologue dal nuovo disco avevo pensato di mettere grub sull'MBR e quindi di utilizzare la tecnica del chainloader per caricare Prologue stesso, configurando appropriatamente grub (naturalmente creerò una partizione hdc1 necessaria a grub e Prologue finirà sulla partizione hdc2). Che ne dite?

Grazie a tutti per l'eventuale aiuto. :)

[ilsensine]

Da quello che descrivi immagino che quel s/o possiene un proprio loader, caricabile in chainloader. Vuol dire che il loader possiede la solita parte residente nei 512 byte dell' "MBR" della partizione (anche il loader di windows funziona così).
512 byte sono maledettamente pochi per caricare il resto del loader: saprai che lilo deve essere "rieseguito" ogni volta che modifichi lilo.conf, e quando installi grub devi indicare la posizione degli stage successivi. Questo perché in quei 512 byte hai appena lo spazio per caricare, tramite una chiamata al BIOS, un settore dell'HD. Non hai assolutamente possibilità di sfogliarti il file system alla ricerca del file. La posizione del "grosso" del bootloader, caricato nei 512 byte, deve essere in una parte fissa, inamovibile, del disco, e la sua posizione "hardcoded" nel mbr in fase di installazione (per questo un cp -a + una copia del mbr non è in grado di far funzionare grub -- occorre dd). Quindi non basta che fai una copia 1 a 1 della partizione: sulla partizione hdc1 i settori avranno una posizione diversa da quella che avevano su hda2.
In sostanza, per avere qualche speranza che funzioni, devi far sì che i settori nel disco di destinazione coincidano con la posizione originaria. Questo è relativamente facile se i dischi sono identici; ti faccio i migliori auguri se i dischi sono diversi.

[shodan]

Grazie dell'aiuto.

Come avrai notato, sono un po' ignorante in materia... :)

Allora, ricapitolando:
-) nell'MBR ci va sempre solo e soltato l'indirizzo del settore dell'HD da caricare; un kernel non ci entrerebbe assolutamente;
-) per quanto detto sopra, il bootloader non risiede direttamente nell'MBR ma da qualche altra parte.

La domanda che nasce allora è: dove risiedono kernel e bootoload? Quando uso lilo, una volta che lo installo i kernel tramite il comando "lilo", posso anche cancellare i kernel dalla partizione di boot, tanto al successivo riavvio verrà comunque caricato. Con grub invece questo non va: se cancello il kernel dall'HD grub non lo troverà né potrà caricarlo. Finora ho sempre pensato che lilo scrivesse l'intero kernel nell'MBR; ma dato che mi indichi che questi è grande solo 512 byte un kernel non ci entrerà mai a poi mai...

Altra domanda: quindi anche il DOS e Win9X hanno una sorta di bootloader... in pratica FDISK, attivando una partizione piuttosto che un'altra, va a scrivere nell'MBR l'indirizzo del kernel risiedente su una partizione piuttosto che su un'altra, giusto?

Quasi ultima domanda (per ora :p): per poter far funzionare il "giochino" che avevo intenzione di fare con DD, devo far in modo che all'avvio venga caricato un kernel / bootloader valido. Quello che avrei intenzione di fare è di creare 2 partizioni, mettendo nella seconda Prologue. A questo punto installerei grub e, con la tecnica del chainloader, andrei a caricare Prologue. Ma come faccio a capire se un s.o. usa un proprio bootloader (e quindi devo usare la tecnica del chainloader) oppure no (e qui il chainloader non dovrebbe servire, giusto?)? Nel caso che riuscissi infine ad arrivare al loader di Prologue, anche questo avrebbe codificato al suo interno i dati relativi ai settori da caricare; se quindi questi settori non combaciano con quanto presente davvero sul disco non funzionerebbe nulla, vero?

Ultima domanda (davvero!:D): se usassi HD diversi (l'originale è un HD 2,5'' da 3,2 GB), dovrei ricalcolarmi gli indirizzi dei settori dove risiede Prologue. Ipotizzando di ricreare le partizioni così come l'originale e posizionarle all'inizio del disco, la posizione dei settori sarebbe corretta oppure avendo il disco nuovo una diversa configurazione di settori / testine / traccie non riuscirei comunque a beccare i settori giusti?

Grazie mille! :)

[ilsensine]

Originariamente inviato da shodan
Quando uso lilo, una volta che lo installo i kernel tramite il comando "lilo", posso anche cancellare i kernel dalla partizione di boot, tanto al successivo riavvio verrà comunque caricato.
...finché i settori del disco utilizzati dal kernel che hai "cancellato" non verranno riutilizzati per qualche altro file.

Con grub invece questo non va: se cancello il kernel dall'HD grub non lo troverà né potrà caricarlo.
grub funziona in maniera diversa: al boot carica dei moduli in grado di leggere dal file system. Molto flessibile, e comodo.


Altra domanda: quindi anche il DOS e Win9X hanno una sorta di bootloader... in pratica FDISK, attivando una partizione piuttosto che un'altra, va a scrivere nell'MBR l'indirizzo del kernel risiedente su una partizione piuttosto che su un'altra, giusto?
Vediamo di chiarire anche questo punto.
In realtà esistono più settori di avvio. Uno è l'mbr vero e proprio, i primi 512 byte all'inizio del disco. Sono _questi_ che il bios carica ed esegue al boot. Poi in ogni partizione i 512 byte iniziali sono utilizzabili per un bootloader.
Quello che seccede con il loader di windows è questo: Il bios carica ed esegue l'MBR; il loader nel MBR quindi carica il settore di avvio della partizione marcata come "attiva" (partizione "attiva" è un concetto prettamente Microsoft), e lo esegue. In quel settore c'è il codice per caricare il resto del loader.
Grub/Lilo invece non hanno bisogno di questo doppio caricamento: i 512 byte di avvio possono stare indifferentemente nel MBR (nel qual caso vengono lanciati dal BIOS) oppure nel settore di avvio di una partizione (nel qual caso vengono lanciati da un altro loader; v. ad es. le tecniche per lanciare linux tramite il loader di win2k/XP). In quei 512 byte c'è il codice necessario per caricare il resto del loader, e/o il kernel. Quando indichi a lilo/grub di caricare windows o altro in "chainload", vuole semplicemente dire che devi caricare i 512 byte di avvio della partizione indicata, ed eseguirli.


Quasi ultima domanda (per ora :p): per poter far funzionare il "giochino" che avevo intenzione di fare con DD, devo far in modo che all'avvio venga caricato un kernel / bootloader valido. Quello che avrei intenzione di fare è di creare 2 partizioni, mettendo nella seconda Prologue. A questo punto installerei grub e, con la tecnica del chainloader, andrei a caricare Prologue.
Se attualmente usi il loader Microsoft, e marcando la partizione di Prologe come "attiva" il gioco funziona, funzionerà anche con grub in chainload. In effetti grub+chainload si comporta esattamente come il loader Microsoft, con la flessibilità in più di poter caricare da qualsiasi partizione, non solo da quella marcata come "attiva". Chiaro fin qui?


Nel caso che riuscissi infine ad arrivare al loader di Prologue, anche questo avrebbe codificato al suo interno i dati relativi ai settori da caricare; se quindi questi settori non combaciano con quanto presente davvero sul disco non funzionerebbe nulla, vero?
Tutto il problema sta qui: far combaciare i settori.


Ultima domanda (davvero!:D): se usassi HD diversi (l'originale è un HD 2,5'' da 3,2 GB), dovrei ricalcolarmi gli indirizzi dei settori dove risiede Prologue. Ipotizzando di ricreare le partizioni così come l'originale e posizionarle all'inizio del disco, la posizione dei settori sarebbe corretta oppure avendo il disco nuovo una diversa configurazione di settori / testine / traccie non riuscirei comunque a beccare i settori giusti?
Esattamente, i valori CHS devono combaciare.
Da esperimenti che ho compiuto in passato però posso dirti che le informazioni sulla "geometria", che da anni ormai sono valori puramente fittizzi, sono scritti anche nella tabella delle partizioni. Questo perché non esiste un modo univoco di descrivere una geometria, visto che ormai non indica più alcuna "geometria fisica" ma sono solo parametri fittizzi. Puoi anche modificarli tramite fdisk di linux, indicando quindi per lo _stesso_ disco geometrie alternative da usare, con il vincolo di utilizzare non più dello spazio del disco.
Questa geometria è quella effettivamente utilizzata dal s/o, e - sperabilmente - anche dal BIOS.
Mi segui fino a qui?

[shodan]

Originariamente inviato da ilsensine
...finché i settori del disco utilizzati dal kernel che hai "cancellato" non verranno riutilizzati per qualche altro file.

grub funziona in maniera diversa: al boot carica dei moduli in grado di leggere dal file system. Molto flessibile, e comodo.


Vediamo di chiarire anche questo punto.
In realtà esistono più settori di avvio. Uno è l'mbr vero e proprio, i primi 512 byte all'inizio del disco. Sono _questi_ che il bios carica ed esegue al boot. Poi in ogni partizione i 512 byte iniziali sono utilizzabili per un bootloader.
Quello che seccede con il loader di windows è questo: Il bios carica ed esegue l'MBR; il loader nel MBR quindi carica il settore di avvio della partizione marcata come "attiva" (partizione "attiva" è un concetto prettamente Microsoft), e lo esegue. In quel settore c'è il codice per caricare il resto del loader.
Grub/Lilo invece non hanno bisogno di questo doppio caricamento: i 512 byte di avvio possono stare indifferentemente nel MBR (nel qual caso vengono lanciati dal BIOS) oppure nel settore di avvio di una partizione (nel qual caso vengono lanciati da un altro loader; v. ad es. le tecniche per lanciare linux tramite il loader di win2k/XP). In quei 512 byte c'è il codice necessario per caricare il resto del loader, e/o il kernel. Quando indichi a lilo/grub di caricare windows o altro in "chainload", vuole semplicemente dire che devi caricare i 512 byte di avvio della partizione indicata, ed eseguirli.


Se attualmente usi il loader Microsoft, e marcando la partizione di Prologe come "attiva" il gioco funziona, funzionerà anche con grub in chainload. In effetti grub+chainload si comporta esattamente come il loader Microsoft, con la flessibilità in più di poter caricare da qualsiasi partizione, non solo da quella marcata come "attiva". Chiaro fin qui?


Tutto il problema sta qui: far combaciare i settori.




Fin qui tutto chiaro! Una sola domanda: ma ogni kernel per poter essere caricato ha bisogno di un bootloader oppure nei famosi 512 byte si potrebbe scrivere direttamente l'indirizzo dei settori in cui si trova il kernel stesso?


Esattamente, i valori CHS devono combaciare.
Da esperimenti che ho compiuto in passato però posso dirti che le informazioni sulla "geometria", che da anni ormai sono valori puramente fittizzi, sono scritti anche nella tabella delle partizioni. Questo perché non esiste un modo univoco di descrivere una geometria, visto che ormai non indica più alcuna "geometria fisica" ma sono solo parametri fittizzi. Puoi anche modificarli tramite fdisk di linux, indicando quindi per lo _stesso_ disco geometrie alternative da usare, con il vincolo di utilizzare non più dello spazio del disco.
Questa geometria è quella effettivamente utilizzata dal s/o, e - sperabilmente - anche dal BIOS.
Mi segui fino a qui?

E qui ho qualche dubbio... anche a me sembra di ricordare che la geometria indicata oggi sia solo fittizia (ho visto disci con 128 testine... mi sembra alquanto improbabile!). Tempo fa però un mio disco, dopo un upgrade del kernel, inizio a funzionare male... perdevo file, riavviavo e li ritrovavo ( :eek: ), ecc... così ho controllato con FDISK e ho visto che il nuovo kernel aveva riconosciuto male i parametri geometrici del disco. Settandoli a mano tutto è tornato OK. Quindi se la geometria è riconosciuta male, il disco non funziona bene, giusto? Ma di preciso, come vengono utilizzati dal s.o. e dal BIOS i parametri della geometria? I parametri fisici (quelli reali) li posso ottenere solo leggendo le specifiche del disco stesso? E perchè si usa un geometria fittizia piuttosto che quella reale?
Ultima domanda: indipendentemente dalla geometria, se prendo 2 dischi diversi e faccio su entrambi 2 partizioni da 2 GB (all'inizio del disco), il settore in cui inizia la 2° partizione sarà lo stesso su entrambi i disci?

Ti ho fatto un milione di domande... :D non vorrei abusare della tua gentilezza... se hai un link esplicativo posso studiarmelo direttamente!

Grazie mille! :)

[ilsensine]

Originariamente inviato da shodan
Fin qui tutto chiaro! Una sola domanda: ma ogni kernel per poter essere caricato ha bisogno di un bootloader oppure nei famosi 512 byte si potrebbe scrivere direttamente l'indirizzo dei settori in cui si trova il kernel stesso?
Nei 512 byte c'è un programma, non un indirizzo. Questo programma può fare cose semplici, come caricare l'mbr della partizione attiva o caricare e lanciare un settore che ha hardcoded.



E qui ho qualche dubbio... anche a me sembra di ricordare che la geometria indicata oggi sia solo fittizia (ho visto disci con 128 testine... mi sembra alquanto improbabile!). Tempo fa però un mio disco, dopo un upgrade del kernel, inizio a funzionare male... perdevo file, riavviavo e li ritrovavo ( :eek: ), ecc... così ho controllato con FDISK e ho visto che il nuovo kernel aveva riconosciuto male i parametri geometrici del disco. Settandoli a mano tutto è tornato OK.
Potrebbe essere stato un bug nel kernel. Linux accede ai dischi di default in LBA non in CHS.

Ma di preciso, come vengono utilizzati dal s.o. e dal BIOS i parametri della geometria?
Per leggere un settore, chiedi al disco quale settore leggere. Nei vecchi dischi si chiedeva direttamente l'indirizzo CHS; quelli "nuovi" (da parecchi anni a questa parte) consentono richieste in indirizzi lineari LBA, indipendenti dalla geometria. E' possibile convertire da CHS in LBA, ma non il viceversa (non in maniera univoca).


Ultima domanda: indipendentemente dalla geometria, se prendo 2 dischi diversi e faccio su entrambi 2 partizioni da 2 GB (all'inizio del disco), il settore in cui inizia la 2° partizione sarà lo stesso su entrambi i disci?
L'indirizzo LBA è uguale; quello CHS lo è solo se C e H sono uguali.


E perchè si usa un geometria fittizia piuttosto che quella reale?

Il CHS in realtà è morto da un pezzo, in quanto non è sufficiente per gestire dischi di grandi dimensioni. Si continua ad usarlo per compatibilità con standard vecchi di decenni.
Non dovrebbe essere affatto richiesto l'accesso al disco tramite i parametri di geometria; di questo si deve occupare il disco stesso. Su questo principio si basa l'LBA e l'LBA48.

http://www.storagereview.com/guide2000/ref/hdd/bios/modesLBA.html

[shodan]

Originariamente inviato da ilsensine
Nei 512 byte c'è un programma, non un indirizzo. Questo programma può fare cose semplici, come caricare l'mbr della partizione attiva o caricare e lanciare un settore che ha hardcoded.



Potrebbe essere stato un bug nel kernel. Linux accede ai dischi di default in LBA non in CHS.


Per leggere un settore, chiedi al disco quale settore leggere. Nei vecchi dischi si chiedeva direttamente l'indirizzo CHS; quelli "nuovi" (da parecchi anni a questa parte) consentono richieste in indirizzi lineari LBA, indipendenti dalla geometria. E' possibile convertire da CHS in LBA, ma non il viceversa (non in maniera univoca).


L'indirizzo LBA è uguale; quello CHS lo è solo se C e H sono uguali.


Il CHS in realtà è morto da un pezzo, in quanto non è sufficiente per gestire dischi di grandi dimensioni. Si continua ad usarlo per compatibilità con standard vecchi di decenni.
Non dovrebbe essere affatto richiesto l'accesso al disco tramite i parametri di geometria; di questo si deve occupare il disco stesso. Su questo principio si basa l'LBA e l'LBA48.

http://www.storagereview.com/guide2000/ref/hdd/bios/modesLBA.html

Grazie, ora è tutto molto più chiaro.

Quindi, dato che anche i BIOS possono utilizzare LBA, anche se avessi dischi con geometria fisica diversa (e così è), se "azzecco" il corretto indirizzo LBA il loader dovrebbe trovare il settore giusto.

E' corretto?

[ilsensine]

No; come la mettiamo se il loader fa una richiesta al BIOS in CHS?

[shodan]

Be, se la fa in CHS sicuramente non funziona... ma almeno un tentativo si può fare, dato che potrebbe anche fare la chiamata in LBA (anche se non credo, dato che il software è vecchissimo).

A proposito, ma tramite BIOS non è possibile convertire da CHS a LBA?

Ciao. :)

[ilsensine]

Uh? Non credo.

Per me dovresti fare così:
- annotati la geometria del disco di origine e di quello (presumibilmente più grande) di destinazione (fdisk -l)
- dd del disco _completo_
- sostituisci il disco destinazione, e controlla che parta
Quindi, con un live CD:
- usa fdisk per espandere il numero dei cilindri, fino a utilizzare tutto lo spazio disponibile (è tra le opzioni avanzate mi sembra). Ricorda che lo spazio da CHS, in byte, è C*H*S*512.
(riavvia con il disco così modificato per controllare che funzioni ancora)
- crea e formatta le nuove partizioni nello spazio ricreato
- formatta la prima partizione, che puoi recuperare installando un linux con grub. Configuri grub per lanciare in chainload la seconda partizione.

In teoria dovrebbe funzionare.

[shodan]

Ok, credo di aver capito.

Proverò (spero! :p) e vi farò sapere.

Grazie mille! :)