Re: Question on what sectors grub2 uses?

[Jordan Uggla]

On Fri, Mar 9, 2012 at 5:26 PM, Michael D. Setzer II
<address@hidden> wrote:
> I am the current maintainer of the G4L disk imaging project, and
> long ago added options to backup the basic mbr being the first
> 512 bytes of the disk. Later added an option that would backup
> the first track (63 sectors) of the disk to include additional code
> that was being placed there by some OSs.

Just for the record, the grub project pretty much always advocates the
use of grub-install for (re-)installing grub.

>
> In a recent clean install of Fedora 16 I noted that first partition is
> starting at 2048 instead of 63 from previous version.

This is for many reasons, the first of which is that partitions
aligned on a MiB boundary will give you better read and write
performance on modern disks. Any decent modern partitioning tool will
default to at least starting partitions on MiB boundaries. The second
is that grub's core.img can sometimes require more than 32K to be able
to read the rest of its files from /boot/grub/. This is usually
because /boot/ is on top of LVM/RAID/ZFS/BTRFS which requires more
code to understand than a simple ext4 partition. But again, there are
good reasons to leave more space in any case for proper alignment.

>
> What would be the necessary steps to backup the mbr and grub2
> info?
>
> dd if=/dev/sda of=mbrgrub2 bs=512 count=????
>
> Would it be 2048, 2047, or some other number?

It depends on where the first partition starts, and what was baked
into the core.img. Grabbing the entire post-mbr gap seems reasonable
to me, though I haven't heard of a configuration requiring a core.img
larger than 1 MiB. On BIOS based systems using GPT you'll also need to
save the BIOS Boot Partition and be sure to restore it to the exact
same sectors on disk (or, as recommended, use grub-install to
re-install grub).

>
> I also noticed I had some machines that were upgraded to Fedora
> 16, and had the grub2 installed, but it only had 63 sectors for the
> first partition to start which was XP. The grub2-install --recheck
> would report the area is now to small, but it was using the grub2
> boot process, so I assume that one time it did fit with an earlier
> grub2? With a lot of work, I was able to resize and move various

There were some reliability issues with some of grub's older LVM and
RAID handling which required more code to fix. So while later versions
of grub may need a larger core.img, it's for a good reason and that
new code can't simply be removed without reducing reliability.

> partitions over and free the space so the first partition started in
> 2048 and then the grub2-install --recheck ran with no problems
> and seems to be fine.
>
> My only big problem has been that I did a preupgrade on another
> systems recently to Feora 16, and it went thru fine, but on reboot
> it was still using the older grub instead of the grub2, and it was
> listing the old kernel that didn't exist any longer. Fortuantely, I had
> a kernel from my g4l project that was there, and it allowed me to
> boot and I was able to modify the old grub.conf and get it to boot.
> It appears that the preupgrade is not able to install the newer
> grub2 in the 62/63 sectors that were available? The boot partition

The more common problem people have is that the newer grub's boot
sector was installed to a different drive's MBR than the drive whose
MBR is read by the BIOS at boot. There isn't much that grub as a
project can do to prevent this problem.

> on that machine was 1024M, so I reduced it to 1023M and moved
> it over to free up the space. Then I ran the grub2-install, and it ran
> with no errors, but I have not actually rebooted the machine to test
> it???

I don't understand this question.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)