Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
Darren Pilgrim [EMAIL PROTECTED] writes:
GEOM doesn't automatically read the partition table and create the
slice device [...]
Yes, it does. When the umassX provider shows up, GEOM immediately
tastes it and creates geoms for the individual slices.
If it really doesn't on your system, try the following:
# /etc/rc.d/devd stop
# logger START
# sysctl debug.bootverbose=1
# sysctl -b kern.geom.conftxt geom-before
[insert umass device, wait 10 secs]
# sysctl -b kern.geom.conftxt geom-after
# sysctl debug.bootverbose=0
# logger STOP
# /etc/rc.d/devd start
# awk '/START/{s=1}{if(s)print}/STOP/{s=0}' /var/log/messages geom-logs
then post the contents of geom-{before,after,logs}.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED]
Darren Pilgrim [EMAIL PROTECTED] writes:
GEOM doesn't automatically read the partition table and create the
slice device [...]
Yes, it does. When the umassX provider shows up, GEOM immediately
tastes it and creates geoms for the individual slices.
If it really doesn't on your system, try the following:
# /etc/rc.d/devd stop
# logger START
# sysctl debug.bootverbose=1
# sysctl -b kern.geom.conftxt geom-before
[insert umass device, wait 10 secs]
# sysctl -b kern.geom.conftxt geom-after
# sysctl debug.bootverbose=0
# logger STOP
# /etc/rc.d/devd start
# awk '/START/{s=1}{if(s)print}/STOP/{s=0}' /var/log/messages
geom-logs
then post the contents of geom-{before,after,logs}.
Attached as named above. The logs show the da0 DISK class in the GEOM
config, but no MBR class entry.
This is on -current as of May 22.
geom-before
Description: Binary data
geom-after
Description: Binary data
geom-logs
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
Darren Pilgrim [EMAIL PROTECTED] writes: Attached as named above. The logs show the da0 DISK class in the GEOM config, but no MBR class entry. Take a closer look at geom-logs. It shows a slew of CAM errors. There's something wrong with your fob, or possibly (but not likely) with the USB stack. Here's what I get in a similar scenario: Jun 10 09:14:02 xps des: START Jun 10 09:14:06 xps kernel: umass0: vendor 0x0d7d USB DISK, rev 1.10/1.00, addr 5 Jun 10 09:14:06 xps kernel: umass0:0:0:-1: Attached to scbus0 Jun 10 09:14:07 xps kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 Jun 10 09:14:07 xps kernel: pass0: USB DISK 1.20 Removable Direct Access SCSI-0 device Jun 10 09:14:07 xps kernel: pass0: Serial Number Jun 10 09:14:07 xps kernel: pass0: 1.000MB/s transfers Jun 10 09:14:07 xps kernel: GEOM: new disk da0 Jun 10 09:14:07 xps kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jun 10 09:14:07 xps kernel: da0: USB DISK 1.20 Removable Direct Access SCSI-0 device Jun 10 09:14:07 xps kernel: da0: Serial Number Jun 10 09:14:07 xps kernel: da0: 1.000MB/s transfers Jun 10 09:14:07 xps kernel: da0: 31MB (64000 512 byte sectors: 64H 32S/T 31C) Jun 10 09:14:13 xps des: STOP except my fob is unpartitioned (like a floppy), which is why I only get da0. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
-Original Message- From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 12:16 AM To: Darren Pilgrim Cc: freebsd-hackers@freebsd.org Subject: Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices Darren Pilgrim [EMAIL PROTECTED] writes: Attached as named above. The logs show the da0 DISK class in the GEOM config, but no MBR class entry. Take a closer look at geom-logs. It shows a slew of CAM errors. There's something wrong with your fob, or possibly (but not likely) with the USB stack. Except that after all those errors, it still mounts and works fine. Also, trying to mount /dev/da0 does produce the MBR entry in the GEOM config: 1 MBR da0s1 255849984 512 i 0 o 2048 ty 11 It also produces a single READ CAPACITY CAM error like those produced when the device attaches. I also tested with a known-good USB zip drive plugged into the same USB port. It attached flawlessly: the console showed the normal attach messages, GEOM config shows the appropriate MBR entry and /dev/da0s4 is created. So yeah I gueuss my fob is busted or funky. The CAM errors are just the drive saying there's no media present, so maybe the device doesn't support the commands necessary to report disk capacity? Is there a way to educate CAM about this so the attach procedure doesn't break? Why would the CAM errors prevent GEOM from creating the MBR geom during attach but not when trying to mount /dev/da0? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Determining disk device and kicking GEOM when doing automatic mounting of umass devices
I want to have a devd entry that automatically mounts umass devices when
they get attached. The problem is figuring out which device to mount and
then getting the correct devices created. For example, the entry for my
thumbdrive:
attach 1000 {
device-name umass[0-9]+;
match vendor 0x08ec;
match product 0x0015;
match sernum 0C50935151F0EA20;
action $scripts/mount_umass.sh $device-name msdosfs /stickdrive;
};
The mount_umass.sh script is as follows:
---BEGIN FILE---
sleep 10
scsidev=`echo ${1} | sed s/umass/umass-sim/g`
diskdev=`camcontrol devlist -v | grep -A 1 ${scsidev} | tail -n 1 | \
awk -F ( '{ print $2 }' | awk -F , '{ print $1 }'`
fstype=${2}
mountpoint=${3}
mount -t ${fstype} /dev/${diskdev} ${mountpoint} 2/dev/null
mount -t ${fstype} /dev/${diskdev}s1 ${mountpoint} 2/dev/null
END FILE
First, the script has to sleep because the device doesn't immediately show
up in the CAM device list. After waiting long enough to be safe, the script
takes the device name passed by devd and uses it to parse the device name
from the output of `camcontrol devlist`. GEOM doesn't automatically read
the partition table and create the slice device, so the script forces it to
do so by trying to mount the base device before mounting the actual
partition.
These tricks are ridiculous, IMO. There has to be a more intelligent means
of going about this. How do I get the scsi disk device name created for a
umass device as soon as it's created? How do I inform GEOM that it needs to
add a new MBR to it's configuration and create the appropriate /dev/da?s*
devices?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : These tricks are ridiculous, IMO. There has to be a more intelligent means : of going about this. How do I get the scsi disk device name created for a : umass device as soon as it's created? How do I inform GEOM that it needs to : add a new MBR to it's configuration and create the appropriate /dev/da?s* : devices? One way is to make devd grok devices arriving and leaving from /dev. One could kludge it to send out geom events, but I think that's insufficiently general since it reports too many things that aren't of interest. Of course, you have no way of knowing what entries in /dev really are, apart from pattern matching. As to your second question, GEOM and/or da (it depends on who you ask) need to react to certain events and re-taste the device. This isn't done automatically, especially when da0 changes from a 32MB to a 64MB part, for reasons I've never known. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
