Trying to automate the GRUB loading sequence based on rEFInd OS selection.

[Brian]

Trying to automate the GRUB loading sequence based on rEFInd OS selection.

For example... I select OS X..... OS X boots. I would like to essentially bypass the GRUB bootloader so when I click an entry (Windows or Linux) in refind the appropriate bootloader handles the work without manually selecting anything from the GRUB menu.

I am quite new to EFI, Linux and posting questions in general so please forgive me if this post is in bad etiquite and I hope that it goes without saying that Roderick Smith is awesome for making this happen in the first place.

Here is my Disk/Partition layout according to OS X. I have exhausted so very much time and energy researching my options and I am sorry if this post is not in good web etiquite but I would love to know if this is even possible prior to any further exhaustion.

#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 240.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Mac OS X 129.7 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 80.0 GB disk0s4
5: Bios Boot Partition 1.0 MB disk0s5
6: Microsoft Basic Data 28.2 GB disk0s6
7: Linux Swap 1.3 GB disk0s7
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme 1.0 TB disk1
1: Windows_NTFS Storage 961.5 GB disk1s1
2: Windows_NTFS PAGEFILE 38.7 GB disk1s2

When selecting either Windows or Linux from rEFInd I have the following GRUB options:

Ubuntu, with Linux 2.6.32-38-generic
Ubuntu, with Linux 2.6.32-38-generic (recovery mode)
Memory Test (memtest86+)
Memory Test (memtest86+, seral console 115200)
Mac OS X (32-bit) (on /dev/sda2)
Mac OS X (64-bit) (on /dev/sda2)
Windows 7 (loader) (on /dev/sda4)

When selecting Windows and checking 'e' for edit:

insmod ntfs
set root='(hd0, 4)'
search --no floppy --fs-uuid --set E0B888EAB888C110
chainloader +1

When selecting Ubuntu, with Linux 2.6.32-38-generic and checking 'e' for edit:

record fail
insmod ext2
set root= '(hd0, 6)'
search --no-floppy --fs--uuid --set 5a9ff983-85d7-4b9f-8b8f-d03b976fe\ 93f
linux /boot/vmlinuz-2.6.32-38-generic roo=UUID=5a9ff983-85d7-4b9f-8\ b8f-d03b976fe93f ro quit splash
initrd /boot/initrd.img-2.6.32-38-generic

I have these two files added to the drivers_x64:

ext4_x64.efi
ntfs_x64.efi

Finally I used the automated install.sh method. Please, anyone.. I am losing my [.....]

[Roderick W. Smith]

First, your 2.6-series kernel is ancient. Furthermore, a 2.6.32 kernel suggests you're running Ubuntu 10.04, which passed its end-of-life date five months ago. The EFI stub loader was added with the 3.3 kernel, so unless that feature has been back-ported into the Ubuntu 10.04 2.6.32 kernel, you won't be able to boot your Linux kernel directly from rEFInd so long as you stick with your past-end-of-life Ubuntu 10.04. Worse, the lack of support for Ubuntu 10.04 means that any new bugs -- including security bugs -- will not be updated. In sum, I strongly recommend that you upgrade from 10.04 to something more recent. Ubuntu 14.04 ships with a 3.13-series kernel and will be supported for almost four more years.

If you upgrade to a 64-bit Ubuntu 14.04, and if you're not running a first- or second-generation Mac (which had 32-bit EFIs), you can install Ubuntu by launching the installer in its "try before installing" mode, open a Terminal, and type sudo ubiquity -b. This will cause it to not install a boot loader. rEFInd should pick up your kernel and boot it directly, thus bypassing GRUB. This will solve part of your problem. An upgrade should preserve your user files and most of the computer's settings -- but back up any important data beforehand, just to be on the safe side.

One caveat to this is that if your Mac is old enough to have a 32-bit EFI, you won't be able to directly launch a 64-bit kernel from rEFInd. You can either install a 32-bit Ubuntu (in which case rEFInd should launch your kernels automatically) or install a 64-bit Ubuntu and jump through some extra hoops to get it all working. If you're not certain of your EFI's bit depth, check the rEFInd info/about screen, and particularly the "Platform" line; it will tell you whether it's 32- or 64-bit.

As to the rest, the problem now is that GRUB is in charge of your BIOS-mode boot process. To fix this problem, you must re-install the Windows boot loader to the disk's MBR. Your best bet for doing this is to run a Window tool, like bootrec /fixmbr, as described here. Do this only after you get Ubuntu booting in some other way, though. Also, note that I'm not a Windows expert. You may get better advice on this part of the task on a Windows forum.