Hi,
just to understand...
I've ever known that in the last bytes of the MBR there is the partitions table. That is, the MBR is 512 bytes long, and in the last bytes (from 446 to 509) find place the partitions table (created by fdisk) (and in the last two bytes the magic mumber).
I found in the GRUB manual and tutorials, that its "stage1" file (the one to put in the MBR) is 512 bytes long, to fit the MBR. OK, but if the installation of the boot loader overwrite the first 512 bytes of the disk, this overwrite the partitions table too, doesn't it?
What step am I loosing?

"but if the installation of the boot loader overwrite the first 512 bytes of the disk, this overwrite the partitions table too, doesn't it?
What step am I loosing?"

Probably that the system reads a copy of the first sector, so it already knows what belongs there. It shouldn't be a surprise to learn that programmers take side-effects such as this into account in order to produce a working product.

No boot loader dares to overwrite the partition table. The code of stage1 actually stops at 446th byte if it is installed in the MBR.

The only known full application of the 512 bytes of stage1 is for writing on the floppy.

For writing on the MBR one must used the "grub-install" shell script which is part of the Grub build. Alternative it can be done in a Grub shell or a Grub prompt by the "root" + "setup" commands.

What you're missing is that the stage1 isn't "just copied" into the MBR. It needs to be tailored for *your* particular instance of installation. What partition the (other) stage files ultimately reside in, and on which disk are data that are contained in the boot loader record for example.

"No boot loader dares to overwrite the partition table. The code of stage1 actually stops at 446th byte if it is installed in the MBR."

While this is logically true, physically it is not. The smallest chunk of data that can be read or written to a disk is 512 bytes. Therefore, the partition table is actually overwritten when the MBR is saved. It's just that it is overwritten with the same data as it already had. There is some good information here: http://en.wikipedia.org/wiki/Partition_table

I see. I was a little confusing, because of a sentence I found, don't remember exatly where, if on the maual or other book, that stated something like "the MBR is 512 byte, that's the reason why the stage1 file is exatly 512 bytes" (and if you check the length of the stage1 file you can find with grub, it's true). Then, the manual tell how to create a bootable floppy by simply copying the stage1. So I assumed that also the installation copies that file on the MBR. But as saikee and syg00 say, I missed the installation is a more complex procedure, (not deeply described at a low level by the manual).
Thank you for your help

Our post crossed Quakeboy, I read you just now. Your observation is very very interesting!

Interesting but wrong.
I regularly "zap" the boot record by copying /dev/zero for some required number of bytes. Almost always less than 512.

A hard disk sector is 512 bytes long; not 327, not 513, but exactly 512 bytes.

Added:
From:http://www.schicktech.com/items.php?...76&itemid=1382

If you were to look under the covers, you would see the software first read the MBR, then rewrite it with the new data, thus not changing the partition table. Due to the way the data is stored physically on a hard disk (synchronous encoding) it is not possible to write only part of a sector. Software may fool you into thinking that's what you're doing, of course.

That fdisk reference is to the old M$oft (DOS) fdisk. Wash your mouth out ...

Thinking out what you said, it certainly sounded reasonable in the "normal" case. I'm currently seeing if I can make any sense of the source for "dd" to see if it always does a hidden read of the outfile for every block (which I think unlikely), or opens the disk as a "byte special" rather than block device in a case such as I described.
Could take a while - it's the Australia day long weekend, and the cricket has just started ...

"That fdisk reference is to the old M$oft (DOS) fdisk. Wash your mouth out"

Pass. I think you'll find that the location of the partition table hasn't changed since the first hard disk was made.

"I'm currently seeing if I can make any sense of the source for "dd" to see if it always does a hidden read of the outfile for every block (which I think unlikely)"

There's no reason it should. But it should do a hidden read if you're starting in the middle of a sector and probably if you end in the middle of one. Otherwise what does it do with the rest of the bytes? Why would zero-fill be the proper thing to do, especially on sector zero.

"or opens the disk as a "byte special" rather than block device in a case such as I described."

So, I assume you do understand the implications of byte special, then.


Consider the case of where you want to append to a file. You cannot actually seek to a byte position on a disk, you can only seek to the sector. If the data you want to append begins in the middle of a sector, then that sector has to be read, the data appended, and the sector written when the sector is full. This continues for each byte you append, though of course the device drivers etc take care of caching data rather than thrashing the disk for every single byte.

Consider the case where you want to change byte 1023 in a file. You can't simply rewrite that byte on the disk. The hardware can't do that. The disk is spinning around and it has a 512 byte synchronous block of data it has to deal with. But, you can read the second sector in the file, change the byte in the read buffer, and then write it back.

If we look at Awesomemachine's thread on how to use dd it has been established beyond doubt that we can write one byte or one word with dd.

dd defaults to write one complete sector of 512 bytes but the user can impose something different.

one can verify the dd command at any time
I donot know the details of how "grub-install" or "lilo -b" in Linux or "setup" in Grub is executed when the MBR is altered. The stage1 of GRub is 512 bytes long but the only reference it has for writing it out the full length of 512 bytes in the Grub Manual is for a floppy. We are only speculating here. However it is a fact that all major boot loaders (Grub, Lilo and NTLDR) when reinstoring the MBR are known not to alter the partition table.

"If we look at Awesomemachine's thread on how to use dd it has been established beyond doubt that we can write one byte or one word with dd."

I don't doubt that at all. But on the hardware level, there is no such thing as writing one byte. Software does a lot of nice stuff for us and lets us fool ourselves into thinking we know what's going on, sometimes.

continuing off-topic, they dug deeper and deeper into the nuances......

The implication of the above is that dd (or something below it) is copying and rewriting in 1-sector chunks. Can anyone describe exactly what happens if, for example, I tell dd to write just one byte?

Hard to see how that would be any kind of universal truth. Do you mean that disk drives are normally configured so they only write in larger chunks? If so, I'm betting that's a firmware function, not hardware.

"Hard to see how that would be any kind of universal truth. Do you mean that disk drives are normally configured so they only write in larger chunks? If so, I'm betting that's a firmware function, not hardware."

It's a function of the way the data is physically stored on the hard disk. It is not stored as 1 byte chunks. It is stored as 512 byte chunks. In an LBA_28 system (you guys have heard of that, right?), you have a limit of 137GB. How can this be, if 28 bits only defines a range of 0-268,435,456? As it turns out, 268,435,456 times 512 (the size of a sector) equals 137,438,953,472, i.e. the dreaded 137GB limit.

In summary, there is no way to address a single byte on a hard disk. What we do is to read a sector change the byte we're interested in, and then write the sector to the disk.