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: [email protected] [mailto:[email protected]] On Behalf Of Ulf Zibis Sent: Sunday, November 04, 2012 6:39 AM To: Andrey Borzenkov Cc: [email protected]; [email protected] 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 <[email protected]> пишет: > >> 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 [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
