Help booting systemd Arch EFI with clover

[katiepea]

I've been dual booting OS X and Linux for years, specifically Arch, I've used grub all that time. I just redid my install a few days ago and decided to skip grub and go with the systemd UEFI boot instead. Clover won't seem to auto detect that. So my first question, after looking around forever, is what specifically Clover is looking for, as in what conditions? Is it only looking for Grub? Is it looking at drive labels? And my 2nd question would be if it's not going to autoscan I'm fine with adding a custom entry but I'm at a wall there as well. I've followed the guide on the arch wiki to try to boot it, the clover guide itself is super vague on what the custom gui entries even are referring to.

These are on seperate HD's. The systemd efi boot is in /dev/sde1 which is mounted to /dev/sde2/boot...
I've attached images to show the drive layouts and my config.plist, can anyone tell me maybe what I'm doing wrong here that clover won't recognize the linux drive?

 

[Going Bald]

For grins and giggles I followed a guide by GloriousEggRoll on youtube in 3 parts: https://www.youtube.com/watch?v=MMkST5IjSjY for part 1.

Installation went easily, I have everything up and running, boots well.

Then I did a clean install of 10.11.3 using a newly made UniBeast USB.

Having the same problem you are having - unable to get Clover to even see the AL drive, let alone boot from it. Have been playing with it all day (raining outside and nothing else to do ) and still no luck.
Going to try the custom entry from your pic next as soon as X12 gets downloaded and installed.

 

[katiepea]

For grins and giggles I followed a guide by GloriousEggRoll on youtube in 3 parts: https://www.youtube.com/watch?v=MMkST5IjSjY for part 1.

Installation went easily, I have everything up and running, boots well.

Then I did a clean install of 10.11.3 using a newly made UniBeast USB.

Having the same problem you are having - unable to get Clover to even see the AL drive, let alone boot from it. Have been playing with it all day (raining outside and nothing else to do ) and still no luck.
Going to try the custom entry from your pic next as soon as X12 gets downloaded and installed.

Got it fixed today

here's the changes for the custom entry:

<key>GUI</key>
<dict>
<key>Custom</key>
<dict>
<key>Entries</key>
<array>
<dict>
<key>AddArguments</key>
<string>root=UUID=7c147578-19c6-4283-8181-d4d0e7281b9c rw add_efi_memmap initrd=/initramfs-linux.img</string>
<key>Disabled</key>
<false/>
<key>Ignore</key>
<false/>
<key>Path</key>
<string>vmlinuz-linux</string>
<key>Title</key>
<string>Arch Linux</string>
<key>Type</key>
<string>Linux</string>
<key>Volume</key>
<string>EFI</string>
<key>VolumeType</key>
<string>Internal</string>
</dict>
</array>
</dict>


___________

I also removed the EFI boot entry for the one that I created with the systemd efibootmgr during the install which was labeled "Linux Boot Manager"

in the arch install you want to type "efibootmgr" this will spit out all the efi boot entries that are current. There will be a hex string like "0081" attached to each one "efibootmgr -b 0081 -B" will remove whatever numbered entry you've selected.

I recreated this to name it "arch linux":

# efibootmgr -d /dev/sdX -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"

Where X and Y are changed to reflect the disk and partition where the ESP is located. Change the root= parameter to reflect your Linux root (disk UUIDs can also be used).

I'm honestly not sure which fixed it, but my gut is that removing the default efi entry and recreating it did the trick as I'm pretty sure the changes to config.plist were tried previously.

I've also attached my arch install cheat sheet. It's a bit easier than chugging along with a video.

 

[Going Bald]

Your "cheatsheet" is fairly close to what I followed, if a bit different in order and the swap partition was set up at the same time as the EFI, home and root. Also notice you use /dev/sda rather than the UUID on your boot loader options setup. If you move drives in and out of your system the /dev/sd id may change on you and cause problems - best to use the actual UUID here, yes?

So deleting your original boot loader and re-installing it new may have also been part of the fix?

Can you zip and post your Clover config.plist? Would like to do a comparison if possible. I am still not getting Clover to even see the drive at all.
Did you add scan kernels=all to yours? Tried that from a hint on another site - did not work.

This is what my Arch Linux EFI partition looks like:

 

[katiepea]

My fstab is set up to assign /dev/X by UUID so they shouldn't change I believe, at least I haven't encountered that happening yet.

