The first 512 bytes of a hard drive (provided that the hard drive is
MBR-structured) form the MBR. (Master Boot Record). If you do "sudo dd
if=[device path of hard drive, possibly something like /dev/hda or /dev/sda]
of=/home/[user name]/Desktop/mbr_of_station72 [or some name you feel good with]
bs=512 count=1", that copies the MBR to a file on your desktop. But you won't
own the file, root will (because sudo was used). I then do a "sudo nautilus" or
"sudo pcmanfm" (or what ever your file browser is), to get a file browser
running as root, right-click the file, go to permissions, and set myself as
owner of the file, then close the root file browser.
The "if" stands for "input file" and the "of" stand for "output file". Yes,
there really is a file called sda (or hda or whatever) in you /dev folder. The
file is 0 bytes big, and whenever you write to it, the kernel intercepts that
write call and instead sends that data you tried to write to the file to the
hard drive, keeping the file at 0 bytes. Likewise, when you read from it, the
kernel intercepts that read call, and instead of reading from a file that
contains nothing, it sends data from the hard drive at you.
The "bs" is the block size. That says how much to read and then write at a
time. "count" says how many blocks of reading/ writing will be done. We want to
copy the first 512 bytes of data from the hard drive, so one block of 512 bytes
will do that. So we do "bs=512 count=1". "bs=256 count=2" would also work, but
technically would be a little slower. The less you copy at a time, the less
chance for an error, but it will take longer the less you copy at a time.
Here's an example:
sudo dd if=/dev/sda of=/home/addresshidden/Desktop/station0_mbr bs=512 count=1
But that's the whole MBR. You are only interested in the boot code of the MBR,
which is the first 440 bytes. So you could do something like this:
sudo dd if=/dev/sda of=/home/addresshidden/Desktop/station0_mbr_boot_program
bs=440 count=1
After the first 440 bytes is a 4 byte disk signature, followed by 2 bytes that
are usually all zeros (they just chill there), followed by 64 bytes that
comprise the partition table, which says where each partition begins and ends,
possibly marks one partition as "active", and also has a partition id for each
partition. The partition id is a serving suggestion as to what the partition is
to be used for. Examples of MBR partition ids: 83 is code for "this is a linux
partiton", 82 is code for "this is a linux swap partition", 0C is code for
"this is an LBA FAT32 partition", EE is code for "don't mess. This is a
GPT-structured hard drive. If you don't know how to handle GPT, just back away
now before it's too late.". And the last 2 bytes are 55 AA. They're always 55
AA. They just chill there. If the BIOS sees that the last 2 bytes of the MBR
aren't 55 AA, then it knows something's up, and won't continue booting the hard
drive.
So Grub2 stage one is the first 440 bytes. Correct me if I'm wrong and it is
actually the first 446 bytes (which would mean there is no disk signature and
those 2 chill bytes won't be zeros, is how it would work, I imagine).
Grub2 stage one's job is to load Grub2 stage 2, which is too big to fit in only
440 bytes.
On an MBR-structured hard drive, the next 62 sectors are up-for-grabs. The
first 63 sectors of an MBR-structured hard drive is referred to as track0. The
first sector is the MBR. The next 62 sectors are just up-for-grabs. There is no
standardised usage for that space. Anyone can write anything there. That is
where Grub2 stage 2 goes, if you have an MBR-structured hard drive.
In the case that your hard drive is GPT-structured, the first sector (512
bytes) is still an MBR. It contains only one partition in it's partition table,
which spans the entire hard drive and has a partition type of EE. So if an OS
doesn't know how to interpret GPT structuring, but still knows MBR structuring,
it will interpret the protective MBR as normal, see that there's one big
partition spanning the whole hard drive, and then back off. If it weren't for
the protective MBR, it would see the whole hard drive as unallocated space and
might be tempted to make some partitions on it and format them, demolishing
data you had on the drive.
But after that first sector on a GPT-structured disk, is the second sector,
which is the GPT header, followed by usually 32 sectors worth of partition
table entries. So Grub2 stage one can't start reading from the second sector to
the sixty-third sector to load Grub stage 2 in the case of a GPT disk, because
the second sector and the third sector and other sectors thereafter are in
other use. Important use. That space is taken, and Grub2 stage 2 can't occupy
the same space. So you actually make a special partition, called a BIOS boot
partition, just for storing Grub stage 2. You mark the partition for such
purpose by giving it a GPT partition id of EF02. (MBR partition ids are only
one byte long, like "EF", and GPT partition ids are two bytes long, like
"EF02".)
This is an example of extracting Grub2 stage 2 from a BIOS boot partition:
sudo dd if=/dev/sda3
of=/home/addresshidden/Desktop/grub2_stage2_from_bios_boot_partition bs=512
*that's where /dev/sda3 is the hardware abstraction file linked to the third
partition of sda. Replace with whatever your BIOS boot partition is.
Notice you don't supply a count. That means to keep copying off the partition
until the whole thing's been copied, which is what you want.
But with an MBR-structured hard drive, stage two is located in the wild,
untamed region from the second sector to the sixty-third sector. You can
extract it with something like this:
sudo dd if=/dev/sda
of=/home/addresshidden/Desktop/grub2_stage2_from_no_mans_land bs=512 skip=1
count=62
That tells dd to skip the first block (where a block is defined as 512 bytes by
"bs") and copy off 62 blocks, starting on the one we skipped to.
In case you start trying to replace Grub code to see if that takes the password
protection off, I'm moderately certain of the following:
So I don't believe you can copy and paste those first 440 bytes from any hard
drive with Grub2 to any other hard drive, and still have Grub2 work on the
destination hard drive. You can probably get away with copying them from one
MBR-structured hard drive to another MBR-structured hard drive because the
first 440 bytes of an MBR disk with Grub2 are programmed to look to the non-MBR
part of track0 for stage 2 to load (just make sure that Grub2 second stage is
in the non-MBR part of track0!), but the first 440 bytes of a GPT-structured
disk with Grub2 are programmed to look to a certain partition (specified by
number, i.e. partition 1, partition 2, etc.) to find and load Grub2 stage2. So
those 440 from a GPT-structured drive won't look to the non-MBR part of track0,
but rather to a certain partition. If that partition (specified by number, i.e.
partition 1, partition 2, etc.) doesn't exist or doesn't have Grub2 stage 2
raw-written to it on the destination
hard drive, those 440 bytes won't succeed on an MBR-structured drive. Even if
there was a partition with Grub2 stage 2 raw written to it on an MBR disk, and
even if the partition number of that partition matched the partition number of
the BIOS boot partition on the GPT disk that you copied those first 440 bytes
from (and thus is the partition that those 440 are programmed to look for),
that Grub2 stage one is programmed to look to the GUID partition table to find
that partition, not the MBR partition table, and wouldn't find the partition,
because MBR-structured hard drives don't have GUID partition tables (GPTs).
Also, going from one GPT-structured disk to another, one GPT disk might have
the third partition be the BIOS boot partition, another the 6th, another the
first. It could be any partition. So if you put the Grub2 second stage on the
3rd partition of a GPT drive, and you put a Grub2 stage one onto that drive
copied from a drive with it's 5th
partition as the Grub2 BIOS boot partition, Grub2 stage one will be looking to
the 5th partition for Grub2 stage 2, when it's actually on the third partition.
So just use grub-install to install grub to hard drives, ok? Then everything
will hunky-dory, and you won't have to do weird copy-pasting.
Also, if the filesystem of the partition containing the operating system is
encrypted, you will need the bootloader to be able to decrypt the filesystem to
load the kernel and initrd (initial ramdisk). Also, even if the filesystem
isn't encrypted, the actual kernel file and/or initial ramdisk file might be,
in which case the bootloader will need to be able decrypt it/them.
Anyways, once you have your bootloader dumps, you can view them in wxHexEditor.
wxHexEditor strictly requires libpng 1.2. So if you're more up-to-date than
that, you'll need to download and compile libpng1.2. "sudo make install" should
put it in /usr/local/lib. Then make a shortcut to the library in /usr/lib.
wxHexEditor will see the shortcut and use it. Launching wxHexEditor from
terminal without libpng 1.2 will tell you the exact file name of what it's
looking for. That will tell you what to name the shortcut and what you will be
shortcutting to to begin with. You can also use gHex, but I perfer wxHexEditor.
If you run wxHexEditor as root, you can view the hardware abstraction files
directly. Just be super-careful if you edit anything. In fact, I'd extract with
dd first, then edit. If it was a goof-up, then I just apply my dd dump back to
the disk to put it back how it was. Don't edit the original dumps. Keep them.
Another tactic is to not run any hex
editors as root, copy the dumps, edit the copies of the dumps, then use a
"sudo dd" to apply the edited dump copies back.
Further more, Grub stage 2 is programmed to look to a certain partition for
grub modules and grub.cfg. So you got to get all those files where Grub expects
them.
So there's really three parts to Grub: stage 1, stage 2, and files.
_______________________________________________
Help-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-grub
