In 0.8.1, OS X: Unable to mount ESP a user was having a problem related to the presence of two internal drives in a MacBook. ./install.sh --esp was failing for him. Joe van Tunen proposed a patch to install.sh to overcome the problem. Apparently it worked for that user.
I'm now in a similar boat but with 0.8.3 and an iMac with two internal (non-ejectable or removable) SSDs. /dev/disk0 is an empty drive with no partitions at all. /dev/disk1 has an ESP (disk1s1) as well as OS X 10.8.5 on it. I am running install.sh whilst booted into the latter.
Output includes:
"Warning: root device doesn't have an EFI partition"
"Could not find an EFI partition. Aborting!"
Examining the code, it seems that Joe's patch has been incorporated into the install.sh shipping with 0.8.3 even though neither that file's revision history or the 0.8.2/3 release notes make mention of it.
Why the patched version worked for the other user but not for me I do not know. In any case, by commenting out lines 449-469 and hard-coding Temp="disk1s1" immediately after that, I was able to get the script to successfully run and all is well.
As an idea to make the code a little simpler and more robust, I propose the following alternative logic for the 449-469 section of code:
1) the script determines what volume it is located on
2) the diskID is determined from the volume
3) parse the output of diskutil list <diskID> for occurrences of EFI
4) if one and only one such partition exists, use it and extract the diskIDsliceID
5) in all other cases, abort, display the output of diskutil list <diskID>, and attach an error message along the following lines:
"./install.sh --esp needs to be run from an OS X volume on a disk which also has one EFI system partition on it. Please relocate the rEFInd folder to such a volume/disk and try again."
The above approach makes it clear that the boot manager will be installed on the same disk that the installer is located on, eliminates the need to scan other disks for suitable ESPs, and does not require any code-based guesswork if multiple suitable ESPs are located.
If OS X users wish to deliberately and knowingly install rEFInd somewhere else, --ownhfs and --root are available to them.
Anyway, it's just an idea.
Thank you, Rod, for all the work you are doing on this project. Thanks also to all the patch submitters out there who are helping make it better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe we can figure out why it's not working for you.
Try the used commands one at a time:
mount
One of the lines should like like this:
/dev/disk0s2 on / (hfs, local, journaled)
Then, using that disk name, try this:
diskutil list /dev/disk0s2
Which should have one of the lines like this:
1: EFI EFI 209.7 MB disk0s1
Putting it all together, try the following lines:
Temp=$(mount | sed -n -E "/^(\/dev\/disk[0-9]+s[0-9]+) on \/ \(.*$/s//\1/p")
echo $Temp
Temp=$(diskutil list $Temp | sed -n -E '/^ *[0-9]+:[ ]+EFI EFI[ ]+[0-9.]+ [A-Z]+[ ]+(disk[0-9]+s[0-9]+)$/ { s//\1/p;q; }' )
echo $Temp
The first line of the result should be the root partition device and the second line should be the EFI partition on the disk containing the root partition like this:
/dev/disk0s2
disk0s1
Last edit: joevt 2014-10-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-10-17
Thanks for the step-through - it's making more sense now. That said, that code doesn't actually work for me. The first part is fine, but the second part returns no data. Even this fails directly from the command line:
$ diskutil list /dev/disk0s2 | sed -n -E '/^ *[0-9]+:[ ]+EFI EFI[ ]+[0-9.]+ [A-Z]+[ ]+(disk[0-9]+s[0-9]+)$/ { s//\1/p;q; }'
Given that the following entry is the one we are interested in:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
1: EFI 209.7 MB disk0s1
Should the second occurrence of EFI actually be in the regular expression-type-thing given that the EFI partition has no name? If we remove ' EFI' from the above we get:
$ diskutil list /dev/disk0s2 | sed -n -E '/^ *[0-9]+:[ ]+EFI[ ]+[0-9.]+ [A-Z]+[ ]+(disk[0-9]+s[0-9]+)$/ { s//\1/p;q; }'
disk0s1
...which was the desired output.
PS: And that would explain why MountOSXESP() is failing for me in install.sh — the code expects my ESPs to be named 'EFI' but they are not!
Last edit: Anonymous 2014-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does your EFI partition have a file system name? I thought diskutil always showed the file system name but maybe it doesn't do that if the partition isn't mounted? You could check diskutil before and after mounting the EFI partition.
This command shows the gpt names:
sudo gpt -r show -l /dev/disk0
This command shows the gpt partition ids:
sudo gpt -r show /dev/disk0
I guess we shouldn't assume the EFI partition has a name. Maybe it's enough that the partition has the correct type. EFI=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
In the script "EFI EFI[ ]+" should be replaced with "EFI .* " to ignore the name.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-10-18
None of the ESPs on any of my computers are named. The diskutil listing is the same regardless of whether the ESP is mounted or not:
$ diskutil list /dev/disk0s2
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER0: GUID_partition_scheme *1.0 TB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 917.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 82.0 GB disk0s4
The drive was a clean install of OS X 10.8 Mountain Lion. I have never paid attention to ESP names up until now so I don't know if it has always been this way, or changed at some point. I have no other versions of OS X to check against, either.
For reference, here is the output from those other two commands:
$ sudo gpt -r show -l /dev/disk0
Password:
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
01 MBR
11 Pri GPT header
232 Pri GPT table
346404096001 GPT part - "EFI System Partition"40964017916896882 GPT part - "MacOSX"179209932812695443 GPT part - "Recovery HD"1793368872124017933701121601536004 GPT part - "BOOTCAMP"19535237121423195352513532 Sec GPT table
19535251671 Sec GPT header
$ sudo gpt -r show /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
01 MBR
11 Pri GPT header
232 Pri GPT table
346404096001 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
40964017916896882 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
179209932812695443 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
1793368872124017933701121601536004 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
19535237121423195352513532 Sec GPT table
19535251671 Sec GPT header
PS: I have had time to do some research and the ESP is un-named in 10.4 Tiger, 10.5 Leopard, 10.6 Snow Leopard, 10.7 Lion and 10.8 Mountain Lion. The ESP is named EFI in 10.9 Mavericks and 10.10 Yosemite. Your suggested change to the regular expression will catch all of those cases.
Last edit: Anonymous 2014-10-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your output seems to confirm that diskutil does show the file system name (the gpt has a MacOSX partition which you've renamed to "Macintosh HD"). So I wonder why diskutil doesn't show the file system name for your EFI partition.
In my gpt, it's labeled as "EFI" and formatted as MS-DOS FAT32. Yours is labeled "EFI System Partition" in the gpt which means they were created differently.
Here's my diskutil info for the partition when it's mounted:
$ diskutil info disk0s1
Device Identifier: disk0s1
Device Node: /dev/disk0s1
Part of Whole: disk0
Device / Media Name: EFI
Volume Name: EFI
Escaped with Unicode: EFI
Mounted: Yes
Mount Point: /Volumes/EFI
Escaped with Unicode: /Volumes/EFI
File System Personality: MS-DOS FAT32
Type (Bundle): msdos
Name (User Visible): MS-DOS (FAT32)
Partition Type: EFI
OS Can Be Installed: No
Media Type: Generic
Protocol: SATA
SMART Status: Not Supported
Total Size: 209.7 MB (209715200 Bytes)(exactly 409600512-Byte-Units)
Volume Free Space: 181.8 MB (181777408 Bytes)(exactly 355034512-Byte-Units)
Device Block Size: 512 Bytes
Read-Only Media: No
Read-Only Volume: No
Ejectable: Yes
Whole: No
Internal: No
Solid State: No
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-11-15
Hi all,
Please note that, on my Snow Leopard machine, I have only one drive but I am experiencing the same problem while launching install.sh 0.8.3, with:
"Warning: root device doesn't have an EFI partition"
"Could not find an EFI partition. Aborting!"
As the drive was formatted during OS X 10.6 install, the ESP has no name, hence the "EFI EFI" string is never matched in the sed command. I just replaced it with simply "EFI" and it worked fine.
So, I don't think this has to do with multiple drive, but rather how the drive was formatted and partitioned.
Cheers,
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In 0.8.1, OS X: Unable to mount ESP a user was having a problem related to the presence of two internal drives in a MacBook. ./install.sh --esp was failing for him. Joe van Tunen proposed a patch to install.sh to overcome the problem. Apparently it worked for that user.
I'm now in a similar boat but with 0.8.3 and an iMac with two internal (non-ejectable or removable) SSDs. /dev/disk0 is an empty drive with no partitions at all. /dev/disk1 has an ESP (disk1s1) as well as OS X 10.8.5 on it. I am running install.sh whilst booted into the latter.
Output includes:
"Warning: root device doesn't have an EFI partition"
"Could not find an EFI partition. Aborting!"
Examining the code, it seems that Joe's patch has been incorporated into the install.sh shipping with 0.8.3 even though neither that file's revision history or the 0.8.2/3 release notes make mention of it.
Why the patched version worked for the other user but not for me I do not know. In any case, by commenting out lines 449-469 and hard-coding Temp="disk1s1" immediately after that, I was able to get the script to successfully run and all is well.
As an idea to make the code a little simpler and more robust, I propose the following alternative logic for the 449-469 section of code:
1) the script determines what volume it is located on
2) the diskID is determined from the volume
3) parse the output of diskutil list <diskID> for occurrences of EFI
4) if one and only one such partition exists, use it and extract the diskIDsliceID
5) in all other cases, abort, display the output of diskutil list <diskID>, and attach an error message along the following lines:
"./install.sh --esp needs to be run from an OS X volume on a disk which also has one EFI system partition on it. Please relocate the rEFInd folder to such a volume/disk and try again."
The above approach makes it clear that the boot manager will be installed on the same disk that the installer is located on, eliminates the need to scan other disks for suitable ESPs, and does not require any code-based guesswork if multiple suitable ESPs are located.
If OS X users wish to deliberately and knowingly install rEFInd somewhere else, --ownhfs and --root are available to them.
Anyway, it's just an idea.
Thank you, Rod, for all the work you are doing on this project. Thanks also to all the patch submitters out there who are helping make it better.
Maybe we can figure out why it's not working for you.
Try the used commands one at a time:
One of the lines should like like this:
Then, using that disk name, try this:
Which should have one of the lines like this:
Putting it all together, try the following lines:
The first line of the result should be the root partition device and the second line should be the EFI partition on the disk containing the root partition like this:
Last edit: joevt 2014-10-14
Thanks for the step-through - it's making more sense now. That said, that code doesn't actually work for me. The first part is fine, but the second part returns no data. Even this fails directly from the command line:
Given that the following entry is the one we are interested in:
Should the second occurrence of EFI actually be in the regular expression-type-thing given that the EFI partition has no name? If we remove ' EFI' from the above we get:
...which was the desired output.
PS: And that would explain why MountOSXESP() is failing for me in install.sh — the code expects my ESPs to be named 'EFI' but they are not!
Last edit: Anonymous 2014-10-17
Does your EFI partition have a file system name? I thought diskutil always showed the file system name but maybe it doesn't do that if the partition isn't mounted? You could check diskutil before and after mounting the EFI partition.
This command shows the gpt names:
This command shows the gpt partition ids:
I guess we shouldn't assume the EFI partition has a name. Maybe it's enough that the partition has the correct type. EFI=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
In the script "EFI EFI[ ]+" should be replaced with "EFI .* " to ignore the name.
None of the ESPs on any of my computers are named. The diskutil listing is the same regardless of whether the ESP is mounted or not:
The drive was a clean install of OS X 10.8 Mountain Lion. I have never paid attention to ESP names up until now so I don't know if it has always been this way, or changed at some point. I have no other versions of OS X to check against, either.
For reference, here is the output from those other two commands:
PS: I have had time to do some research and the ESP is un-named in 10.4 Tiger, 10.5 Leopard, 10.6 Snow Leopard, 10.7 Lion and 10.8 Mountain Lion. The ESP is named EFI in 10.9 Mavericks and 10.10 Yosemite. Your suggested change to the regular expression will catch all of those cases.
Last edit: Anonymous 2014-10-18
Your output seems to confirm that diskutil does show the file system name (the gpt has a MacOSX partition which you've renamed to "Macintosh HD"). So I wonder why diskutil doesn't show the file system name for your EFI partition.
In my gpt, it's labeled as "EFI" and formatted as MS-DOS FAT32. Yours is labeled "EFI System Partition" in the gpt which means they were created differently.
Here's my diskutil info for the partition when it's mounted:
Hi all,
Please note that, on my Snow Leopard machine, I have only one drive but I am experiencing the same problem while launching install.sh 0.8.3, with:
"Warning: root device doesn't have an EFI partition"
"Could not find an EFI partition. Aborting!"
As the drive was formatted during OS X 10.6 install, the ESP has no name, hence the "EFI EFI" string is never matched in the sed command. I just replaced it with simply "EFI" and it worked fine.
So, I don't think this has to do with multiple drive, but rather how the drive was formatted and partitioned.
Cheers,
Marc