grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How many sectors for GRUB 2


From: Ulf Zibis
Subject: Re: How many sectors for GRUB 2
Date: Sun, 04 Nov 2012 14:39:07 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]