Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Statically assigning disk identifier

Is there a way to statically assign disk identifiers? My boot camp partition's identifier keeps moving around after each reboot. This causes applications like Parallels and VMWare to lose track of the partition since they locate by the disk identifier.

This has been a problem for VMWare and Parallels for a long, long time. It's not their issue though as it relates entirely to how OSX assigns disk identifiers.

Thanks!

Mac Pro, Mac OS X (10.6.2), Parallels 5, 4 hard drives

Posted on Nov 21, 2009 9:34 AM

Reply
13 replies

Nov 21, 2009 9:45 AM in response to xl600

I don't believe there is any way to do that. but I don't understand why this is a problem and why it would move around. os x assigns disk identifiers in sequence on each drive. so the bootcamp partition on the main drive should always be disk1s3. unless you have several partitions on the main drive beside the bootcamp partition and don't keep them mounted all the time?

Nov 21, 2009 10:04 AM in response to V.K.

Well, it certainly does move around on my Mac Pro 1,1. In fact, I tend to have to create one bootcamp VM for each HD identifier that it can be after any particular reboot.

Disk0s3
Disk1s3
Disk2s3
Disk3s3

(The bootcamp partition is s3 of course.. at least that stays the same..).

It's rather irritating and surprising that there's a random factor in the boot process. I suspect it has a lot to do with the variation in spin up speeds of the different drives, but that's only speculation.

Note that the main drive's identifier also moves around in the same way (Bootcamp and the main drive are on the same physical drive). This morning, it was Disk0. After I rebooted it's DIsk1. Tomorrow, it'll be something else (If I reboot). OSX itself doesn't have any issue with this of course, just applications which use drive ids like VMWare and Parallels.

Robert

Nov 21, 2009 12:27 PM in response to V.K.

Well, they don't. I'm not sure why. They're motivation to fix this issue is really low it seems as it only affects Mac owners with bootcamp and multiple physical hard drives (Probably not their major audience).

It's frustrating the Mac acts this way though and that there's no way to overcome it.

Nov 21, 2009 1:41 PM in response to xl600

xl600 wrote:
It's frustrating the Mac acts this way though and that there's no way to overcome it.


There isn't really anything Apple can do about how Windows identifies volumes, but something definitely isn't right within your OS X installation if the startup drive isn't always disk0 or if the slice number of its startup volume changes on different startups. Have you perhaps edited or added anything to /private/etc/, such as a fstab (file system table) file, or anything like that? (See the man page for fstab ( http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/m an5/fstab.5.html) & the linked man pages for more about file system identification & arbitration in OS X -- it pretty much conforms to common UNIX & UNIX-like standards for this, which is probably the real reason Apple would not change it to be more Windows-like. It would not be considered a fix!

Nov 22, 2009 7:56 AM in response to R C-R

I'm not sure what Windows would have to do with anything?

And no, there's been no modification of fstab types of files. Yet today, my startup drive is mapped as disk1s2 and my Time Machine drive is disk0s2. A few days ago it was disk2s2.

-----------------
bigmac:~ user1$ cd /private/etc/
bigmac:etc user1$ cat fstab.hd
IGNORE THIS FILE.
This file does nothing, contains no useful data, and might go away in
future releases. Do not depend on this file or its contents.
-----------------

Nov 22, 2009 10:31 AM in response to R C-R

Just to make it very clear what happens:

"diskutil list" returns the following:

/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *250.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Time Machine Backups 249.7 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *500.1 GB disk1
1: EFI 209.7 MB disk1s1
+2: Apple_HFS KaiOsX_HD 430.4 GB disk1s2+
3: Microsoft Basic Data KaiXP_C 69.3 GB disk1s3
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *500.1 GB disk2
1: EFI 209.7 MB disk2s1
2: Apple_HFS Digital Video 499.6 GB disk2s2

After a powerdown and reboot

/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *250.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Time Machine Backups 249.7 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *500.1 GB disk1
1: EFI 209.7 MB disk1s1
2: Apple_HFS Digital Video 499.6 GB disk1s2
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID partitionscheme *500.1 GB disk2
1: EFI 209.7 MB disk2s1
+2: Apple_HFS KaiOsX_HD 430.4 GB disk2s2+
3: Microsoft Basic Data KaiXP_C 69.3 GB disk2s3

Note the swap of disk1 and disk2 through reboots. Browsing the web, this seems to be mentioned in reference to the MacPro platform more than anything else (Probably because of the multiple drive bays).

Nov 22, 2009 12:53 PM in response to xl600

Note the swap of disk1 and disk2 through reboots.


Sure, but this is not unexpected behavior, since (I presume) neither of these disks contains the startup volume.

Browsing the web, this seems to be mentioned in reference to the MacPro platform more than anything else (Probably because of the multiple drive bays).


This is only somewhat related to the fact that the Pro has internal bays -- specifically it is because they have integral SATA bus connections that typically (but not always) initialize connected drives faster at startup than external bus-connected ones like USB or Firewire.

The normal startup sequence (IOW, booting normally into Mac OS X) first attempts to initialize the drive with the volume on it designated in PRAM as the startup volume, which becomes disk0, then polls for any other available drives. They are assigned device ID strings & nodes in the order they become available. This insures the fastest possible startup because in some configurations the OS might be using a different drive for VM, User folders, or whatever. This not specific to the Mac Pro; in this respect all modern Macs are the same.

If you refer to the "DEVICES" section of the man page for diskutil, you will note that there are four ways provided to refer to a disk partition. The first two (string & node ID's) are never reliably constant & unchanging (because of the above). The volume mount point is constant (as long as you don't change the path name) & the Universally Unique Identifier (UUID), as the name suggests, survives even a path name change.

For this reason, the UUID the preferred way to refer to a volume when an unchanging reference is required. For instance, note from the previously mentioned link about using the fstab file (which is not the same thing as the fstab.hd file, which the man page for fstab should make clear), the file reference is in the UUID form. This is the form you should use too, at least where unchanging references are what you need.

Nov 22, 2009 9:47 PM in response to R C-R

KaiOSX_HD is indeed the startup volume. Thus the notion that Disk0 is always the startup volume is incorrect. Why, I can't say. Is it because all three drives have EFI partitions?

Regardless, I've contacted Parallels to ask them why UUID isn't being used. I've asked them about this many times before but I never get any reasonable response like "Yeah, we're going to fix that in version xx...". Parallels 3,4, and now 5 have all had problems in this area. VMWare I think has also had past issues (I'm no longer running VMWare though).

Thanks,

Robert

Nov 23, 2009 3:02 AM in response to xl600

xl600 wrote:
KaiOSX_HD is indeed the startup volume. Thus the notion that Disk0 is always the startup volume is incorrect. Why, I can't say. Is it because all three drives have EFI partitions?


Are you starting up normally or (for instance) using the option key at boot time to invoke the Startup Manager & override the Startup Disk setting stored in PRAM? Do you maybe briefly see a question mark at boot time, indicating that either no Startup Disk has been set or one that is not actually attached to the Mac is set?

Otherwise, maybe I'm wrong about disk0 always being the startup disk. To be honest, I haven't had a multi-bay Mac for years, since the days of System 8, so I'm extrapolating from what I see with my single internal drive Macs & OS X.

However, even if I'm wrong about that, I can't imagine why the startup disk would switch between disk2 & disk3 on different start ups, unless perhaps the drives have some problems or possibly Parallels is somehow to blame, although I can't image how.

At this point all I can suggest is that if you haven't already done so, make sure Disk Utility finds no problems with any of the drives, try a PRAM reset & then make sure that the appropriate volume is set in the Startup Disk system preference. But at best, this should just give you consistent string & node ID assignments for the startup disk on different start ups, which really doesn't solve the Parallels problem.

Nov 23, 2009 7:05 AM in response to R C-R

Nope. I rarely use the option at boot and I haven't noticed any question mark on the screen. Disk utility shows no issues and I've tried PRAM reset in the past. I think this is just one of those oddities of the MacPro design.

I'm wondering if Parallels can be fooled into using an fstab defined name for the bootcamp partition?

Thanks,

Robert

Statically assigning disk identifier

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.