Diskdrake crashes with the following error. This is on a clean Cauldron install on 2012-01-14. I didn't have a problem with diskdrake when I was on mga1. I'll attach the messages from /var/log/messages ]# diskdrake cannot get info for device (17:0:0:0) at /usr/lib/libDrakX/detect_devices.pm line 222. Backtrace has 15 calls on stack: 15: /usr/lib64/libparted.so.1(ped_assert+0x31) [0x7ff2202d22b1] 14: /usr/lib64/libparted.so.1(ped_geometry_read+0x80) [0x7ff2202d8bf0] 13: /usr/lib64/libparted.so.1(ped_geometry_read_alloc+0x54) [0x7ff2202d8c84] 12: /usr/lib64/libparted.so.1(nilfs2_probe+0x8d) [0x7ff2202e233d] 11: /usr/lib64/libparted.so.1(ped_file_system_probe_specific+0x6e) [0x7ff2202d377e] 10: /usr/lib64/libparted.so.1(ped_file_system_probe+0x7c) [0x7ff2202d386c] 9: /usr/lib64/libparted.so.1(+0x28a26) [0x7ff2202eda26] 8: /usr/lib64/libparted.so.1(ped_disk_new+0x75) [0x7ff2202d78a5] 7: /usr/lib/libDrakX/auto/c/stuff/stuff.so(XS_c__stuff_get_disk_type+0x132) [0x7ff22072329e] 6: /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x690) [0x7ff221d91690] 5: /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so(Perl_runops_standard+0x16) [0x7ff221d887f6] 4: /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so(perl_run+0x266) [0x7ff221d280c6] 3: /usr/bin/perl(main+0x154) [0x400f34] 2: /lib64/libc.so.6(__libc_start_main+0xed) [0x7ff220c6532d] 1: /usr/bin/perl() [0x400cb9] Aborted
Created attachment 1366 [details] diskdrake messages from /var/log/messages
Parted is quite fussy when it comes to partition tables being correct. Can attach the output from "sfdisk -l -uS /dev/sd?".
CC: (none) => davidwhodgins
Created attachment 1368 [details] sfdisk and hdparm output
Created attachment 1369 [details] lspcidrake -v output Not sure if this is helpful, but the 17:0:0:0 device is the Marvel controller on my system. ]# pwd /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host17/target17:0:0/17:0:0:0 [root@localhost 17:0:0:0]# cat vendor Marvell [root@localhost 17:0:0:0]# cat model 91xx Config [root@localhost 17:0:0:0]# lspcidrake -v |grep Mar ahci : Marvell Technology Group Ltd.|Device 91a3 [STORAGE_IDE] (vendor:1b4b device:91a3 subv:1458 subd:b000) (rev: 11)
Disk /dev/sde: 38913 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sde1 * 2048 625139711 625137664 83 Linux 38913 x 512 x 63 = 625137345 According the the partition table, the partition is bigger than the drive. libparted will not work with that. You'll have to fix the partition table. Probably best to copy all of the data elsewhere, delete/recreate the partition, then restore the data.
Sorry, copy/paste error. but correct result 38913*255*63=625137345
OK. Thanks for the help! So I wonder how that happened. Before this install I had MGA1 running and used diskdrake all the time without a problem. Also, the drive would have been partitioned with diskdrake under Mandriva (I can't say exactly when). IMHO, it would be nicer if diskdrake gracefully failed or ignored that drive with an error message. I see the geometry call in the backtrace, but the window simply wouldn't show up for a GUI user.
(In reply to comment #7) > OK. Thanks for the help! So I wonder how that happened. Before this install The most common way I've seen this happen, is using dd, or ghost, or similar, to copy a partition from one drive to another. Consider the case where both drives are exactly the same size. Older partitioning software would start the first partition on sector 63. Newer partitioning software will start the first partition on sector 2048. Using dd, ghost, or any of the other sector level copying software to copy the partition will result in a partition that has it's end past the end of the drive. As this was the partition table in the mbr that was wrong, the most likely cause, was copying an older similar (but slightly larger) drive to this one, using dd, or similar software. > IMHO, it would be nicer if diskdrake gracefully failed or ignored that drive > with an error message. I see the geometry call in the backtrace, but the > window simply wouldn't show up for a GUI user. Agreed. There are already other bug reports about this. The upstream developers response is "fix the partition table". I don't feel like searching right now, but there is at least one existing bug report effectively saying diskdrake should handle this better.
Just some more info. My understanding is that diskdrake changed to using libparted, in order to handle "advanced format drives", where the partitions must be aligned on 4k boundaries, and ssd drives must be aligned on the write erase block size. Using libparted, partitions (by default) are aligned on 1MB boundaries. Older versions of diskdrake would ignore the partition size greater than the disk size. Current versions wont because of the change to using libparted.
Thanks for the work :) Added maintainer of drakxtools and diskdrake IIRC we have a *lot* a bug report related to this one (but hard to search :s)
CC: (none) => thierry.vignaudAssignee: bugsquad => pterjan
diskdrake have been using libparted since Mandriva 2009.1 or 2010.0, I don't remember, but is supposed to use its own code when libparted rejects the drive (for example due to invalid partitions). In this case, there is another problem in libparted leading to a crash. Also, cannot get info for device (17:0:0:0) is unrelated.
This may be the problem http://lists.alioth.debian.org/pipermail/parted-devel/2011-September/003914.html
Blocks: (none) => 4159
Summary: diskdrake crashes with "cannot get info for device (17:0:0:0)" => libparted crashes probing nilfs2
Source RPM: drakxtools-13.74-1.mga2.src.rpm => parted
Now I'm getting this on a kernel upgrade as well. 85/189: kernel-desktop-3.2.1-1.mga2 ############################################################################# Backtrace has 15 calls on stack: 15: /usr/lib64/libparted.so.1(ped_assert+0x31) [0x7fd2cc61d2b1] 14: /usr/lib64/libparted.so.1(ped_geometry_read+0x80) [0x7fd2cc623bf0] 13: /usr/lib64/libparted.so.1(ped_geometry_read_alloc+0x54) [0x7fd2cc623c84] 12: /usr/lib64/libparted.so.1(nilfs2_probe+0x8d) [0x7fd2cc62d33d] [snip] /sbin/installkernel: line 125: 16266 Aborted bootloader-config --kernel-version $version --initrd-options "$INITRDOPTS" $options 86/189: virtualbox-kernel-3.2.1-desktop-1.mga2
Priority: Normal => release_blockerSeverity: normal => major
Upstream fix for this crash http://anonscm.debian.org/gitweb/?p=parted/parted.git;a=blobdiff_plain;f=libparted/fs/nilfs2/nilfs2.c;h=166c54c0108dcb22ec1c2e4f21cd92dce8a9fa88;hp=511b1550f7fb8cebd6e301fb7a07542a3143609e;hb=2147402b83b27a35011cad032d0519c4a0672280;hpb=99f9c6a99b5d702a2c42cbce0fb74d09d88b2b0d
(In reply to comment #5) > Disk /dev/sde: 38913 cylinders, 255 heads, 63 sectors/track While you're right that the sde partition table was wrong, this wasn't the drive that was causing the problem. I reformatted both sdc and sde and I'm still getting the error. It comes from my sdf drive. When I run the parted command all my drives work except: ]# parted /dev/sdf GNU Parted 3.0 Using /dev/sdf Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Backtrace has 13 calls on stack: 13: /usr/lib64/libparted.so.1(ped_assert+0x31) [0x7f5bcd4f52b1] 12: /usr/lib64/libparted.so.1(ped_geometry_read+0x80) [0x7f5bcd4fbbf0] 11: /usr/lib64/libparted.so.1(ped_geometry_read_alloc+0x54) [0x7f5bcd4fbc84] 10: /usr/lib64/libparted.so.1(nilfs2_probe+0x8d) [0x7f5bcd50533d] [snip] ]# sfdisk -l -uS /dev/sdf Disk /dev/sdf: 121601 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdf1 * 63 1953520064 1953520002 83 Linux /dev/sdf2 0 - 0 0 Empty /dev/sdf3 0 - 0 0 Empty /dev/sdf4 0 - 0 0 Empty
Just pushed parted-3.0-2.mga2 with that patch
Thanks Thierry! Fixed all my issues.
Status: NEW => RESOLVEDResolution: (none) => FIXED