[IMPLEMENTED] A way to hide non-bootable drives...

[Gounah]

It would be nice to choose which drives will be displayed.

Thank you! I really appreciate your work!

[BladeRunner]

I too would like to see this feature added.

In OS X the /etc/fstab can identify partitions by UUID and then provide a "noauto" parameter which stops partitions from being mounted at boot time.  Maybe a similar mechanism could be added to Chameleon.

[dapetcu21]

Maby witch drives to be shown and with what name

[Gringo Vermelho]

Unless I misunderstand the 'noauto' parameter, editing fstab is not an option for me because I still want the unbootable drives mounted. I just don't want to see them as selectable boot targets.

I don't know if it's technically possible but something simple like 'hidepartition=disk1s3' in boot.plist would be great.

[BladeRunner]

That is not what I meant.  I know that editing the /etc/fstab would not do it.  I have my Win7 partition referenced there so it does not mount, but  it still shows in the Chameleon loader menu.

What I meant was to try using a Chameleon control file in /Extra which used a uuid=  syntax to identify a partition and what to do with it.

Sorry I did not make myself clear.

[sckevyn]

I too would like to see this feature added.

In OS X the /etc/fstab can identify partitions by UUID and then provide a "noauto" parameter which stops partitions from being mounted at boot time.  Maybe a similar mechanism could be added to Chameleon.

The problem with using fstab is it picks by UUID, so if you have 1 drive, you cannot do the "noauto" trick. It won't complete booting before it reboots due to no mountable file systems =)

Hopefully we'll come up with something in regards to this, but right now we're working on bigger bugs atm.

sckevyn

[zhell]

I'm not trying to push this issue at all, as to me it's a cosmetic one.

I do not understand the previous post by sckevyn.
As a cosmetic issue, it should feasible to fix at the cosmetic layer, but probably I'm missing something important.

Why can't you add  some boot.plist key "Hide Partitions" of type array, which the user populates with UUIDs (and if you like with BIOS device specs as are used in the current "Default Partition" key).

Then, before displaying a partition in the GUI, just compare its UUIDs (or BIOS device spec) to the above array.

In the console partition selector, one might want to have all partitions listed to be able to recover from mishaps editing the "Hide Partition" key...

zhell

[sckevyn]

I'm not trying to push this issue at all, as to me it's a cosmetic one.

I do not understand the previous post by sckevyn.
As a cosmetic issue, it should feasible to fix at the cosmetic layer, but probably I'm missing something important.

Why can't you add  some boot.plist key "Hide Partitions" of type array, which the user populates with UUIDs (and if you like with BIOS device specs as are used in the current "Default Partition" key).

Then, before displaying a partition in the GUI, just compare its UUIDs (or BIOS device spec) to the above array.

In the console partition selector, one might want to have all partitions listed to be able to recover from mishaps editing the "Hide Partition" key...

dp35dp

dp35dp,

UUID's cover the entire drive, not just a partition. This is why you cannot use UUID to mask a partition, OS X by default will mask the ENTIRE UUID, which is EVERY partition on that drive, not just 1 specific one. my HD for instance has 3 partitions

/dev/disk0s1 ntfs <-- laptop restore partition
/dev/disk0s2 ntfs <-- laptop XP Pro partition
/dev/disk0s3 hfs <-- OS X 10.5.6 install

all of them have the same UUID as they are physically on the same drive if I mask 1 of them by UUID, I masked them all... I would love for Chameleon to not to see the restore partition ever for obvious reasons but that code isn't in place yet.

As far as it being a cosmetic change, it's more code than you would think. Definitely not a "cosmetic" change =)

sckevyn

[zhell]

Thanks so much for elaborating, sckevyn.

It was my mistake to assume that we were talking about GPT or GPT+MBR disks. There, every HFS+ and NTFS partition has a UUID, at least on my system:
root@blue ~# for part in `diskutil list | sed -En 's/.*(disk0s.)/\1/p'`; do echo ${part}: `diskutil info $part | grep UUID`; done 
disk0s1:
disk0s2: Volume UUID: 302F82E3-D05F-38A1-BFF8-439CD0E69BAF
disk0s3: Volume UUID: 8A5DD1EC-0BE1-3E17-836C-1BC21FECA7DB
disk0s4: Volume UUID: A020FA1E-97D4-4341-BEE6-81BBBD513FBF
disk0s5:

disk0s1 is the EFI partition (FAT32) and disk0s5 is a ZFS slice, neither of which can currently be used as a system partition.

So for GPT disks, it should indeed be a cosmetic change (given that you are able to read the UUID, but I think you seem to be passing "boot-uuid=<UUID>" to the kernel when the user selects a disk, so it should be there).

However, if a disk is only MBR formatted, it's up to the filesystem to provide a UUID for the partition it lives in. Most popular UNIX filesystems (ReiserFS, ext2/3, JFS, XFS, and probably ZFS on Open Solaris) support that.

Windows (FAT32/NTFS) is a different story. Still, the Linux kernel somehow provides UUIDs for even those partitions (at /dev/disk/by-uuid/).

