Both your #1 and #2 options are possible; however, if you don't understand the Mac's native EFI-mode booting and how the Mac implements BIOS/legacy booting, you're likely to make a hash of things in setting it up. My suspicion is that you installed Ubuntu in BIOS/legacy mode with a BIOS-mode version of GRUB, which means that GRUB will be unable to launch OS X (or maybe it'll manage, but that path is very flaky in my experience). If I'm right, you'll want to install either an EFI version of GRUB or rEFInd to do as you want. Installing from OS X is preferable, although the Mactel tools to which LiveWireBT can theoretically make this more reliable in Linux. (I have limited experience with these tools myself, though, so I can't comment on them in detail.) My pages on hybrid MBRs and EFI boot loaders for Linux will help bring you up to speed, but be prepared to spend some time on the reading. Sorry, but I know of no good shortcut for this. A brains-off step-by-step guide might work, but is more likely to lead you astray because of assumptions the author makes that don't apply to your system.
The rEFInd documentation is pretty extensive. Be aware there have been significant changes in rEFInd's Mac support recently. In particular, version 0.8.4 and later now install to the EFI System Partition (ESP) by default, which is necessary to work with the way Yosemite is set up by default. This change has caused some confusion among users, though.
Full disclosure: I maintain rEFInd, so I'm not unbiased.
This is my final answer, which is based on information found by matching keyword within 2000+ pages in this listing on Ubuntu Wiki. What I found were dated notes of Ubuntu development and specifications (read: words, words, words), so that took me some time to reach this answer.
Ops, wrong naming
To begin with, the naming of boot loaders shall be clarified:
Name with all letters capitalized refers to the boot loader (e.g. GRUB, SYSLINUX)
Name with initial letter capitalized refers to the project name or, several or all variants of the boot loader family (e.g. Syslinux)
In particular, 'Syslinux' is a collection of boot loaders that includes 'SYSLINUX', 'ISOLINUX', 'EXTLINUX' and 'PXELINUX'
Following the naming convention, the question is actually referring to "ISOLINUX" for "El Torito no-emulation" bootloader, not "SYSLINUX". Perhaps the latter is used interchangeably with the former in old days. Nevermind, then.
Brief history
2005: ISOLINUX is choosen for Ubuntu CD boot loader, instead of GRUB.
GRUB has been suggested before as a possible replacement boot loader, but this approach was tried in the Warty live CD where we observed significant regressions in bootability versus the ISOLINUX-using install CD. We feel that sticking with solutions based on ISOLINUX is the most appropriate approach for a long-term-supported release.
-- from CdBootloader - Ubuntu Wiki
2006: gfxboot has been added; This supports information quoted in 2010.
In Dapper, we added gfxboot to our amd64 and i386 CD images, providing a friendly graphical boot menu as the first thing users see when booting Ubuntu CD images on those architectures [...]
-- from PortableGfxboot - Ubuntu Wiki
2009: ISOLINUX (noted as SYSLINUX) is still used for booting Ubuntu CD.
Ubuntu live CDs still boot using SYSLINUX, which does not include support for starting the kernel in graphics mode. This means that live CDs display a graphical boot menu, then switch back to text mode to start the kernel, and will then normally switch back to graphics mode later. As a result, live CDs will currently flicker more than normal installed systems at boot time.
-- from BootGraphicsArchitecture - Ubuntu Wiki
2010: ISOLINUX has been used, but GRUB 2 is needed for UEFI support.
Current Ubuntu CDs use ISOLINUX, with the gfxboot extensions from SuSE implementing graphical menus.
This has proven to be rather difficult to maintain, with only one person in Ubuntu who understands the theming code involved [...]
[Since] GRUB 2 recently had graphical menu support added to it upstream, moving to that has the potential to reduce our maintenance load. It seems likely that we will need to use GRUB 2 anyway in order to support EFI, and having to configure two different boot loaders on our CDs would be undesirable.
-- from FoundationsTeam/Specs/MaverickCDBoot - Ubuntu Wiki
Pursuant to foundations-m-grub2-boot-framebuffer, we will need to look into our ability to support graphical boot menus in EFI. GRUB has some level of support for UGA and GOP graphics.
This requires using GRUB for CD booting, or at least having the bare minimum of configuration to support it [...]
-- from FoundationsTeam/Specs/MaverickUefiSupport - Ubuntu Wiki
Differences found or not
Following brief history, we now understand that:
ISOLINUX was preferred due to GRUB had regressions back then (2005)
ISOLINUX was still preferred despite lack of support for starting the kernel in graphics mode that cause flickering during boot transition (2009)
ISOLINUX has been used with gfxboot to provide graphical menu, which was not implemented or not possible with GRUB back then (2010)
GRUB has been added later to boot with UEFI support since Maverick (post-2010)
Then, I realized that it is not the difference between GRUB and SYSLINUX that made Ubuntu live CD include two boot loaders.
Fundamental reasons
From my reading, these supporting facts actually hinted that:
Ubuntu live CD has been using particular boot loader that had better support for providing graphical menu and theme, and smooth transition to show boot splash. In this case, SYSLINUX (precisely ISOLINUX).
When UEFI systems became increasingly common, then only Ubuntu had included GRUB (precisely GRUB 2) in Ubuntu live CD to boot with UEFI support.
Above all, I believe this answers the question that I had for more than a year and this answer has finally put my curiosity to rest.
TL;DR GRUB and ISOLINUX are both used in Ubuntu live CD for exclusive reasons; Both were included in live CD for better boot experience and hardware support.
Best Answer
Typically,
EFI/ubuntu/grubx64.efi
on the EFI System Partition (ESP) is the GRUB binary, andEFI/ubuntu/shimx64.efi
is the binary for shim. The latter is a relatively simple program that provides a way to boot on a computer with Secure Boot active. On such a computer, an unsigned version of GRUB won't launch, and signing GRUB with Microsoft's keys is impossible, so shim bridges the gap and adds its own security tools that parallel those of Secure Boot. In practice, shim registers itself with the firmware and then launches a program calledgrubx64.efi
in the directory from which it was launched, so on a computer without Secure Boot (such as a Mac), launchingshimx64.efi
is just like launchinggrubx64.efi
. On a computer with Secure Boot active, launchingshimx64.efi
should result in GRUB starting up, whereas launchinggrubx64.efi
directly probably won't work.Note that there's some ambiguity possible. In particular, if you want to use a boot manager or boot loader other than GRUB in a Secure Boot environment with shim, you must call that program
grubx64.efi
, even though it's not GRUB. Thus, if you were to install rEFInd on a Secure Boot-enabled computer,grubx64.efi
could be the rEFInd binary. This binary would probably not reside inEFI/ubuntu
, though; both it and a shim binary would probably go inEFI/refind
. Also, as you've got a Mac (which doesn't support Secure Boot), there's no need to install rEFInd in this way; it makes much more sense to install rEFInd asEFI/refind/refind_x64.efi
(its default location and name).Note that the rEFInd documentation includes a whole page on Secure Boot. Chances are you won't benefit from reading it, user190735, since you're using a Mac. I mention it only in case some other reader comes along who's trying to use rEFInd in conjunction with Secure Boot.