I didn't mean removing the bootloader, just the EFI boot entry that it created, much like Clover will create a EFI boot entry called "MAC OSX" or something, it's not the bootloader itself, just the entry I believe sits in the NVRAM that an EFI bootloader looks for. Instructions I posted are for removing and recreating it since there's no flat I can see in the manpage for efibootmgr to rename.

More info on this can be found here: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#efibootmgr

I think this is what Clover was looking for, I could be wrong since I can't find detailed documentation on what Clover is actually scanning for when it scans.

Your arch / efi structure appears to be the same as mine. No I don't have scanning kernels enabled.

Full config.plist here:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
			<key>Debug</key>
			<false/>
			<key>DropOEM_DSM</key>
			<false/>
			<key>ReuseFFFF</key>
			<false/>
		</dict>
		<key>DropTables</key>
		<array>
			<dict>
				<key>Signature</key>
				<string>MCFG</string>
			</dict>
		</array>
		<key>SSDT</key>
		<dict>
			<key>DropOem</key>
			<true/>
			<key>Generate</key>
			<true/>
		</dict>
	</dict>
	<key>Boot</key>
	<dict>
		<key>Arguments</key>
		<string>-xcpm kext-dev-mode=1</string>
		<key>Debug</key>
		<false/>
		<key>Legacy</key>
		<string>LegacyBiosDefault</string>
		<key>Secure</key>
		<false/>
		<key>Timeout</key>
		<integer>3</integer>
		<key>XMPDetection</key>
		<string>Yes</string>
	</dict>
	<key>CPU</key>
	<dict>
		<key>BusSpeedkHz</key>
		<integer>100035</integer>
		<key>C2</key>
		<true/>
		<key>C4</key>
		<true/>
		<key>C6</key>
		<true/>
		<key>Latency</key>
		<string>0xcd</string>
		<key>Type</key>
		<string>0x0701</string>
	</dict>
	<key>Devices</key>
	<dict>
		<key>USB</key>
		<dict>
			<key>FixOwnership</key>
			<true/>
			<key>Inject</key>
			<true/>
		</dict>
	</dict>
	<key>DisableDrivers</key>
	<array>
		<string>Nothing</string>
	</array>
	<key>GUI</key>
	<dict>
		<key>Custom</key>
		<dict>
			<key>Entries</key>
			<array>
				<dict>
					<key>AddArguments</key>
					<string>root=UUID=7c147578-19c6-4283-8181-d4d0e7281b9c rw add_efi_memmap initrd=/initramfs-linux.img</string>
					<key>Disabled</key>
					<false/>
					<key>Ignore</key>
					<false/>
					<key>Path</key>
					<string>vmlinuz-linux</string>
					<key>Title</key>
					<string>Arch Linux</string>
					<key>Type</key>
					<string>Linux</string>
					<key>Volume</key>
					<string>EFI</string>
					<key>VolumeType</key>
					<string>Internal</string>
				</dict>
			</array>
		</dict>
		<key>CustomIcons</key>
		<true/>
		<key>Mouse</key>
		<dict>
			<key>DoubleClick</key>
			<integer>500</integer>
			<key>Enabled</key>
			<true/>
			<key>Mirror</key>
			<false/>
			<key>Speed</key>
			<integer>8</integer>
		</dict>
		<key>Scan</key>
		<dict>
			<key>Entries</key>
			<true/>
			<key>Legacy</key>
			<false/>
			<key>Tool</key>
			<false/>
		</dict>
		<key>ScreenResolution</key>
		<string>1920x1080</string>
		<key>Theme</key>
		<string>mlcamp</string>
	</dict>
	<key>Graphics</key>
	<dict>
		<key>Inject</key>
		<dict>
			<key>ATI</key>
			<false/>
			<key>Intel</key>
			<false/>
			<key>NVidia</key>
			<false/>
		</dict>
		<key>InjectEDID</key>
		<true/>
		<key>NvidiaSingle</key>
		<false/>
		<key>VideoPorts</key>
		<integer>5</integer>
	</dict>
	<key>KernelAndKextPatches</key>
	<dict>
		<key>AppleRTC</key>
		<true/>
		<key>AsusAICPUPM</key>
		<true/>
		<key>Debug</key>
		<false/>
		<key>KernelCpu</key>
		<false/>
		<key>KernelHaswellE</key>
		<false/>
		<key>KernelLapic</key>
		<false/>
		<key>KernelPm</key>
		<false/>
		<key>KextsToPatch</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>Trim Enabler</string>
				<key>Disabled</key>
				<false/>
				<key>Find</key>
				<data>
				QVBQTEUgU1NE
				</data>
				<key>Name</key>
				<string>IOAHCIBlockStorage</string>
				<key>Replace</key>
				<data>
				AAAAAAAAAAAA
				</data>
			</dict>
		</array>
	</dict>
	<key>RtVariables</key>
	<dict>
		<key>MLB</key>
		<string>XXXXXXXXXXXXX</string>
	</dict>
	<key>SMBIOS</key>
	<dict>
		<key>BiosReleaseDate</key>
		<string>10/12/2012</string>
		<key>BiosVendor</key>
		<string>Apple Inc.</string>
		<key>BiosVersion</key>
		<string>IM131.88Z.010A.B05.1210121459</string>
		<key>Board-ID</key>
		<string>Mac-FC02E91DDD3FA6A4</string>
		<key>BoardManufacturer</key>
		<string>Apple Inc.</string>
		<key>BoardType</key>
		<integer>10</integer>
		<key>ChassisAssetTag</key>
		<string>iMac-Aluminum</string>
		<key>ChassisManufacturer</key>
		<string>Apple Inc.</string>
		<key>ChassisType</key>
		<string>13</string>
		<key>Family</key>
		<string>iMac</string>
		<key>Manufacturer</key>
		<string>Apple Inc.</string>
		<key>ProductName</key>
		<string>iMac13,2</string>
		<key>SerialNumber</key>
		<string>XXXXXXXXXXXX</string>
		<key>Trust</key>
		<false/>
		<key>Version</key>
		<string>1.0</string>
	</dict>
	<key>SystemParameters</key>
	<dict>
		<key>InjectKexts</key>
		<string>Detect</string>
		<key>InjectSystemID</key>
		<true/>
	</dict>
