How to boot the MBR of an secondary disk with GRUB?

I want to boot the MBR of my second internal hard disk drive. Is this possible with GRUB?
It is very annoying press F12 all the time to get to the MultiBoot Selection Menu and boot manually from the second drive. :
Is there a way to to that. Boot from MBR.

Of course, I won’t change the boot order in BIOS, I’m using openSUSE more than Mac, but I want a menu entry in GRUB for Mac.

Questions and Answers:

Why you want to do that?
I want to boot the Darwin/Chameleon Boot Loader that is stored in the MBR of my second disk drive.
I only can use this boot loader to boot Hackintosh OS X. GRUB won’t boot MacOSX. :’(

I think you can boot it the same way as you would boot Windows. That is, you would use a chainloader.

Maybe something like this will work:


    rootnoverify (hd1,0)
    chainloader +1

Whether that actually does what you want would depend on whether the code in that secondary MBR is able to handle the fact that it is running from the second disk.

The way “lilo” used to do this, was to use one of the changable BIOS entry points, and insert a small code segment that logically swaps the first and second disks. I don’t know grub well enough to know if it can do the same thing.

I am pretty sure the only way to boot from the MBR is by setting that disk as the first boot drive in your BIOS. Grub will allow you to then boot from any partition anywhere in your disk/partition collection. Essentially, the Grub Boot loader would be acting just like what the MBR does in then booting from an active partition. If the operating system can not be loaded by directly booting from a partition, then you must set that disk as first in your BIOS setup. Consider you would have the same problem if you are “booting” openSUSE from a Logical partition numbered 5 or higher. That only works if Grub is in the MBR and you have booting from that disk that contains the Grub boot loader.

Thank You,

Its not necessary to do so in BIOS, although it is likely cleaner if this is the only boot drive.

I currently have openSUSE-11.4, Tumbleweed-11.4 on sda and openSUSE-12.1 M2 on sdb. The mbr on sda has the PC boot the openSUSE-12.1 M2 partition on sdb. This (IMHO) is very messy, but it works. Its messy to boot Tumbleweed 12.1 (on sda) but clean to also boot openSUSE-11.4 (on sda).

Let me explain:

Here is my “fdisk -l” output:


stonehenge01:/home/oldcpu # fdisk -l

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bcd34

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63     1044224      522081    6  FAT16
/dev/sda2   *     1044225    52243379    25599577+  83  Linux
/dev/sda3        52243380    54283634     1020127+  82  Linux swap / Solaris
/dev/sda4        54283635   625137344   285426855    5  Extended
/dev/sda5        54283698   515076029   230396166   83  Linux
/dev/sda6       515076093   566275184    25599546   83  Linux
/dev/sda7       566275248   625137344    29431048+  83  Linux

Disk /dev/sdb: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders, total 320173056 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00070b93

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048    52436991    26217472   83  Linux
/dev/sdb2        52436992   104871935    26217472   83  Linux
/dev/sdb3       104871936   110446591     2787328   82  Linux swap / Solaris
/dev/sdb4       110446592   320172031   104862720    f  W95 Ext'd (LBA)
/dev/sdb5       110448640   215302143    52426752   83  Linux
/dev/sdb6       215304192   320143359    52419584   83  Linux

Note /sda2 is openSUSE-11.4. Note /sda6 is Tumbleweed-11.4. Note sdb1 is openSUSE-12.1 M2. By default the PC will boot openSUSE-12.1 M2, where this is the 12.1 M2 menu.lst:


# Modified by YaST2. Last modification on Thu Jun 23 10:26:17 CEST 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0
timeout 8
gfxmenu (hd1,0)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 12.1 Milestone 2 - 2.6.39-2
    root (hd1,0)
    kernel /boot/vmlinuz-2.6.39-2-default root=/dev/disk/by-id/ata-Maxtor_6Y160P0_Y4319JDE-part1 resume=/dev/disk/by-id/ata-Maxtor_6Y160P0_Y4319JDE-part3 splash=silent quiet showopts vga=0x317
    initrd /boot/initrd-2.6.39-2-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 12.1 Milestone 2 - 2.6.39-2
    root (hd1,0)
    kernel /boot/vmlinuz-2.6.39-2-default root=/dev/disk/by-id/ata-Maxtor_6Y160P0_Y4319JDE-part1 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317
    initrd /boot/initrd-2.6.39-2-default

###Don't change this comment - YaST2 identifier: Original name: Linux other###
title Linux other
    rootnoverify (hd0,1)
    chainloader +1

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Floppy
    rootnoverify (fd0)
    chainloader +1

If I choose 12.1 on (hd1,0) it boots !

If choose the “Linux other” it brings me to the grub boot menu.lst for /sda2, which gives me a choice of /sda2 (openSUSE-11.4) or /sda6 which brings me to the grub menu of Tumbleweed-11.4. I can boot Tumbleweed-11.4 from that.

I tried to add Tumbleweed-11.4 (on sda6) direct to the menu.lst of openSUSE-12.1 M2 (where that file is on sdb1) but that does not work. I get a memory (?) or out of range error(?) when I try to go direct to my Tumbleweed-11.4 (on sda6). I need to reach sda6 via the menu.lst on sda2. Sound confusing? Well yes it is confusing because I am confused, even though it works.

So this CAN be made to work, but it requires knowledge that is superior to what I currently possess to explain. I can only say I have it working, but not explain why nor how.

Actually, it works fine if you copy the first sector of that logical partition to a file, and then make an entry in the Windows boot manager to boot that file. You can do that without putting grub in the MBR.

I don’t know but I think we are confused as to just what the MBR (Master Boot Record) does. Here is a pointer to its description.

Master boot record - Wikipedia, the free encyclopedia

In simple terms, the MBR takes boot control directly from the PC BIOS. It then allows the booting of an operating system from any Active Primary partition, located on the same disk as the MBR. It (the MBR code) is just smart enough to locate the boot sector in one of the four primary partitions and turn over control of the PC to that partition boot loader. Since the MBR is very small, any additional functionality is achieved by being able to locate addition boot code located elsewhere on the disk. Such as the Grub boot loader being able to “boot” openSUSE when located in a logical partition. Then ANY operating system that can be loaded directly from its primary partition (such as Windows or openSUSE), without the need of special functionality located in the MBR, can be booted from the grub boot loader located on ANY disk partition without reading another MBR.

Now consider in reverse the standard MBR Windows lays down. I know that there are differences between Windows versions, but it can and will boot any Operating System that is in one of the first four primary partitions that is marked active even and including the grub boot loader when loaded into a primary partition. However, that standard Windows MBR can not load openSUSE when it is installed in a logical partition without loading grub from a standard primary partition. Further, none of the MBR setups I know of can launch the loading of another disk MBR. And in any event, the Grub boot loader does not do that, but generally it does not need to boot the MBR from another disk to load Windows or to load a copy of Linux. If there were some OS loader, like Grub, that could load Windows from a logical partition, then grub would be unable to duplicate that ability I would imagine if it could only work by loading another special MBR. That would require that the PC BIOS be set to boot from that disk. Now there are other boot managers out there and it is hard to say what functions they may have, but normally they do not boot a second time from the MBR and generally, there is no need to do so.

Thank You,

Sigh!

You are making it too complicated. What the MBR does is very simple. “Booting the MBR” is meaningful, but it might not achieve what the original poster wanted, namely to boot his MacOS.

What is probably needed, is for something to fool MacOS into reading from the second disk when it thinks it is reading from the first disk. I don’t know whether grub has an option for that. When you switch boot disks in the BIOS, the BIOS sets itself up so that every BIOS read from the first disk actually goes to the second disk, thereby suitably fooling whatever you are trying to boot from the second disk. LILO did have an option to install a small BIOS overlay to do this. The typical BIOS is designed to allow the use of a small overlay.

Grub can boot everything from any harddisk and doesn’t care. Some (unix) systems might not boot from other than the 2 first HDS, but this wouldn’t be Grub’s fault anymore. You can use updategrub](http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/advanced-how-faq-read-only/458238-updategrub-opensuse-legacy-grub-not-update-grub.html#post2329167) to add any kind of Linux kernel and chainload boot entries as well as Windows and other custom boot entries (not necessarely chainload ones) for odd operating systems in /etc/updategrub/customs (in a similar way that Ubuntu’s update-grub does by reading /etc/grub.d/40_custom). I’ve tried to learn from update-grub and work around some os-prober ‘bugs’. IMHO updategrub for Legacy Grub is better (in term of selecting and adding boot entries) than update-grub on Grub2 and is more configurable. By default it will add chainload entries for all other Grubs found on any partition or MBRs of any hard disk. If you don’t want it to add chainload entries, you can set/uncomment the following in /etc/updategrub/defaults:

CHAINLOADGRUB=no

But you should NOT, because chainload entries are the safest of all. They will still work after any kernel update (kernel boot entries won’t and you would have to run updategrub again to refresh the menu). By the way - this is a typical openSUSE bug/feature - ‘foreign’ kernel boot entries will be removed after a kernel update on the openSUSE side. We’ve been after this bug for a long time and I guess I found the culprit (details are here: updategrub for openSUSE Legacy Grub (not update-grub!)). The work around I provided is not a good solution (as it won’t prevent openSUSE to update its own kernel entries even if it won’t destroy any other). The purpose of this post was only to describe what happens and how it could possibly be fixed.

To add boot entries simply use (of course as root) :

updategrub

To use an interactive menu:

updategrub -i

To just display the list of boot entries without adding them:

updategrub -l

Here’s updategrub -l ouptut on this computer - from Arch Linux with Grub is installed in a logical partition bootsector (sda15):

Scanning...
Following boot entries could be added to Grub menu:

# Ubuntu 10.10 (10.10) on /dev/sda6
title Ubuntu 10.10 (maverick) - kernel 2.6.35-30-generic
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.35-30-generic root=UUID=5adac0e4-5c27-4292-a8dc-cd86cb806951 ro vga=794
    initrd /boot/initrd.img-2.6.35-30-generic

# Ubuntu 10.10 (10.10) on /dev/sda6
title Ubuntu 10.10 (maverick) - kernel 2.6.35-28-generic
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.35-28-generic root=UUID=5adac0e4-5c27-4292-a8dc-cd86cb806951 ro vga=794
    initrd /boot/initrd.img-2.6.35-28-generic

# openSUSE 11.4 (x86_64) on /dev/sda11
title openSUSE 11.4 (Celadon) - kernel 2.6.37.6-0.5 (Desktop)
    root (hd0,10)
    kernel /boot/vmlinuz-2.6.37.6-0.5-desktop root=/dev/disk/by-uuid/86949758-5b38-4f29-9f03-da0b2c055b8e resume=/dev/disk/by-uuid/ba9db764-a47e-48d9-b6f9-b627b57c0287 splash=silent quiet showopts vga=0x31a
    initrd /boot/initrd-2.6.37.6-0.5-desktop

# Mandriva Linux 2010.2 (2010.2) on /dev/sdb6
title Mandriva 2010.2 (Farman) - kernel 2.6.38.8
    root (hd1,5)
    kernel /boot/vmlinuz BOOT_IMAGE=linux root=UUID=4ecf3517-c7e9-47a1-8930-13a4e188e730 resume=UUID=ba9db764-a47e-48d9-b6f9-b627b57c0287 splash=silent vga=794
    initrd /boot/initrd.img

# Mandriva Linux 2010.2 (2010.2) on /dev/sdb6
title Mandriva 2010.2 (Farman) - kernel 2.6.38.8 (desktop)
    root (hd1,5)
    kernel /boot/vmlinuz-2.6.38.8-desktop-69mib BOOT_IMAGE=2.6.38.8-desktop-69mib root=UUID=4ecf3517-c7e9-47a1-8930-13a4e188e730 resume=UUID=ba9db764-a47e-48d9-b6f9-b627b57c0287 splash=silent vga=794
    initrd /boot/initrd-2.6.38.8-desktop-69mib.img

# Debian GNU/Linux (squeeze/sid) on /dev/sda19
title Debian GNU/Linux - kernel 2.6.32-trunk-amd64
    root (hd0,18)
    kernel /boot/vmlinuz-2.6.32-trunk-amd64 root=UUID=30eac80e-8574-46fb-a4ee-ec2a2ee453f9 ro
    initrd /boot/initrd.img-2.6.32-trunk-amd64

# Debian GNU/Linux (squeeze/sid) on /dev/sda19
title Debian GNU/Linux - kernel 2.6.32-3-amd64
    root (hd0,18)
    kernel /boot/vmlinuz-2.6.32-3-amd64 root=UUID=30eac80e-8574-46fb-a4ee-ec2a2ee453f9 ro
    initrd /boot/initrd.img-2.6.32-3-amd64

# Windows NT/2000/XP (loader) on /dev/sda1
title Windows NT/2000/XP (loader) - added by updategrub
    rootnoverify (hd0,0)
    chainloader +1

# Windows NT/2000/XP (loader) on /dev/sdb1
title Windows NT/2000/XP (loader) - added by updategrub
    map (hd1) (hd0)
    map (hd0) (hd1)
    rootnoverify (hd1,0)
    chainloader +1


# Grub on sda MBR
title Grub2 in sda MBR
    rootnoverify (hd0)
    chainloader +1

# Grub on sdb MBR
title Legacy Grub in sdb MBR
    rootnoverify (hd1)
    chainloader +1

# suse-Grub on /dev/sda11
title suse Grub on /dev/sda11 
    root (hd0,10)
    chainloader +1

# mandrivalinux-Grub on /dev/sdb6
title mandrivalinux Grub on /dev/sdb6 
    root (hd1,5)
    chainloader +1

# debian-Grub on /dev/sda19
title debian Grub on /dev/sda19 
    root (hd0,18)
    chainloader +1

# Legacy Grub on /dev/sdb4
title Legacy Grub on /dev/sdb4 
    root (hd1,3)
    chainloader +1

# Legacy Grub on /dev/sda4
title Legacy Grub on /dev/sda4 
    root (hd0,3)
    chainloader +1

# Grub2 on /dev/sda6
title Grub2 on /dev/sda6 
    root (hd0,5)
    kernel /boot/grub/core.img
    boot

# OpenBSD on (hd0,1) - /dev/sda25
title OpenBSD 4.7
    rootnoverify (hd0,1)
    makeactive
    chainloader +1

# NetBSD on (hd0,2) - /dev/sda31
title NetBSD 5.0.2
    rootnoverify (hd0,2)
    makeactive
    chainloader +1

# FreeBSD on (hd0,2) /dev/sda28
title FreeBSD 8.1
    rootnoverify (hd0,2)
    makeactive
    chainloader +1

# DragonflY on (hd0,1)
title DragonFly 2.4.1 
    rootnoverify (hd0,1)
    makeactive
    chainloader +1

# FreeBSD on (hd0,1) 
title FreeBSD 8.0 - alt
    rootnoverify (hd0,1)
    makeactive
    chainloader +1

# FreeBSD on (hd1,2) /dev/sdb20 
title FreeBSD 7.2 - alt
    rootnoverify (hd1,2)
    makeactive
    chainloader +1

# OpenBSD on (hd1,1) - /dev/sdb17
title OpenBSD 4.7 - alt
    rootnoverify (hd1,1)
    makeactive
    chainloader +1

# NetBSD on (hd1,2) - /dev/sdb24
title NetBSD 5.0.2 - alt
    rootnoverify (hd1,2)
    makeactive
    chainloader +1

Different kinds of entries and how they were added:

  • blue: all Linux kernel entries found on other partitions (detected by os-prober and read by linux-boot-prober), parsed and added by updategrub
    notice that failsafe, recovery and single user mode boot entries are ignored by default (but could be added by setting NOFAILSAFE=no in /etc/updategrub/defaults).
  • green: Windows boot entries. updategrub will apply device mapping (as in the second entry) in Windows is not on the first HD.
  • red: chainload entries for both Grub2 and Legacy Grub wherever they are. Those are added by updategrub directly (in a similar way findgrub
    would display them)
  • grey: any other entries written from /etc/updategrub/custom will be appended.

I’ll double check my BIOS to ensure my understanding as to what is functioning in my (sandbox) PC is correct and repost once I have confirmed my facts.

@SoftHacker
Can you not use rEFIt on Mac hardware? That’s what I use to dual or triple boot on iMacs. iMacs have a single HD though, but I guess rEFIt should be able to handle that. Grub should be installed in openSUSE’s partition boot sector and NEVER in MBR. rEFIt will present you with the choice of booting Mac OSX or Linux (actually Grub).

I just confirmed, and this is in line with please_try_again’s post.

On my PC the 1st boot drive is sda. The active partition on sda is sda2. But never the less, when I boot the PC, the very first grub menu I see is the menu.lst from sdb1. And that tells me that the MBR on sda points to partition on sdb1. That’s the only thing that makes sence to me.

I don’t think < ??? > I have this wrong.

Well now we have all of the Master Booters here it would seem. lol!

I think that we all are able to get our PC’s to boot using Grub in any manner that we so desire. My only last word is there is but one Master Boot Record per hard disk. The PC BIOS is solely responsible to boot from the MBR. Every Active Primary Partition also includes a boot sector, its just not the Master Boot Record. In Grub you always point it to a partition as in (h?,x) and NOT just (h?), right? This means you are booting from a partition boot sector, at least in the case of chain loading anyway and not the MBR. Loading a kernel does operate in a different manner which is why we have grub. This was my only point of this. Please forgive me for stirring up a bees nest here. The brain power in this one thread boggles the mind over a simple subject such as the MBR.

Thank You,

That’s the kind of question findgrub could easily answer by showing all the Grub stage1 (in red below) and where they look for stage2 (or Grub2’s core) (including menu.lst - in blue below):


Find Grub Version 3.0.1 - Written for openSUSE Forums


 - reading MBR on disk /dev/sdb                    ... --> Grub  found in sdb MBR     => sda11  0x83 (openSUSE)
 - searching partition /dev/sdb1   (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sdb1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sdb1
    rootnoverify (hd1,0)
    chainloader +1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sdb2   (FreeBSD)      
 - skipping partition  /dev/sdb3   (FreeBSD)      
 - reading bootsector  /dev/sdb4   (Extended)      ... --> Grub  found in /dev/sdb4   => sdb6   0x83 (Mandriva)
 - skipping partition  /dev/sdb5   (swap)         
 - reading bootsector  /dev/sdb6   (LINUX)         ... --> Grub  found in /dev/sdb6   => sdb6   0x83 (Mandriva)
 - reading bootsector  /dev/sdb7   (LINUX)         ...
 - reading bootsector  /dev/sdb8   (LINUX)         ...
 - reading bootsector  /dev/sdb9   (LINUX)         ...
 - reading bootsector  /dev/sdb10  (LINUX)         ...
 - reading bootsector  /dev/sdb11  (LINUX)         ...
 - reading bootsector  /dev/sdb12  (LINUX)         ...
 - reading bootsector  /dev/sdb13  (LINUX)         ...
 - reading MBR on disk /dev/sdc                    ...
 - reading MBR on disk /dev/sda                    ... --> Grub2 found in sda MBR     => sda6   0x83 (Ubuntu)
 - searching partition /dev/sda1   (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    makeactive
    chainloader +1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sda2   (FreeBSD)      
 - skipping partition  /dev/sda3   (FreeBSD)      
 - reading bootsector  /dev/sda4   (Extended)      ... --> Grub  found in /dev/sda4   => sda11   0x83 (openSUSE)
 - skipping partition  /dev/sda5   (swap)         
 - reading bootsector  /dev/sda6   (LINUX)         ... --> Grub2 found in /dev/sda6   => sda6    0x83 (Ubuntu)
 - reading bootsector  /dev/sda7   (LINUX)         ...
 - reading bootsector  /dev/sda8   (LINUX)         ...
 - reading bootsector  /dev/sda9   (LINUX)         ...
 - reading bootsector  /dev/sda10  (LINUX)         ...
 - reading bootsector  /dev/sda11  (LINUX)         ... --> Grub  found in /dev/sda11  => sda11   0x83(openSUSE)
 - reading bootsector  /dev/sda12  (LINUX)         ...
 - reading bootsector  /dev/sda13  (LINUX)         ...
 - reading bootsector  /dev/sda14  (LINUX)         ...
 - reading bootsector  /dev/sda15  (LINUX)         ... --> Grub  found in /dev/sda15  => sda15   0x83 (Mandriva)
 - reading bootsector  /dev/sda16  (LINUX)         ...
 - reading bootsector  /dev/sda17  (LINUX)         ...
 - reading bootsector  /dev/sda18  (LINUX)         ...
 - reading bootsector  /dev/sda19  (LINUX)         ... --> Grub  found in /dev/sda19  => sda19   0x83 (Mandriva)
 - reading bootsector  /dev/sda20  (LINUX)         ...

Press <enter> to Exit findgrub... 


The info about the OS inside parentheses is not very reliable but the one about the partition containing stage2 is correct. If you install Grub in the Linux root partition (or /boot) , both stage1 and stage2 are located on the same partition (like in most of the above entries).

No. You can chainload a MBR as well (if it contains a boot manager code like Grub). From my example in post #8:

# Grub on sda MBR
title Grub2 in sda MBR
    rootnoverify **(hd0)**
    chainloader +1

# Grub on sdb MBR
title Legacy Grub in sdb MBR
    rootnoverify **(hd1)**
    chainloader +1

You can boot Grub in MBR, then chainload Grub in a partition or in the MBR of another disk, then call the first Grub back and boot in circle all night long. I do that often when I’m depressed. lol!

Oh, I see, you’re actually running OS X on PC hardware, right? Try to add something like that in your Grub menu:

###Don't change this comment - YaST2 identifier: Original name: MacOSX###
title Mac OS X on second HD
    rootnoverify (hd1)
    chainloader +1

It will load the bootcode (assuming there is one) from your second HD’s MBR. I don’t know if it’s going to work, since I never used OS X on PCs (I’m not even sure it’s legal, but that’s another problem). I know it works with different BSD bootloaders in MBR that I have been using in the past.

If it doesn’t work, you might try to read 2 sectors instead of one:


    chainloader +2

I know NOTHING about Hackintosh though. Could you please report if it works?

I have never seen (or ever used) these options before:


# Grub on sda MBR
title Grub2 in sda MBR
    rootnoverify (hd0)
    chainloader +1

# Grub on sdb MBR
title Legacy Grub in sdb MBR
    rootnoverify (hd1)
    chainloader +1

It would not even be readily evident just what you were booting, as in OS, at least from Grub’s point of view and not required to load Windows or Linux. But I take your word for it please_try_again. And pray tell what does chainloader +2 do?

Thank You,

I think they won’t work for you since (I know) you stick to generic boot code. AFAIK there is one extra step that couldn’t be performed at this point: determine the active partition from the partition table.

It reads two sectors instead of one (if the boot code is longer).

I think they won’t work for you since (I know) you stick to generic boot code. AFAIK there is one extra step that couldn’t be performed at this point: determine the active partition from the partition table.

Well I must say then that it is not the same as that performed by the BIOS when it boots from the selected hard disk. And really, I never doubted some sort of tricks can be performed, but in the end of the day, you normally can only boot from the MBR, with full and normal functionality, from the system BIOS. AND I never doubted if there was someone that fully understood how this whole process works, it is indeed please_try_again. AND further, it is not my intentions to get in a disk sector battle with you, that is for sure. That is because I hate to be blasted out of the sky. lol!

Thank You,

This is what ‘findgrub’ yields for my sandbox PC (where I provided the ‘fdisk -l’ output above) :


Find Grub Version 3.0.1 - Written for openSUSE Forums


 - reading MBR on disk /dev/sda                    ... --> Grub  found in sda MBR     => sda1   0x6 (openSUSE)
 - searching partition /dev/sda1   (FAT16)         ...
 - reading bootsector  /dev/sda2   (LINUX)         ... --> Grub  found in /dev/sda2   => sda2   0x83 (openSUSE)
 - skipping partition  /dev/sda3   (swap)         
 - reading bootsector  /dev/sda4   (Extended)      ... --> Grub  found in /dev/sda4   => sda6   0x83 (openSUSE)
 - reading bootsector  /dev/sda5   (LINUX)         ...
 - reading bootsector  /dev/sda6   (LINUX)         ...
 - reading bootsector  /dev/sda7   (LINUX)         ...
 - reading MBR on disk /dev/sdb                    ... --> Grub  found in sdb MBR     => sdb5   0x83 (openSUSE)
 - reading bootsector  /dev/sdb1   (LINUX)         ...
 - reading bootsector  /dev/sdb2   (LINUX)         ...
 - skipping partition  /dev/sdb3   (swap)         
 - reading bootsector  /dev/sdb4   (Extended)      ...
 - reading bootsector  /dev/sdb5   (LINUX)         ...
 - reading bootsector  /dev/sdb6   (LINUX)         ...

Press <enter> to Exit findgrub...

sdb5 is a /home and sdb6 is currently empty. I note sdb used to be a stand along hard drive on an older PC that I canabilzed. I do not think I ever boot to the MBR on sdb in the PC’s current BIOS configuration.

I need to rush off to work, and I’ve no time to look at this in any detail.

But the above is not exactly what I expected ! :open_mouth: rotfl!

I’m wondering if the script was not able to accurately identify where the sda MBR points to ? It has an arrow for sda pointing to sda1 but I believe in fact in reality it points to sdb1. …

I do know sda is the 1st boot hard drive in BIOS. I know sdb1 is the OS I am currently typing from (openSUSE-12.1 M2). And I recall when installing 12.1 M2 it noted it would be placing content on sda’s MBR (I can’t recall exact details).

And I know when the PC boots, by default it boots sdb1.