How to set a consistent location for drives mounted on boot?
-
29-05-2021 - |
문제
Each time I reboot my computer, when I run diskutil list
the order of the mounted drives changes: /dev/disk0 becomes /dev/disk1 and vice versa. This creates problems for applications and scripts that depend on finding specific information in a consistent location. So far, the only (unreliable) solution is to reboot the computer hoping the paths correct themselves.
I have also seen this question but none of the answers seemed to be a reliable long-term fix: Can I set a mount order via stab
Is there a way to set how the drives mount on boot so they are always at the same mounting location/path?
Update: I have found a similar question for Ubuntu here where the solution is to update the reference to drives to use their UUID. However, I have not found a similar UUID-based reference available in Mac: VirtualBox raw drive using UUID instead of device name
해결책 2
In short, it doesn't seem to be possible to set consistent disk locations. However, there are some workarounds that can be useful in certain workflows.
For my specific case: While Allan's response had some helpful info that played a part in the final solution, it alone was not able to solve my issue.
The only way I was able to solve this issue was to upgrade my scripts that launch VirtualBox to also
- Release the old virtual disk image then delete the .vmdk files
- Create a new virtual disk image and set the permissions (using Allan's diskutil snippets)
- Set the ownership for the new files
- Update the new .vmdk files to match the old .vmdk UUID
- Re-add the IDE controller and attach the .vmdk file as its medium
- Launch the VM.
While this is far more involved than I had hoped, so far this has been a much more consistent solution to the issue where the drives change their order.
The full script can be found below:
#release drives
dev="/dev/"
diskUUID=<the-disk-uuid>
diskXs2=$dev$(diskutil list ${diskUUID} | awk 'FNR == 5 { print $7 }')
diskXs4=$dev$(diskutil list ${diskUUID} | awk 'FNR == 7 { print $7 }')
if grep -qs '/Volumes/Bootcamp ' /proc/mounts; then
echo "Drive '/Volumes/Bootcamp' is now unmounted."
sudo diskutil unmount /Volumes/Bootcamp
else
echo "Drive '/Volumes/Bootcamp' is not mounted."
fi
sudo chmod 777 ${diskXs2}
sudo chmod 777 ${diskXs4
# Detach old disk image
vmUUID="<VM-UUID-HERE>"
MAX_PORT=$(vboxmanage showvminfo ${vmUUID} |grep "Storage Controller Max Port Count (0)" | awk '{print $7}' );
vboxmanage storagectl ${vmUUID} --name 'IDE' --portcount $MAX_PORT --remove
# Make new disk image
diskX=$(diskutil list ${diskUUID} | awk '/dev/ { print $1 } ')
if ls win10raw* 1> /dev/null 2>&1; then
rm win10raw*
fi
sudo /usr/local/bin/VBoxManage internalcommands createrawvmdk -rawdisk ${diskX} -filename win10raw.vmdk -partitions 2,4
# Update the new .vmdk files to match the old .vmdk UUID
oldVmdkUUID="<OLD_UUID>"
sed -i '' "25s|.*|ddb.uuid.image=""${oldVmdkUUID}"" |" "win10raw.vmdk"
if ls *.vmdk 1> /dev/null 2>&1; then
# echo "files do exist"
sudo chown <MY-USER> *.vmdk
fi
# Attach new disk image
/usr/local/bin/VBoxManage storagectl ${vmUUID} --name "IDE" --add ide
/usr/local/bin/VBoxManage storageattach ${vmUUID} --storagectl IDE --port 0 --device 0 --type hdd --medium "win10raw.vmdk"
# Launch the VM
nohup /usr/local/bin/VBoxManage startvm ${vmUUID} &
References:
- https://www.commandlinefu.com/commands/view/2926/get-a-list-of-all-your-virtualbox-virtual-machines-by-name-and-uuid-from-the-shell
- https://www.andreafortuna.org/2019/10/24/how-to-create-a-virtualbox-vm-from-command-line/
- https://organisemenet.wordpress.com/2017/01/05/bulk-delete-vbox-disk-medium/
- https://mezzantrop.wordpress.com/2016/10/18/quick-reference-for-adding-and-attaching-drives-in-virtualbox-cli/
- http://web.archive.org/web/20181103074214/http://danielphil.github.io/windows/virtualbox/osx/2015/08/25/virtualbox-boot-camp.html
다른 팁
Is there a way to set how the drives mount on boot so they are always at the same mounting location/path?
You don't need to specify the order in which they boot; you use the UUID. To get the UUID of a drive in macOS use the command:
% diskutil info diskXsY | grep -i UUID
where X is the disk number (i.e. /dev/disk5
) and Y is the slice or partition number (i.e. disk5s1
)
For example, I inserted a random USB flash disk that identified as /dev/disk7
. Issuing the command as detailed above
% diskutil info disk7s1 | grep -i UUID
Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B
Disk / Partition UUID: DF8CB142-B426-4F62-841C-5D26904CF54C
The Disk UUID is the second entry.
So, to identify this disk anytime it's been attached to the Mac, you can use the UUID. For example:
% diskutil list DF8CB142-B426-4F62-841C-5D26904CF54C
/dev/disk8 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *16.0 GB disk8
1: EFI EFI 209.7 MB disk8s1
2: Apple_CoreStorage MyTest 15.7 GB disk8s2
3: Apple_Boot Boot OS X 134.2 MB disk8s3
If you notice, it now has an identifier of disk8
. I had inserted another USB flash forcing the drive identifier to change proving that this is a valid method.
If you must use the drive identifier, create a function that determines the identifier via the UUID. For example, the following command will get your the disk identifier of the attached drive with the UUID:
% diskutil list DF8CB142-B426-4F62-841C-5D26904CF54C | awk '/dev/ { print $1 } '
/dev/disk8
You could create a Bash/Zsh function to return this info for you on demand.
Regarding non-removable media...
Each time I reboot my computer, when I run diskutil list the order of the mounted drives changes: /dev/disk0 becomes /dev/disk1 and vice versa
I can't see this happening. Non-removable media does not change. Your boot device is specified in NVRAM meaning /disk0
will be what you boot from and since it's defined in the preboot environment disk0
and disk1
will not swap places. The only time this can happen is during Recovery (you're booting from a different volume) but then, when booting from Recovery, you're not loading anything there, especially your VB app.
Now, if you're referring to removable devices, yes, it is possible for the identifier to change (I did it in my example). This is why you use the disk UUID to ensure you're always access the same drive regardless of when it gets attached.