Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
"Marco d'Itri" writes: > On Nov 15, Bjørn Mork wrote: > >> OK. I'm currently running linux-image-3.1.0-1-amd64 version 3.1.1-1, >> but I had this problem with the previous kernel as well >> (linux-image-3.0.0-2-amd64 version 3.0.0-6). Unfortunately I am not >> entirely sure when things worked the last time, as the whole external >> disk thing is something I use rarely. > Even if it never worked, this still does not mean that udev is at fault. I must admit that I am much more interested in making it work (again) than who's to blame for the bug... Anyway, a couple of new data points: - downgrading the kernel to linux-image-2.6.32-5-amd64 version 2.6.32-38 did not make any difference - downgrading udev from version 172-1 to version 164-3 did not make any difference either I'm started to wonder if this is just something that used to work by sheer luck, and that there isn't really any new bug at all. If it's OK with you, I'll try a couple of other things (like older kernels) before closing it. Bjørn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
On Nov 15, Bjørn Mork wrote: > OK. I'm currently running linux-image-3.1.0-1-amd64 version 3.1.1-1, > but I had this problem with the previous kernel as well > (linux-image-3.0.0-2-amd64 version 3.0.0-6). Unfortunately I am not > entirely sure when things worked the last time, as the whole external > disk thing is something I use rarely. Even if it never worked, this still does not mean that udev is at fault. -- ciao, Marco signature.asc Description: Digital signature
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
"Marco d'Itri" writes: > On Nov 15, Michael Biebl wrote: > >> It sounds like running udisks-daemon triggers a uevent which causes udev >> to probe the partition on that device. > Probably by opening the block device. > >> Marco, do you have maybe an idea why the partition is not correctly >> probed initially? > No, but I would start looking at the kernel. OK. I'm currently running linux-image-3.1.0-1-amd64 version 3.1.1-1, but I had this problem with the previous kernel as well (linux-image-3.0.0-2-amd64 version 3.0.0-6). Unfortunately I am not entirely sure when things worked the last time, as the whole external disk thing is something I use rarely. I will try to install a recent squeeze kernel and see if that helps. Can I do that without downgrading udev? Well, I'll try anyway :-) Thanks for the very helpful feedback, both of you. Bjørn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
On Nov 15, Michael Biebl wrote: > It sounds like running udisks-daemon triggers a uevent which causes udev > to probe the partition on that device. Probably by opening the block device. > Marco, do you have maybe an idea why the partition is not correctly > probed initially? No, but I would start looking at the kernel. -- ciao, Marco signature.asc Description: Digital signature
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
reassign 648810 udev 172-1
thanks
Michael Biebl writes:
> What exactly used to work? udisks-daemon has always been started on
> demand so I fail to see the regression wrt udisks.
Right. Sorry about jumping to conclusions when noticing that simply
running "udisks --dump" fixed my problem.
I'm reassigning this bug to udev now, hoping that is more correct
>> My question is really "what service is responsible for calling the
>> BLKRRPART ioctl whenever a new disk is detected?"
>
> $ grep blkid /lib/udev/rules.d/*
> /lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{program}="/sbin/blkid
> -o udev -p $tempnode"
> /lib/udev/rules.d/60-persistent-storage.rules:
> IMPORT{program}="/sbin/blkid -o udev -p -u noraid -O
> $env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"
> /lib/udev/rules.d/60-persistent-storage.rules:
> IMPORT{program}="/sbin/blkid -o udev -p -u noraid $tempnode"
> /lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
> IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
Thanks. I just verified that running
/sbin/blkid -o udev -p /dev/sdb
does fix the problem for me as well. So I should probably look for any
rule changes which may cause this rule to be skipped.
> That sounds like either an issue in udev or the kernel not generating
> proper uevents when the device is plugged in.
>
> It sounds like running udisks-daemon triggers a uevent which causes udev
> to probe the partition on that device.
>
> Marco, do you have maybe an idea why the partition is not correctly
> probed initially?
>
> Bjørn, what does udevadm info --query=all --name=sdb show after you
> plugged in your device (and udisks daemon is not running).
nemi:/tmp# udevadm info --query=all --name=sdb
P:
/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host15/target15:0:0/15:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-SEMC_Mass_Storage_43423531314D42573144-0:0
S: disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
E: UDEV_LOG=3
E:
DEVPATH=/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host15/target15:0:0/15:0:0:0/block/sdb
E: MAJOR=8
E: MINOR=16
E: DEVNAME=/dev/sdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_VENDOR=SEMC
E: ID_VENDOR_ENC=SEMC\x20\x20\x20\x20
E: ID_VENDOR_ID=0fce
E: ID_MODEL=Mass_Storage
E: ID_MODEL_ENC=Mass\x20Storage\x20\x20\x20\x20
E: ID_MODEL_ID=3138
E: ID_REVISION=0001
E: ID_SERIAL=SEMC_Mass_Storage_43423531314D42573144-0:0
E: ID_SERIAL_SHORT=43423531314D42573144
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usb-storage
E: ID_PATH=pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-_00_1d_7-usb-0_1_1_0-scsi-0_0_0_0
E: UDISKS_PRESENTATION_NOPOLICY=0
E: DEVLINKS=/dev/disk/by-id/usb-SEMC_Mass_Storage_43423531314D42573144-0:0
/dev/disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
nemi:/tmp# cat /proc/partitions
major minor #blocks name
80 125034840 sda
81 129724 sda1
82 124904988 sda2
2540 124903960 dm-0
2541 119668736 dm-1
25425234688 dm-2
> If you run "echo change > /sys/block/sdb/uevent", do you partitions show
> up? how does the udevadm info look then?
Yes, they do:
nemi:/tmp# echo change > /sys/block/sdb/uevent
nemi:/tmp# cat /proc/partitions
major minor #blocks name
80 125034840 sda
81 129724 sda1
82 124904988 sda2
2540 124903960 dm-0
2541 119668736 dm-1
25425234688 dm-2
8 16 15558144 sdb
8 17 15554048 sdb1
nemi:/tmp# udevadm info --query=all --name=sdb
P:
/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host15/target15:0:0/15:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-SEMC_Mass_Storage_43423531314D42573144-0:0
S: disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
E: UDEV_LOG=3
E:
DEVPATH=/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host15/target15:0:0/15:0:0:0/block/sdb
E: MAJOR=8
E: MINOR=16
E: DEVNAME=/dev/sdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_VENDOR=SEMC
E: ID_VENDOR_ENC=SEMC\x20\x20\x20\x20
E: ID_VENDOR_ID=0fce
E: ID_MODEL=Mass_Storage
E: ID_MODEL_ENC=Mass\x20Storage\x20\x20\x20\x20
E: ID_MODEL_ID=3138
E: ID_REVISION=0001
E: ID_SERIAL=SEMC_Mass_Storage_43423531314D42573144-0:0
E: ID_SERIAL_SHORT=43423531314D42573144
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usb-storage
E: ID_PATH=pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-_00_1d_7-usb-0_1_1_0-scsi-0_0_0_0
E: ID_PART_TABLE_TYPE=dos
E: UDISKS_PRESENTATION_NOPOLICY=0
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-id/usb-SEMC_Mass_Storage_43423531314D42573144-0:0
/dev/disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
>From the looks of it, it seems that the "change" event caused both
/sbin/blkid (adding ID_PART_TABLE_TYPE) and /lib/udev/udisks-part-id
(addi
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
On 15.11.2011 12:32, Bjørn Mork wrote:
> Michael Biebl writes:
>
>> I can't see the usability regression.
>
> OK. I certainly don't have the full picture here, and this might be a
> bug in some other part of the puzzle. If you can provide any pointers
> where to look further, then I'd appreciate that.
>
> But the observed fact on my laptop is that this used to work out of the
> box, and it doesn't anymore after upgrading to wheezy. That's why I
> labelled it "regression".
What exactly used to work? udisks-daemon has always been started on
demand so I fail to see the regression wrt udisks.
>> If no one is using the udisks service, why should it be started?
>
> If I am right assuming that the task "scan for partitions and inform the
> kernel" is delegated to udisks,
Nope, that's not how it works. udisks-daemon does not do the partition
probing and inform the kernel.
then it looks to me as if udisks-daemon
> need to run regardless of whether anything uses the udisks service. It
> is then not just the dbus interface that depends on udisks-daemon, but
> anything using the kernel interfaces.
>
> If my assumption is wrong, then I would appreciate a hint as to where to
> look for this. Maybe udev?
Most likely. As said, the device and partition probing is done by udev
and its helpers. See /lib/udev/rules.d. The results of running those
probers is stored in the udev db.
> My question is really "what service is responsible for calling the
> BLKRRPART ioctl whenever a new disk is detected?"
$ grep blkid /lib/udev/rules.d/*
/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{program}="/sbin/blkid
-o udev -p $tempnode"
/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{program}="/sbin/blkid -o udev -p -u noraid -O
$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"
/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{program}="/sbin/blkid -o udev -p -u noraid $tempnode"
/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
There are also specializied probers for md and lvm devices.
>> Btw, the device probing is done by udev and its helpers and not udisks
>> itself, ie. if you attach a usb device, and then later start
>> udisks-daemon, your statement that those partitions wouldn't be detected
>> is simply not true.
>
> The disk is probed and detected regardless of udisks-daemon, but not
> its partitions.
As said, probing the devices/partitions is done by udev, and
udisks-daemon is more or less a D-Bus interface to the udev database.
>
>> Can you provide further information what kind of problem you are having?
>
> Plugging in my phone (which provides a partitioned hard drive and a CD
> over USB), without running udisks-daemon:
>
> bjorn@nemi:~$ ps aux|grep udisk
> bjorn12482 0.0 0.0 8920 852 pts/6S+ 12:04 0:00 grep udisk
>
>
> nemi:/home/bjorn# udevadm monitor --kernel --udev
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent
>
>
>
> KERNEL[12802.743473] add /devices/pci:00/:00:1d.7/usb2/2-1 (usb)
> KERNEL[12802.744379] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0 (usb)
> KERNEL[12802.746485] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10 (scsi)
> KERNEL[12802.746536] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/scsi_host/host10
> (scsi_host)
> UDEV [12802.756836] add /devices/pci:00/:00:1d.7/usb2/2-1 (usb)
> UDEV [12802.767990] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0 (usb)
> UDEV [12802.768837] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10 (scsi)
> UDEV [12802.769338] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/scsi_host/host10
> (scsi_host)
> KERNEL[12803.749427] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0 (scsi)
> KERNEL[12803.749488] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0
> (scsi)
> KERNEL[12803.749584] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_disk/10:0:0:0
> (scsi_disk)
> KERNEL[12803.749758] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_device/10:0:0:0
> (scsi_device)
> KERNEL[12803.750145] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_generic/sg2
> (scsi_generic)
> UDEV [12803.750196] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0 (scsi)
> KERNEL[12803.750528] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/bsg/10:0:0:0
> (bsg)
> KERNEL[12803.750733] add
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1
> (scsi)
> KERNEL[12803.752976] add /devices/virtual/bdi/8:16 (bdi)
> KERNEL[12803.75388
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
Michael Biebl writes: > I can't see the usability regression. OK. I certainly don't have the full picture here, and this might be a bug in some other part of the puzzle. If you can provide any pointers where to look further, then I'd appreciate that. But the observed fact on my laptop is that this used to work out of the box, and it doesn't anymore after upgrading to wheezy. That's why I labelled it "regression". > If no one is using the udisks service, why should it be started? If I am right assuming that the task "scan for partitions and inform the kernel" is delegated to udisks, then it looks to me as if udisks-daemon need to run regardless of whether anything uses the udisks service. It is then not just the dbus interface that depends on udisks-daemon, but anything using the kernel interfaces. If my assumption is wrong, then I would appreciate a hint as to where to look for this. Maybe udev? My question is really "what service is responsible for calling the BLKRRPART ioctl whenever a new disk is detected?" > Btw, the device probing is done by udev and its helpers and not udisks > itself, ie. if you attach a usb device, and then later start > udisks-daemon, your statement that those partitions wouldn't be detected > is simply not true. The disk is probed and detected regardless of udisks-daemon, but not its partitions. > Can you provide further information what kind of problem you are having? Plugging in my phone (which provides a partitioned hard drive and a CD over USB), without running udisks-daemon: bjorn@nemi:~$ ps aux|grep udisk bjorn12482 0.0 0.0 8920 852 pts/6S+ 12:04 0:00 grep udisk nemi:/home/bjorn# udevadm monitor --kernel --udev monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[12802.743473] add /devices/pci:00/:00:1d.7/usb2/2-1 (usb) KERNEL[12802.744379] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0 (usb) KERNEL[12802.746485] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10 (scsi) KERNEL[12802.746536] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/scsi_host/host10 (scsi_host) UDEV [12802.756836] add /devices/pci:00/:00:1d.7/usb2/2-1 (usb) UDEV [12802.767990] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0 (usb) UDEV [12802.768837] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10 (scsi) UDEV [12802.769338] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/scsi_host/host10 (scsi_host) KERNEL[12803.749427] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0 (scsi) KERNEL[12803.749488] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0 (scsi) KERNEL[12803.749584] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_disk/10:0:0:0 (scsi_disk) KERNEL[12803.749758] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_device/10:0:0:0 (scsi_device) KERNEL[12803.750145] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/scsi_generic/sg2 (scsi_generic) UDEV [12803.750196] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0 (scsi) KERNEL[12803.750528] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/bsg/10:0:0:0 (bsg) KERNEL[12803.750733] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1 (scsi) KERNEL[12803.752976] add /devices/virtual/bdi/8:16 (bdi) KERNEL[12803.753888] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb (block) KERNEL[12803.757430] change /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb (block) KERNEL[12803.759888] add /devices/virtual/bdi/11:1 (bdi) KERNEL[12803.760836] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1/block/sr1 (block) KERNEL[12803.761293] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1/scsi_device/10:0:0:1 (scsi_device) KERNEL[12803.761938] change /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1/block/sr1 (block) KERNEL[12803.762624] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1/scsi_generic/sg3 (scsi_generic) KERNEL[12803.762901] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1/bsg/10:0:0:1 (bsg) UDEV [12803.768524] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:1 (scsi) UDEV [12803.769526] add /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0 (scsi) UDEV [12803.771572] add /devices/virtual/bdi/8:16 (bdi) UDEV [12803.771605] add
Bug#648810: [Pkg-utopia-maintainers] Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
On 15.11.2011 10:34, Bjørn Mork wrote: > However, this does not consider the situation when *nothing* ever calls into > the > org.freedesktop.UDisks service, a condition which is perfectly normal on any > non-desktop (or even non-gnome?) system. On such systems, udisks-daemon will > not > run. And since partition scanning now is left up to udisks-daemon, this > means that > the partitions of e.g. newly attached USB disks are not automatically > detected. > > There are a number of workarounds, like just firing up udisk(1) which will > trigger udisks-daemon to start, or running partprobe(8) manually after > attaching a new disk. But I still want to report this as a bug, since it > represents a usability regression from squeeze. I can't see the usability regression. If no one is using the udisks service, why should it be started? Btw, the device probing is done by udev and its helpers and not udisks itself, ie. if you attach a usb device, and then later start udisks-daemon, your statement that those partitions wouldn't be detected is simply not true. Can you provide further information what kind of problem you are having? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#648810: udisks-daemon: regression from squeeze: partitions on USB disks are not scanned by default
Package: udisks Version: 1.0.4-2 Severity: normal File: udisks-daemon -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 udisks-daemon(8) states udisks-daemon provides the org.freedesktop.UDisks service on the system message bus. Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon(1) whenever an application calls into the org.freedesktop.UDisks service. However, this does not consider the situation when *nothing* ever calls into the org.freedesktop.UDisks service, a condition which is perfectly normal on any non-desktop (or even non-gnome?) system. On such systems, udisks-daemon will not run. And since partition scanning now is left up to udisks-daemon, this means that the partitions of e.g. newly attached USB disks are not automatically detected. There are a number of workarounds, like just firing up udisk(1) which will trigger udisks-daemon to start, or running partprobe(8) manually after attaching a new disk. But I still want to report this as a bug, since it represents a usability regression from squeeze. Thanks, Bjørn - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages udisks depends on: ii dbus 1.4.16-1 ii libatasmart4 0.18-1 ii libc6 2.13-21 ii libdbus-1-31.4.16-1 ii libdbus-glib-1-2 0.98-1 ii libdevmapper1.02.1 2:1.02.67-1 ii libglib2.0-0 2.28.8-1 ii libgudev-1.0-0 172-1 ii liblvm2app2.2 2.02.88-1 ii libparted0debian1 2.3-8 ii libpolkit-gobject-1-0 0.102-1 ii libsgutils2-2 1.32-1 ii libudev0 172-1 ii udev 172-1 Versions of packages udisks recommends: pn dosfstools 3.0.12-1 pn eject2.1.5+deb1+cvs20081104-8 pn hdparm 9.32-1 pn mtools 4.0.12-1 pn ntfs-3g [ntfsprogs] 1:2011.4.12AR.7-1 pn policykit-1 Versions of packages udisks suggests: pn cryptsetup 2:1.3.0-3 pn mdadm pn reiserfsprogs pn xfsprogs - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7CMjgACgkQ10rqkowbIskQwwCfZzc4m4/dHQCEJFyDDjFFofOK TbUAn1kxQF6aIGuodp9cjAbgmHBGg40h =Tf2T -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
