RE: How many sectors for GRUB 2

[Elliott, Robert (Server Storage)]

Starting a partition on LBA 63 (historically common for MBR) or LBA 34 
(historically common for GPT)  is a real bad idea for:
- HDDs implementing large physical sectors (e.g., 4 KiB)
- SSDs (page sizes are 4 KiB, 8 KiB, or larger)
- Logical drives presented by a RAID controller (strip sizes in powers of two 
ranging up to 256 KiB or even 1 MiB are common)

1 MiB is a simple choice that works well on all those types of storage.  You 
can retrieve more precise alignment tips from the SCSI Block Limits VPD page, 
but tuning the image for one drive could leave it non-optimal if image copied 
to another drive.

1 MiB may not be optimal for a RAID logical drive's stripe (with an "e") size, 
but that's a secondary concern to aligning to the strip size.


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ulf Zibis
Sent: Sunday, November 04, 2012 6:39 AM
To: Andrey Borzenkov
Cc: address@hidden; address@hidden
Subject: Re: How many sectors for GRUB 2


Am 04.11.2012 05:02, schrieb Andrey Borzenkov:
> В Sat, 03 Nov 2012 23:37:41 +0100
> Ulf Zibis <address@hidden> пишет:
>
>> Am 03.11.2012 18:05, schrieb Andrey Borzenkov:
>>> core.img is the part that is installed in MBR gap, but it does not
>>> mean that it was this particular file. grub-install creates core.img
>>> in /boot/grub and embeds it in the same run, but it is also
>>> possible to directly use
>>>
>>> grub-mkimage -o /tmp/foo.img ...
>>> grub-bios-setup -c /tmp/foo.img ...
>>>
>>> You wanted to be absolutely safe and sure. The only way to be is to
>>> reinstall grub using grub-install.
>> You mean, after I would have shrinked th MBR gap?
> No, before. Then you can be more or less sure it is the same file.

Ah thanks. I now understand what you wanted to say.
My focus  was only the question on how to determine the size of the used bytes 
in the MBR gap, not 
if they are exactly the same of /boot/grub/core.img.

>
>> That's the problem!
>> What will happen, if the gap is too small?
> grub-install will complaint and the only possibility will be to use
> block list (i.e. point boot sector directly to core.img on filesystem).
>
>> For that reason I *before* wanted to know how much space is needed.
>>
> To be honest, I do not understand what your goal is.

Well, after installing Windows 7 + Ubuntu on a new big (500 GB) harddisk, I was 
"disgusted" about 
the waste of 2048 sectors ahead the 1st partition, which I respect, that could 
be seen as nitpicking 
;-) This lead me to the assumption, that GRUB could use more than 62 sectors of 
the MBR gap if 
available, to avoid some kind of 2-step loading. Theoretically there could be a 
possibility to use 
GRUB without any dependency on an existing Linux installation/partition on the 
disk.
My initial goal was to manually shrink the MBR gap to the "usual" 63 sectors to 
avoid this "waste".
A 2nd goal: reducing the size of my MBR+GRUB backup. As you know, installing 
whatever Microsoft OS 
will destroy that data. So why saving 1 MiB (=2048 sectors) if ~26 kB are 
sufficient?
3rd: To my knowledge, some old OS, e.g. MS-DOS, require the old CHS alignment 
of sectors on the 
disk, where the maximum for a cylinder is 63 sectors. I suspect, if it is 
possible to install MS-DOS 
on a 2048-sector-aligned disk.
4th: the remaining space could be used for some other sophisticated purposes. 
This is not of my 
current interest, but theoretically may be for other people.

>> I tried:
>> your bootinfoscript
>> --> bootinfoscript.txt
>> your findgrub
>> --> findgrub.txt
>> Ubuntu's boot_info_script from Ubuntu Software Center
>> --> RESULTS.txt
>>
>> As you can see in the attachment, none of these provided the size of
>> the used bytes in MBR gap :-(
>>
> Yes, you are right. Hmm ... may be something to add. But it is not that
> trivial, it may also not be contiguous. Although I am not that sure how
> useful this information really is.

1.) see above.
2.) I had installed Ubuntu on a USB-pendrive. There the MBR gap was only 32 
sectors (=16184 Bytes). 
So I came to the assumption, that the hidden-sectors part of GRUB must be 
smaller than that, and the 
core.img file in the file system must be 2nd part of the GRUB bootstrap. And 
behind that, I wanted 
to check out, if I could additionally install Windows by help of Bart PE on the 
same pendrive, using 
GRUB as boot manager.

@ developers:

I do not understand, why all this information must be grabbed by a complicated 
error-prone script, 
instead of providing a command, maybe like "grub-info".

-Ulf


_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel