Quasi-Success in Booting from an External HDD on Mac HW

[silverthread]

I have had some success in booting Ubuntu 14.04.2 LTS on an external hdd using an Apple

i-Mac. Mac OS X (10.10.2) occupies the internal hard drive. I have the following hardware:i-Mac (9,1) 3.06GHz Core 2 Duo (64-bit hardware); an iomega 2TB Firewire 800 HD;
Graphics Card ATI Radeon HD 4850. I have followed the instructions found here , adapting where necessary to accommodate installation to the external HDD. However, there was some modification of the Linux partition scheme wherein the recommended /boot partition was eliminated and incorporated within the / partition (for reasons unknown this worked). Ultimately the following partition scheme was used: / -- 100GiB; swap --8GiB; /home --915GiB (respectively sdb4, sdb5, and sdb6) and a biosgrub partition. Everything proceeds well up to step 10 of the instructions at the previously cited link.
I know the developer of refind, has in other postings, suggested that booting Linux from an external HDD on Apple hardware is at best an iffy proposition; nevertheless, refind presents 4 boot entries: Ubuntu (via grub64.efi), Mac OS X, Ubuntu (signed efi kernel) and Ubuntu (generic efi kernel). The latter two entries, examined using the F2 key option, both contain UUID's for the kernel and initrd. Selecting either of these begins the booting process from the external HDD. The boot continues, including the sound of the Ubuntu "drums", unfortunately with a blank purple/magenta screen and continued disk activity (quite long).
My working hypothesis is that, like the installation USB key, a option needs to be passed to the kernel. In the case of the installation USB key, this was "radeon.modeset=0". If I am correct how would I pass this using a refind stanza? Do I have to provide a stanza for each entry/OS refind discovers? Must I include the UUID's that refind has listed for the Ubuntu entries. These things were unclear to me having read this. I would appreciate any and all advice or help as I believe I am very close to making this work.

[Roderick W. Smith]

Don't try writing a custom stanza. Experiment by using F2, as you've discovered how to do. You can edit the boot entry by that method to try out different options until you (with any luck) find one that works.

With a working option in hand (or in mind), edit the /boot/refind_linux.conf file and add your option to the boot entries in that file. If that file doesn't already exist, run the mkrlconf.sh script that comes with rEFInd to create one. (In your case, rEFInd might well be getting its root partition information from /etc/fstab, but this file can't hold the extra options you need. Running mkrlconf.sh creates the /boot/refind_linux.conf file that you can then customize.)

[silverthread]

I was able to log on with the kernel options: radeon.modeset=0 nomodeset.
I now have to work out some wrinkles with Ubuntu and properly
configure the graphics card. One, in which you might assist, consists
of eliminating the need to (re-)create a new gpt (on the external) with gdisk
after each log out (from Ubuntu).

I wanted to offer my thanks for your suggestions and help. I do not think
this would have worked without refind, great work.

[Roderick W. Smith]

There should be no need to mess with the partition table on each boot, much less after logging out of your account. If such actions are damaging the partition table, then something is very wrong. The most common source of such problems is mis-set motherboard-based software RAID (aka "fake RAID") settings, but such issues most commonly affect internal disks, not external ones; and AFAIK, Apple has never gone down that particular rabbit hole. (OTOH, maybe the disk has some RAID data on it from a previous use with non-Apple hardware.)

If you could post the output of sudo sgdisk -v /dev/sdb (or whatever the disk device is) when the problem occurs, I might be able to offer more specific advice. Be sure to precede every line of output by four spaces to preserve the formatting and set it in a monospace font; failure to do this will create a garbled mess.

[silverthread]

Here is the output from "sudo sgdisk -v /dev/sdb/

Problem opening /dev/sdb/ for reading! Error is 20.
Verification may miss some problems or report too many!

Problem: The CRC for the main GPT header is invalid. The main  GPT header may
be corrupt. Consider loading the backup GPT header to rebuild the main GPT
header ('b' on the recovery & transformation menu). This report may be a false
alarm if you've already corrected other problems.

Problem: The CRC for the main partition table is invalid. This table may be
corrupt. Consider loading the backup partition table ('c' on the recovery &
transformation menu). This report may be a false alarm if you've already
corrected other problems.