</dict>
</plist>

 

[Going Bald]

My fstab is set up to assign /dev/X by UUID so they shouldn't change I believe, at least I haven't encountered that happening yet.

I didn't mean removing the bootloader, just the EFI boot entry that it created, much like Clover will create a EFI boot entry called "MAC OSX" or something, it's not the bootloader itself, just the entry I believe sits in the NVRAM that an EFI bootloader looks for. Instructions I posted are for removing and recreating it since there's no flat I can see in the manpage for efibootmgr to rename.

More info on this can be found here: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#efibootmgr

I think this is what Clover was looking for, I could be wrong since I can't find detailed documentation on what Clover is actually scanning for when it scans.

Your arch / efi structure appears to be the same as mine. No I don't have scanning kernels enabled.

Hmmm... I may not have an entry in the NVRAM, unless it is the P3 entry - I do not see one similar to the Mac OS X ones for Arch Linux. What I see in the UEFI for booting is
Mac OS X
Mac OS X
UEFI OS (P1: HGST HTS725050A7E630) -- this is the OS X drive
UEFI OS (P2: HGST HTS725050A7E630) -- this is the Win10 drive
UEFI OS (P3: HGST HTS725050A7E630) -- this is the Arch Linux drive

(yes, those are identical hard drives - found 6 of them at a yard sale, still in OEM plastic, unopened, for less than half retail)

I will try your script and see what happens. Do you have time to write up a "How to" guide for booting Arch with Clover and post it in the http://www.tonymacx86.com/linux/ forum? I am sure there are many who would be grateful to be spared trying to dual boot Arch and OS X and not being able to boot it with Clover.

 

[Going Bald]

I also removed the EFI boot entry for the one that I created with the systemd efibootmgr during the install which was labeled "Linux Boot Manager"

in the arch install you want to type "efibootmgr" this will spit out all the efi boot entries that are current. There will be a hex string like "0081" attached to each one "efibootmgr -b 0081 -B" will remove whatever numbered entry you've selected.

I recreated this to name it "arch linux":

# efibootmgr -d /dev/sdX -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"

Where X and Y are changed to reflect the disk and partition where the ESP is located. Change the root= parameter to reflect your Linux root (disk UUIDs can also be used).

I'm honestly not sure which fixed it, but my gut is that removing the default efi entry and recreating it did the trick as I'm pretty sure the changes to config.plist were tried previously.

