In recent kernels, dm allows user-space to set the geometry of a device: http://www.redhat.com/archives/dm-devel/2006-February/msg00137.html So, by default, HDIO_GETGEO now returns zero for the geometry paramters rather than returning -ENOTTY This causes a divide-by-zero in linux.c:_device_probe_geometry(): if (!ioctl (arch_specific->fd, HDIO_GETGEO, &geometry)) { dev->hw_geom.sectors = geometry.sectors; dev->hw_geom.heads = geometry.heads; dev->hw_geom.cylinders = dev->length / (dev->hw_geom.heads * dev->hw_geom.sectors) / (dev->sector_size / PED_SECTOR_SIZE); Suggest either checking for zero return on these paramets and falling back to the default values. (Of course, you could probably also argue that dm should continue returning -ENOTTY when the geometry hasn't been set. cc-ing agk) To reproduce: $> dd if=/dev/zero of=/tmp/t.img bs=1M count=0 seek=4096 0+0 records in 0+0 records out 0 bytes (0 B) copied, 7.3e-05 seconds, 0.0 kB/s $> losetup /dev/loop0 /tmp/t.img $> echo "0 8388608 linear /dev/loop0 0" | dmsetup create foo $> parted /dev/mapper/foo mklabel msdos Floating point exception
man 4 sd says: If the geometry information is not available, zero will be returned for all of the parameters.
Just tried the reproducer listed above on rawhide. I don't get the floating point exception. I have parted-1.7.1-15.fc6 in rawhide right now. Can the reporter please try rawhide to verify the problem is gone (or still exists)? Thanks.
Right, it's fixed now: if (!ioctl (arch_specific->fd, HDIO_GETGEO, &geometry) && geometry.sectors && geometry.heads) {