Your message dated Wed, 17 Nov 2010 15:13:51 +0000 with message-id <[email protected]> has caused the report #602533, regarding parted sees useless /dev/cciss/ device to be marked as having been forwarded to the upstream software author(s) [email protected]
(NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 602533: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602533 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---On Fri, Nov 05, 2010 at 05:37:23PM +0000, Ian Jackson wrote: > Package: parted > Version: 1.8.8.git.2008.03.24-11.1 > > I'm running this version of parted running on an HP DL165 with > linux-image-2.6.26-2-686-bigmem 2.6.26-25lenny1. I have nothing > connected to the CCISS controller; the disks are connected only to the > ordinary SATA controller. > > However, there is still a device node /dev/cciss/c0d0, without a > corresponding entry in /proc/partitions. parted sees this and > complains about it. > > Notably: parted -l prints: > > Error: /dev/cciss/c0d0: unrecognised disk label > > Another consequence of this behaviour is that d-i prints this warning, > interrupting automatic installations: > > Unable to determine geometry of file/device /dev/cciss/c0d0. You should > not use Parted unless you REALLY know what you're doing! > Warning! > 1. Ignore [*] > 2. Cancel > Prompt: '?' for help, default=1> > > The device can be opened but looks empty: > > woodlouse:~# dd if=/dev/cciss/c0d0 of=t > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 0.000570254 s, 0.0 kB/s > woodlouse:~# > > It would be nice if parted could be taught to ignore this spurious > device. Perhaps it should ignore all zero-length devices ? I agree; there seems no point in complaining about this. The problem with throwing an exception is that it's difficult for partitioners such as partman to programmatically distinguish between this kind of thing and some more serious error that actually merits letting the user know. Ian asked me on IRC why libparted didn't use /proc/partitions, which doesn't list this device. (It does, but only if /sys/block/ is not present.) I looked into the differences between /proc/partitions and /sys/block/, and they are as follows: * /proc/partitions omits zero-length devices. * /proc/partitions omits non-partitionable removable devices. * /proc/partitions omits RAM block devices. * /proc/partitions is in a human-readable format, while /sys/block/ is machine-readable. To a first approximation nobody cares about RAM block devices, and libparted definitely should expose non-partitionable removable devices because it's sometimes useful to be able to manipulate those from a partitioning program which uses libparted for device discovery (e.g. you might want to create a filesystem on the whole disk). However, the policy of /proc/partitions seems closer to what we want in the case of zero-length devices, and therefore I suggest that we silently ignore these. I'll follow up to this mail with a patch. Thanks, -- Colin Watson [[email protected]]
--- End Message ---