I've also attached my arch install cheat sheet. It's a bit easier than chugging along with a video.

Tried this - did not work.
Boot Arch, login, open Xterm, at the $ type "efibootmgr" without quotes and got a return of "command not found"
Then I thought, "Dummy, this is UEFI, use UXterm" so tried that - same result, command not found.

Then I thought "Dummy, you are not logged in as root, so type "sudo efibootmgr" without quotes and got the same command not found.

I may need to install a lot of other apps to make this work, but I am reluctant to take the time to do so on an experimental install I do not intend to keep.

One last try with the install usb and then I quit.

What do you think would happen if I deleted all of the entries and then just rebooted?

EDIT again: Booted with the installer USB. Deleted the entries for Mac OS and the entry for the Arch Linux drive. Deleted the boot loader
lsblk reveals my root to be sdb3, so type:
efibootmgr -d /dev/sdb -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdb3 rw initrd=/initramfs-linux.img" and hit enter and I get #invalid numeric value Y

 

[Going Bald]

Your arch / efi structure appears to be the same as mine. No I don't have scanning kernels enabled.

Full config.plist here: >

Copying the plist into your post destroys the formatting, which is what I wanted to check.
Use

 and

to enclose your .plist, or other coded entries so you do not lose the format structure.


EDIT: Never mind - got it figured. I now have a Penguin to boot Arch on the Clover boot screen. Unfortunately, it boots to blank screen instead of initiating the Ach Linux boot. I will get it figured out sooner or later.

Verified the AL drive boots on its own, so probably not the boot loader. I hope I can make sense of my notes when someone asks me "how to" and I try to answer

 

[katiepea]

Tried this - did not work.

lsblk reveals my root to be sdb3, so type:
efibootmgr -d /dev/sdb -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdb3 rw initrd=/initramfs-linux.img" and hit enter and I get #invalid numeric value Y

in my earlier comment i noted "Where X and Y are changed to reflect the disk and partition where the ESP is located. Change the root= parameter to reflect your Linux root (disk UUIDs can also be used)."

Y is the partition number where the ESP is. So your line is probably

efibootmgr -d /dev/sdb -p 1 -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdb3 rw initrd=/initramfs-linux.img

I also edited my earlier post to use the code formatting.

Not sure if you ever said you were using grub or not. Not having efibootmgr installed would indicate you might be, next time you can skip grub and the config for it if you want and just do a " bootctl install " to use arch's systemd uefi bootloader rather than grub. No configuration required for it, just that line and it allows you to do nothing else.

edit: it just occurred to me that you probably actually did do a bootctl install and didn't use grub, I'm just wondering, for no reason really, why this isn't installed for you. When you did your pacstrap base install did you do base-devel too to install developer tools?

 

[Going Bald]

in my earlier comment i noted "Where X and Y are changed to reflect the disk and partition where the ESP is located. Change the root= parameter to reflect your Linux root (disk UUIDs can also be used)."

Y is the partition number where the ESP is. So your line is probably

efibootmgr -d /dev/sdb -p 1 -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdb3 rw initrd=/initramfs-linux.img

I also edited my earlier post to use the code formatting.

Not sure if you ever said you were using grub or not. Not having efibootmgr installed would indicate you might be, next time you can skip grub and the config for it if you want and just do a " bootctl install " to use arch's systemd uefi bootloader rather than grub. No configuration required for it, just that line and it allows you to do nothing else.

edit: it just occurred to me that you probably actually did do a bootctl install and didn't use grub, I'm just wondering, for no reason really, why this isn't installed for you. When you did your pacstrap base install did you do base-devel too to install developer tools?

Don't know where my brain went on that script. Shows what happens when you try something when you are not awake yet.
I just did the bootctl install following the guide by Gloriouseggroll - installing by rote. Not familiar enough with Arch Linux to know what is installed by default and what needs installed separately. I did decide to keep the drive as is and explore what Arch offers as opposed to Debian or Ubuntu.
I do have the penguin icon as a result of the config.plist edit, but it will not boot yet - suspect I need that script run. Will try that when I get home from work today (gonna be a loooonnnggg 12 hours!)

A couple of things definitely need to change: the background and the lock screen pics are horrible.
I looked through the settings to see what I could change them to, but could find no way to add other pics - can I just drag and drop onto the selection window or is there a path to where they are stored you can give me?