Re: Question on what sectors grub2 uses?

[Michael D. Setzer II]

First, thanks for the detailed reply. 
Well place comments in message below.

On 10 Mar 2012 at 16:33, Jordan Uggla wrote:

From:                   Jordan Uggla <address@hidden>
Date sent:              Sat, 10 Mar 2012 16:33:42 -0800
Subject:                Re: Question on what sectors grub2 uses?
To:                     "Michael D. Setzer II" 
<address@hidden>
Copies to:              address@hidden

> 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.
> 

These are older machine, some of which were partitioned as long 
as Redhat 9. So, any that where upgraded from a CD or DVD or 
preupgrade would have the first partition starting at 63. 

I do generally recommend users of G4L do a full disk image 
backup, which gets everything, but with the new large disks this 
can take many hours, so users asked to bu able to backup the 
mbr and the actually system partitoins. 


> >
> > 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.
> 

That makes a lot of sense. I had used the LVM paritions for awhile 
when they came out, but I eventually went back to creating 
separate partitions on most machines, but the one I had the big 
issue with was still using LVM partitions for root and swap.

> >
> > 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).

Will have to do some testing and see if I can find more info. Don't 
have any GPT systems, so that is totally new ground.

> 
> >
> > 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.
> 

OK. Would have been nice it the preupgrade or dvd upgrade 
process would mention these things at the start. Would have been 
easier to make changes before. 

> > 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.
> 

Interesting. My systems are all single drive systems, or the one 
drive has the OSs, and other drives are extra data drives.

> > 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.

Actually, it wasn't a question in itself. Just that that process got rid 
of the message and seemed to work. So, it would appear that it 
resolved the issue. I was wondering if it did need the full 1024M or 
as you said earlier, that is due to partitioning using the 1M 
alignment? My first computer had an option to get a 20M hard 
disk back in 1983 for an extra $2000, but I got the dual floppy 
system instead. 

Again, Thank for the detailed info.

> 
> -- 
> Jordan Uggla (Jordan_U on irc.freenode.net)
> 
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub


+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:address@hidden                            
  mailto:address@hidden
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

address@hidden CREDITS
SETI        11907713.656842   |   EINSTEIN     7464888.469852
ROSETTA      4298461.658130   |   ABC         11599755.685299