I wouldn't expect the minimal-live to boot on any uefi system. It's not uefi-compatible. Please try the amd64 desktop-live iso. It has both 32 and 64-bit uefi bootloaders. It should boot on your system.

If you choose to install it, I think you'll need to install the grub-efi-ia32 package first, then run the installer and let it install the bootloader.

I don't understand why you think cfdisk defaults to gpt. I also don't see where you can change the partition label on a partitioned disk. It just reports what is there. On an unparitioned disk, the first thing cfdisk does is give you a choice of partition table types. I had to zero the first few MB of a disk before running cfdisk to see that.

Your 'A2' surfaced the hidden glitch in the bootloader matrix!  The beowulf minimal-liveCD defaults to 'gpt', and minimal-liveCD is limited to BIOS boot

Yeah, I see the problem. The installer selects gdisk if /sys/firmware/efi exists or if there are gpt disks found. If you don't know to pre-partition with cfdisk, you are understandably lost in the installer. I'll change it so both are available under any circumstances, and the user can decide which one to use.

fsmithred wrote:

If the minimal-live CD booted on the macbook, then the mac is capable of booting in legacy bios (CSM) mode. There is no uefi bootloader in that iso.

The above quote was in reference to booting the CD on hardware.

englee wrote:

Hi,
Q2: If minimal-live CD ISO has no uefi bootloader bundled in its ISO, how would the above partition's differ in legacy bios (CSM) mode, when refracta installer script defaults to gdisk/gpt?
englee

A2:
For a legacy bios boot, you don't need the efi partition. You just need a root partition for the operating system and grub-pc will put the bootloader in the mbr of the disk of your choice. If you use gpt with a bios boot, you need to have a special partition for the bootloader to put some additional code. The live installer will complain about this if you don't have it.

If the minimal-live CD booted on the macbook, then the mac is capable of booting in legacy bios (CSM) mode. There is no uefi bootloader in that iso. And I agree that it should have installed in virtualbox. I have installed previous versions of the minimal-live in previous versions of virtualbox, and the current isos are essentially the same as they were then.

If you choose expert install in the netinstall iso, you get a few more questions, and one of them lets you skip adding a bootloader. That would have avoided clobbering rEFInd.

I booted the first option in the minimal live. Choosing one of the toram or access options shouldn't change the outcome. I'm not sure about the no-probe option.

This one: devuan_beowulf_3.1.1_amd64_minimal-live.iso

In your virtualbox gui, go to System, Motherboard, Chipset. What does it say?

This is not really making sense to me.

This section starts with line 524. It should tell how many efi partitions are present. I don't understand the error message on that.

if [ "$esp_count" -eq 1 ] ; then
        esp_count=$(env LC_ALL=C fdisk -l | awk '/EFI System/ { print $0 }' | wc -l)
fi
if [ "$esp_count" -gt 1 ] ; then
        must_choose_esp="yes"
fi

The error messages about  'Unable to open /dev-sr0 read-write' and 'Can't have a partition outside the disk' make me think that it's trying to install grub to the wrong disk. (i.e. to the CDROM). Sometimes grub and the kernel don't agree on which disk is first. This might be one of those cases.

englee wrote:

Hi,
Burnt beowulf minimal LiveCD (no DT) onto a CD-R media, which booted just fine on the old MBP.
'grub-install' trapped the following error on the LiveCD VM install to HDD:

Installing for i386-pc platform.
grub-install: error: unable to identify a filesystem in hostdisk//dev/sda; safety check can't be performed.

Your comments, where the MBP is exempt from this glitch in the matrix?
englee

If you are installing from the minimal-live, there will already be at least one ext2/3/4 filesystem on the virtual disk when you get to the grub-install stage.  What do fdisk and blkid show for the disk? What virtualization software are you using on the mac? Maybe it does something differently from what I expect.

englee wrote:

How would you suggest booting beowulf USB HDD by enabling CSM ("Legacy" mode) and disabling UEFI?

Check the firmware ("BIOS") settings for an option to disable UEFI. This is usually called CSM or "Legacy" mode with normal PCs but I have no experience whatsoever with Macs (I hate them with a vengeance) so I have no idea how this stuff works with them.

FYI: Some macbook pros use a 32-bit efi bootloader with a 64-bit operating system. I know the 2011 ones did that. Not sure about the 2013 models or how to tell which grub it needs.

englee wrote:

Why would VM mistake an AMD64 w/i386-PC?

That message is from GRUB — "i386-pc" is for non-UEFI systems, even if they're 64-bit; the UEFI GRUB targets are called "i386-efi" & "x86_64-efi".

So the VM seems to have the grub-pc package installed instead of grub-efi-amd64, which is incorrect if you want to dual-boot with a UEFI OS X installation.

Try this in the installed system:

# apt install grub-efi-amd64{,-signed} # this should cause the removal of the grub-pc package
# grub-install --target=x86_64-efi --bootloader-id=debian --removable # make sure the correct ESP is mounted under /boot/efi first

englee wrote:

Installer failed to recognize beowulf USB drive's ESP

What does that mean, exactly?

I've just experimented in a VM and if I use the "manual" partitioning option then multiple ESPs are detected and identified as such. I managed to install Devuan onto a second disk with it's own ESP by marking the ESP on the first disk as "do not use". The Devuan ESP was marked as "EFI system partition" and the installer then successfully created a boot entry pointing to it. I think you can use the "Advanced" installer to force the fallback EFI loader but I just rebooted and used "Rescue Mode" to do that afterwards.

englee wrote:

1      1049kB  99.6MB   98.6MB  fat16       EFI System Partition boot, esp

Was the original ESP marked "fat16"? I always use FAT32.

englee wrote:

Why can't the installed beowulf use the same type of standalone bootloader as it's installer

You can do that but it will require a new EFI system partition on the beowulf drive to hold the GRUB files.

englee wrote:

Boot0000* devuan HD(1,GPT, lbc27af6-16da—4b55-9dda-6ab2e0b4c0b9,0x28,0x64000)/File(\EFI\devuan\shimx64.efi)

The grub-efi-amd64-signed package is hard-coded to look under $ESP/EFI/debian/ for the location of the configuration file so that might be why it's having trouble.

So from the shell in the installed system run these commands (this presumes the EFI system partition is assigned to /dev/sda1):

mount /dev/sda1 /mnt
cp -r /mnt/EFI/de{vu,bi}an
efibootmgr -b 0 -B
efibootmgr --create --label 'Devuan' --loader '/EFI/debian/shimx64.efi'
debconf-set-selections <<<'grub-efi-amd64 grub2/update_nvram boolean false'

^ That copies the "devuan" directory to a "debian" version, deletes the current boot entry, creates a new boot entry pointing to the "debian" directory and tells the grub-efi-amd64 package not to change the boot entries in future.