A hybrid way could be to let "Hide Partition" be a dictionary that has as siblings
- for GPT disks: An array of UUIDs
- for MBR disks: A string with the disk's UUID from the MBR plus an array of partition numbers.

Thanks,
zhell

[BladeRunner]

Thanks so much for elaborating, sckevyn.

It was my mistake to assume that we were talking about GPT or GPT+MBR disks. There, every HFS+ and NTFS partition has a UUID, at least on my system:

--snip --

A hybrid way could be to let "Hide Partition" be a dictionary that has as siblings
- for GPT disks: An array of UUIDs
- for MBR disks: A string with the disk's UUID from the MBR plus an array of partition numbers.

Thanks,
dp35dp

I like your idea about a hybrid array of partition IDs.  However, I see a couple of problems.  First, such a structure could be somewhat complex to configure correctly and could cause problems if implemented in the Boot.plist.  I think it would be safer to implement it as a separate, optional control file found in the EFI or Extra folders.

Second, the BISO ID - hd(0,2) - can shift around depending on what is plugged into the USB/FireWire ports at boot time. Not sure how to resolve this problem.

Maybe a standalone utility which borrows Chameleon code could be implemented to generate such a configuration file.  That might reduce the amount of support requests in the forum and be easier in the long run.

[zhell]

I like your idea about a hybrid array of partition IDs.  However, I see a couple of problems.  First, such a structure could be somewhat complex to configure correctly and could cause problems if implemented in the Boot.plist.  I think it would be safer to implement it as a separate, optional control file found in the EFI or Extra folders.

I think this is a matter of taste.

I would most like to have a separate Chameleon-specific hu.osx86.chameleon.[boot.]plist file and only use the com.apple.Boot.plist to override values set in /L/P/SC/com.apple.Boot.plist file on the actual system volume selected by the user.

If so desired, the plist format allows to have several sections that could then be split into separate plist files (smbios.plist, device-properties.plist, etc) if the user so desires and would be merged by Chameleon, separate plist files overriding values in the master plist.

Second, the BISO ID - hd(0,2) - can shift around depending on what is plugged into the USB/FireWire ports at boot time. Not sure how to resolve this problem.

I am with you here. In fact, I only referred to that because the Chameleon team has used it for "Default Partition". I have already added a feature request, see here: http://forum.voodooprojects.org/index.php/topic,34.0.html
The problem can be solved without risking drives shifting around as I described. MBR drives have a UUID per drive and GPT drives have one per partition.

Maybe a standalone utility which borrows Chameleon code could be implemented to generate such a configuration file.  That might reduce the amount of support requests in the forum and be easier in the long run.

Definitely agree. plist files were never meant to be edited by users. Also, there are two command line tools that I use most of the time: defaults and PlistBuddy. Be aware that defaults changes the plist to binary format, so you have to convert it back to plain text using plutil.

Thanks for your thoughts,
zhell

[chrisd]

Although it's not as glamorous as embedding UUIDs in a .plist file, how about using a file at the root of the drive to mark it as hidden from the boot menu.  Something like the .ntfs-readonly file that ntfs-3g uses to bypass read/write mounting on a drive (http://www.macosxhints.com/article.php?story=20080101043841537).   I would think this would be an easier solution to implement.

Just a thought....

[zhell]

Although it's not as glamorous as embedding UUIDs in a .plist file, how about using a file at the root of the drive to mark it as hidden from the boot menu.  Something like the .ntfs-readonly file that ntfs-3g uses to bypass read/write mounting on a drive (http://www.macosxhints.com/article.php?story=20080101043841537).   I would think this would be an easier solution to implement.

Just a thought....

Surely also a possibility. A drawback crossing my mind is that this would mean that I have to boot Windows or Linux to be able to change whether or not to hide the partition, as OS X doesn't support NTFS or any Linux FS read-write...

[chrisd]

Surely also a possibility. A drawback crossing my mind is that this would mean that I have to boot Windows or Linux to be able to change whether or not to hide the partition, as OS X doesn't support NTFS or any Linux FS read-write...

True for ext2/ext3, but for NTFS you can use MacFUSE (ntfs-3g) to mount read/write.  A word of caution on this though - MacOS will stick .DS_Store (and other hidden) files all over your NTFS drives if you mount them read/write.  I don't like that on my Windows boot partition, so I use the .ntfs-readonly file at the root to have that volume mount read-only.

As for creating the files, I don't change which drives I do and don't boot from often so it would be a one-time hassle for me to boot to Linux to create these files in order to make the right drives show up in the boot menu.

Even with the hassle of rebooting to the other OS, to me it still seems like a more mainstream solution than something that requires either a user to understand UUIDs or an application to make the .plist because the config is so complex. 

[zhell]

I am not against your idea; it definitely would be very useful if it were implemented and suit the needs of most users.

Still, I stand by my proposal; I think someone who has so many partitions that they want to hide some of them probably would be able to (i) get the UUIDs and (ii) edit the plist file.

Obviously, ideally there would be a System Preferences pane for Chameleon :-)

Maybe ~pcwiz or another GUI aficionado[1] could whip up something...

[1] afi·cio·na·do, noun: a person who likes, knows about, and appreciates a usually fervently pursued interest or activity