On Fri, Mar 9, 2012 at 5:26 PM, Michael D. Setzer II <[email protected]> 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) _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
