Alan Hargreaves' Weblog

Tamarack, Gnome 2.17 and external devices

This is a combination that I've been hanging on. vold never quite handled my cds, dvds and usb media quite right.

I'm happy to say that for the most part it all just works like it should.

Well, I have a multi-partitioned usb device which exhibits an interesting problem.

First, let's have a look at how the device (it's a 60gb usb 2 disk) is partitioned.

             Total disk size is 57231 cylinders
             Cylinder size is 2048 (512 byte) blocks

                                               Cylinders
      Partition   Status    Type          Start   End   Length    %
      =========   ======    ============  =====   ===   ======   ===
          1                 Ext Win95         1  28615    28615     50
          2                 Solaris2      28616  57230    28615     50 

Partition 1 has a fat-32 filesystem.
Partition 2 has an SMI label and slice 0 is a zfs pool with the imaginitve name 'usb'.

# fstyp /dev/dsk/c4t0d0p1
pcfs
# fstyp /dev/dsk/c4t0d0s0
zfs

If I insert this disk into my notebook running b53, I get the notice about not being able to mount the zfs pool (which I expect), but it does not notice the fat-32 partition, let alone mount it:

# rmmount -l
/dev/dsk/c4t0d0s0    rmdisk,rmdisk0,usb

I had a chat with one one of the developers about this. He found that if we place the zfs pool directly into the second partition, then everything works as you would expect. The different controller numbers and zfs pool name are purely due to using another disk and machine in anotehr continent.

# fstyp /dev/dsk/c2t0d0p1
pcfs
# fstyp /dev/dsk/c2t0d0p2
zfs
# rmmount -l
/dev/dsk/c2t0d0p0:1  rmdisk,rmdisk0,NONAME,/media/NONAME
/dev/dsk/c2t0d0s2    rmdisk,rmdisk0,lacie_p2

It turns out that if hal discovers an SMI label on any partition, it does not probe any of the other logical disks, leading to the logging of

6502219 If SMI label exists, hal does not probe logical disks

In the meantime as I really don't want to muck around with the existing zpool, I'll continue to mount my pcfs manually, but it will be nice when this one is fixed.

It's probably also worth mentioning that "zpool import usb" just works.

Technorati Tags: SXCR, OpenSolaris

Posted at 10:51AM Dec 12, 2006 by Alan Hargreaves in OpenSolaris  | 

Gotcha bug for SXCR 53 and 54

A few folks have come across an issue after using live upgrade to go to build 54 of nevada, so to save some hassles for when it comes out as an SXCR, I thought I'd post this. It also seems that some folks hit it with 53.

It looks like after such a live upgrade the mountpoints for /tmp and /var/run are created with 0700 permissions. The /tmp permisssion will prevent a non-root login in gnome. The /var/run will cause more subtle issues with stuff that wants to access in there. One example of this would be from rhythmbox.

** (rhythmbox:1439): WARNING **: hal_initialize failed: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied

The actual issue is the permissions of the mount points, and you can't fix these in any way that will be persistant across reboots (as they are tmpfs's) unless you unmount the filesystems. You could try booting with "-m milestone=none" and fixing the underlying moountpoints, or you could try the following. If you don't have anything using those mountpoints yet, you'll get away with it.

# umount /tmp
# umount /var/run
# chmod 1777 /tmp
# chmod 755 /var/run
# mount /tmp
# mount /var/run

This has been logged as

6497684 Unable to login due to live upgrade setting incorrect permissions on /tmp and /var/run

Which, unfortunately is not available externally (being logged against live-upgrade.

Of course the preventative thing to do would be to mount the alternate boot environment and fix the permissions before booting it.

Technorati Tags: SXCR, OpenSolaris

Posted at 10:18AM Dec 12, 2006 by Alan Hargreaves in OpenSolaris  |