Cosa scrive Grub nel settore di avvio per l'avvio di MBR?


1

Parte del processo di installazione di syslinux comporta l'installazione mbr.binsul record di avvio principale di un dispositivo.

dd \
  conv=notrunc \
  bs=440 \
  count=1 \
  if=/usr/lib/syslinux/mbr/mbr.bin \
  of=/dev/sdX

Se ripristino quei byte dal disco e li confronto con il mbr.binfile originale , sono identici.

$ sha512sum /usr/lib/syslinux/mbr/mbr.bin
3ba2bd96c7e5d81e...
$ dd bs=440 count=1 if=/dev/sdX | sha512sum
3ba2bd96c7e5d81e...

Fin qui tutto bene! Sembra logico che quei due checksum debbano essere identici.

Grub mi sembra un po 'più misterioso quando provo ad usarlo per realizzare lo stesso comportamento di Syslinux.

Facendo un po 'di svantaggio in dpkg-reconfigure grub-pcposso vedere che la mia grubinstallazione finisce per chiamarlo quando installa un nuovo bootloader ...

grub-install --target=i386-pc --force --no-floppy /dev/sdX

Eseguendo lo stesso grub-installcomando e aggiungendo --verbose, vedo che grub-installchiama grub-bios-setup.

grub-bios-setup \
  --verbose \
  --force \
  --directory='/boot/grub/i386-pc' \
  --device-map='/boot/grub/device.map' \
  '/dev/sdX'

Osservando alcuni dei sorgenti , penso che grub-bios-setupsia ciò che è responsabile della scrittura nell'MBR, perché se azzerare i primi 512 byte poi rieseguire grub-bios-setup, vedo quei byte ripristinare quelli che erano prima di averli azzerati.

Sfortunatamente, non capisco abbastanza bene il codice per capire totalmente da cosa viene scritto grub-bios-setup.

Ho avuto qualche sospetto. Penso che parte di ciò che è scritto abbia a che fare con boot.img. In effetti, se confronto determinati byte dal mio settore di avvio e boot.imgsono uguali (nota, il numero totale di byte letti qui è 440).

$ skip=104 count=336; \
  sudo dd if=/boot/grub/i386-pc/boot.img \
    skip=$skip bs=1 count=$count 2>/dev/null | sha512sum ; \
sudo dd if=/dev/sdX \
    skip=$skip bs=1 count=$count 2>/dev/null | sha512sum

e531a81fd3eedb324a9...
e531a81fd3eedb324a9...

Hanno somiglianze, ma non sono del tutto uguali. I primi 104byte differiscono e non riesco a capire quali siano le cause di tale differenza.

Esiste un mbr.bintipo di file comparabile per Grub? È vero boot.img? Grub modifica quindi alcuni di quei byte? Grub sta generando al volo quei byte diversi? Questi byte generati da Grub sono specifici per ciascun sistema e unici ogni volta che Grub li scrive?


Ho provato a guardare il mio sistema per vedere cosa usa, ma ... sono passato a EFI qualche tempo fa.
Ignacio Vazquez-Abrams,

Risposte:


1

Sì, boot.imgviene scritto nei primi 440 byte dell'MBR. boot.imgcontiene un "BIOS Parameter Block", che contiene dati che dipendono dal sistema su cui è installato. Questi dati vengono scritti nel BPM quando è installato Grub. Ecco il codice sorgente.

A proposito, non passerei molto tempo su GRUB. Questo codice probabilmente non verrà eseguito su nuovi PC tra un paio d'anni. Intel prevede di sbarazzarsi della modalità BIOS legacy entro il 2020.


Grazie per quelle informazioni! Quando dici "Questi dati vengono scritti nel BPM quando è installato Grub", vuoi dire che i dati BPB sono derivati ​​/ scritti nel momento in cui Grub è installato nell'MBR? Quindi eseguire qualcosa come i grub-installrisultati nel BPB specifico del sistema e il generico boot.imgcombinato in quei 440 byte nell'MBR? O vuoi dire che BPB è scritto quando i binari / pacchetto Grub sono installati sul sistema host?
Will Haley,

E so che EFI è il modo moderno / corretto di fare le cose ora, ma non mi rendevo conto che il BIOS legacy aveva una scadenza un po '. Buono a sapersi quella data 2020. Grazie!
Will Haley,

Quando è installato Grub, il programma di installazione legge boot.imgin memoria e lo mette in pausa prima di scriverlo sul disco come nuovo MBR. I dati provengono da due origini diverse: il BPM e la tabella delle partizioni vengono letti dal disco e alcuni vengono generati al volo, come l'unità di avvio (offset 0x64) e kernel_sector (offset 0x5c). Anche due byte di istruzione vengono cambiati in NOP, se necessario. Il BPM non è presente nell'MBR, ma i byte corrispondenti vengono comunque copiati.
Johan Myréen,

Intel ha annunciato la scadenza del 2020 alla fine del 2017, ma non avrei trattenuto il respiro. D'altra parte, vedo il dumping del BIOS come una cosa positiva a lungo termine, poiché la coesistenza di BIOS e UEFI sta causando molta confusione.
Johan Myréen,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.