Felipe Alfaro Solana

I have been fighting for quite some time to get Solaris 10 installed and working properly under VMwae Fusion 1.1 on an Intel Core 2 Duo Mac. I think this is an interaction problem between VMware Fusion and Solaris 10. Even if you tell VMware Fusion that you want to install Solaris in 32-bit mode, VMware doesn’t disable the 64-bit, long-word instruction support (available from the host). Thus, Solaris 10 is able to detect that 64-bit, long-word instructions are available and boots a 64-bit kernel. VMware then complains about the fact that the virtual machine was configured in 32-bit mode but the guest is trying to execute 64-bit instructions.

The work-around is pretty easy: it consists of disabling 64-bit, long-word instructions in the VMware configuration file for the guest. This is described in greater detail in article Installing Solaris 10 as a 32-Bit Guest Operating System on a 64-Bit Host Machine but consists mainly in editing the .vmx virtual machine’s configuration file and adding the following line:

monitor_control.disable_longmode = 1

Rebooting the installation, or booting an already installed virtual machine system should make Solaris boot into 32-bit mode.

Disclaimer: What I’m describing in this post is not new. Much on the contrary, it is well known and understood, but I wanted to document this because it can be a little bit confusing if you are used to System V, like Sun’s Solaris.

Depending on whether you are using a BSD-like or System V-like systen, the owner of a file system object (file or directory, for example) might be different.

In System V or similar systems, while creating a new file in a directory, the file is owned, by default, by the user’s primary group — remember that every UNIX user has only one primary group, but can belong to many secondary groups (and this limit is usually vendor-specific, and usually near 32) —. An exception to this rule is when the directory has the SetGID bit set.

For example, on Solaris 10:

Sun Microsystems Inc. SunOS 5.11 snv_74 October 2007
# id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),
5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)
# mkdir -p /tmp/foo
# chgrp nuucp /tmp/foo
# ls -ld /tmp/foo
drwxr-xr-x 2 root nuucp 69 Oct 11 17:10 /tmp/foo
# touch /tmp/foo/bar
# ls -l /tmp/foo/bar
-rw-r--r-- 1 root root 0 Oct 11 17:11 /tmp/foo/bar

Since the primary group for user root is group root, and the directory has the setgid permission bit turned off, the file is owned by group root.

However, for directories that have the setgid permission bit turned on the semantics change: creating files and directories within a directory that has the setgid permission bit enabled causes those files and directories to inherit the group from the directory. That is, those files and directories will be owned by the same group as the directory they are contained in:

# rm -f /tmp/foo/bar
# chmod g+s /tmp/foo
# ls -ld /tmp/foo
drwxr-sr-x 2 root nuucp 105 Oct 11 17:11 /tmp/foo
# touch /tmp/foo/bar
# ls -l /tmp/foo/bar
-rw-r--r-- 1 root nuucp 0 Oct 11 17:11 /tmp/foo/bar

However, this is not what I was seeing on Mac OS X, a BSD-like system based on Darwin.

On my Mac OS X laptop, I’m used to store big files (like ISO images) under /Users/Shared. This stems from the fact that I normally use FileVault to encrypt my own files and Mac OS X performs bad when trying to encrypt huge files at high speed (like when copying an ISO file over a Gigabit network using rsync into a FileVault-protected home directory). But I’m digressing. In a default install, /Users/Shared is owned by wheel. What I saw is that all files that I was dropping in /Users/Shared were owned by group wheel while the primary group for my own user is not.

It turns out that the semantic for the creation of new file system entries (files and directories) in BSD-like systems (OpenBSD, FreeBSD, Darwin, Mac OS X, and so on) is exactly the same as the semantics of System V for directories that have the setgid bit enabled. Well, in fact, to be fair, is the other way around: in System V, enabling the setgid bit in a directory makes the directory use the BSD semantics. This is described in the Filesystems HOWTO from The Linux Documentation Project.

BSD semantics says that an object (file or directory), whle being created, always inherits the owning group from the directory where the object is created (no matter if the setgid bit in the parent directory is set or not). Although this makes a lot of sense, sometimes, I prefer the System V semantics that allow any user to decide whether to use BSD semantics or the old System V semantics via the setgid bit. Also remember that System V semantics dictate that if a directory has the setgid bit turned on, any new subdirectory created below it will also inherit the setgid bit.

Recently I purchased two external USB hard-drives, one from LACIE and another one from IOMEGA, that I plugged into one of my Linux workstations. I wanted these drives to be auto-mounted during boot, so I created a couple of entries in /etc/fstab. The problem is that, somehow, the Linux kernel is not always able to enumerate devices on a bus in the same order between reboots. Thus, sometimes the LACIE hard disk gets /dev/sdb and IOMEGA gets /dev/sdc, and other times it is the other way around. In fact, it gets even worse as my machine as a built-in 6×1 card-reader, so I also have /dev/sd{d,e,f,g}.

Looking at /etc/udev/rules.d, I found that Ubuntu has a nice 65-persistent-disk.rules file with very smart and useful udev entries that create symlinks under /dev/disk by disk ID, disk label, device path and device UUID:

• /dev/disk/by-id contains one symlink per physical device and partition. The symlink name is built using the device’s ID.
• /dev/disk/by-label contains one symlink per partition. The symlink name is built using the partition volume label.
• /dev/disk/by-path contains one symlink per physical device and parition. The symlink name is built using the device bus name.
• /dev/disk/by-uuid contains one symlink per partition. The symlink name is built using the partition UUID.

For example:

$ tree /dev/disk
/dev/disk
|-- by-id
| |-- scsi-1ATA_WDC_WD1600JS-75NCB2_WD-WCANM44 -> ../../sda
| |-- scsi-1ATA_WDC_WD1600JS-75NCB2_WD-WCANM44-part1 -> ../../sda1
| |-- scsi-1ATA_WDC_WD1600JS-75NCB2_WD-WCANM44-part2 -> ../../sda2
| |-- scsi-1ATA_WDC_WD1600JS-75NCB2_WD-WCANM44-part5 -> ../../sda5
| |-- scsi-1ATA_WDC_WD1600JS-75NCB2_WD-WCANM44-part6 -> ../../sda6
| |-- usb-Generic_Flash_HS-CF_26020128B005 -> ../../sdd
| `-- usb-Generic_Flash_HS-COMBO_26020128B005 -> ../../sde
|-- by-label
| `-- DellUtility -> ../../sda1
|-- by-path
| |-- pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../scd0
| |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sda2
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part5 -> ../../sda5
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
| |-- usb-26020128B005:0:0:0 -> ../../sdd
| `-- usb-26020128B005:0:0:1 -> ../../sde
`-- by-uuid
|-- 07D6-0701 -> ../../sda1
|-- 29982b9e-63a4-4d3f-8b88-ebc9d000c09f -> ../../sda5
`-- 6aa8745b-dbe2-4386-9697-cc0c2dee27d4 -> ../../sda6


Basically, what I did is replacing the entries I previously created in /et/fstab using absolute device names, like /dev/sdb1, with /dev/disk/by-label/<VOLUME> instead.

Name stability and predictability across reboots for devices is quite a nice feature in Ubuntu Linux. And this can be easily ported to other Linux distributions simply by copying /etc/udev/rules.d/65-persistent-disk.rules.