Problem: The CRC for the backup GPT header is invalid. The backup GPT header
may be corrupt. Consider using the main GPT header to rebuild the backup GPT
header ('d' on the recovery & transformation menu). This report may be a false
alarm if you've already corrected other problems.

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The main header's self-pointer doesn't point to itself. This problem
is being automatically corrected, but it may be a symptom of more serious
problems. Think carefully before saving changes with 'w' or using this disk.

Problem: main GPT header's current LBA pointer (1) doesn't
match the backup GPT header's alternate LBA pointer(0).

Problem: Disk is too small to hold all the data!
(Disk size is 0 sectors, needs to be 0 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 18446744073709551582, but backup header is at
18446744073709551615 and disk size is 0 sectors.
The 'e' option on the experts' menu will probably fix this problem

Warning: 0xEE partition doesn't start on sector 1. This can cause problems
in some OSes.

As you can see numerous errors.  Interestingly, when installing,
ubiquity/gparted saw sdb as some sort of RAID volume; however,
this disk was never used in a RAID system nor was it ever attempted
during any partitioning or installation from either Mac OS X nor
Ubuntu Linux.  It was purchased new, never used.

Thanks for the help.

[Roderick W. Smith]

You added a slash (/) to the command I specified; it must be sudo sgdisk -v /dev/sdb, not sudo sgdisk -v /dev/sdb/. Please re-run the command without that extra slash, since the output of the command you entered is useless.

That said, the fact that GParted saw the disk as a RAID volume supports my speculation that it may have been used in a RAID setup before and that this is the source of your troubles. Perhaps somebody had bought it and used it before you, then returned it to the store and the store didn't disclose this fact; or maybe the factory messed up and splatted RAID data onto it. If so, the following command might help:

dmraid -r -E /dev/sdb

I don't recommend issuing it just yet, though; if it's applied inappropriately, that command could damage data on your disk.

[silverthread]

Sorry for the late reply and the mistake. Here then is the corrected output:

sudo sgdisk -v /dev/sdb
[sudo] password for user:

No problems found. 1689573 free sectors (825.0 MiB) available in 4
segments, the largest of which is 1425408 (696.0 MiB) in size.

The above command was executed in Linux (after correcting the gpt). Perhaps I should exectue the command (necessarily in Mac OS X) after a shutdown and gpt is altered/misconfigured.

I also found that, using the mount command in Linux, /boot/efi is mounted vfat (rw) on /sdb1. During installation I did not create a separate /boot partition. Is this how it should be? I would also like to note that earlier that I stated upon logout the gpt table had to be rebuilt (in Mac OS X) using gdisk. It would be more precise to say upon shutdown the gpt must be rebuilt.

I shall wait for your reply before executing:

dmraid -r -E /dev/sdb

Thanks.

[Roderick W. Smith]

The above command was executed in Linux (after correcting the gpt). Perhaps I should exectue the command (necessarily in Mac OS X) after a shutdown and gpt is altered/misconfigured.

Yes, please do. The whole point of using sgdisk -v is to get a report on the errors in the partition table. If you run it after some other tool has fixed those errors, the results won't tell me anything; and indeed that's the case with what you've posted.

I also found that, using the mount command in Linux, /boot/efi is mounted vfat (rw) on /sdb1. During installation I did not create a separate /boot partition. Is this how it should be?

Yes, that's fine. You can use a separate /boot partition or not, as you see fit. An exception is if your root (/) filesystem is in an LVM or RAID setup. In such cases, you must have a separate /boot partition. This is clearly not the case for your current setup, though.

I would also like to note that earlier that I stated upon logout the gpt table had to be rebuilt (in Mac OS X) using gdisk. It would be more precise to say upon shutdown the gpt must be rebuilt.

That's an important correction, and makes much more sense. Logout and shutdown operations are very different. Partition table damage upon logout makes very little sense, because nothing should be routinely touching the partition table upon logout. Partition table damage upon shutdown is more believable because the firmware, boot loaders, and other tools might all touch the partition table, mostly after powering the system back up.