| Summary: | Partitionmanager - libsolid doesn't correctly detect hard disks | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] solid | Reporter: | Mattia <mattia.verga> |
| Component: | general | Assignee: | Lukáš Tinkl <lukas> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | grave | CC: | adaptee, andrius, asturm, chris.dart, entisten, kde.bugs.sp242, kde, kevin.kofler, lukas, njc, rdieter, sqn14, treeve, yesyoucanspamme |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | 4.11 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
partitionmanager window
same disk from gparted systemsettings.desktop backtrace of partition manager crash backtrace of partition manager crash output of solid-hardware list detail with udisks1 output of solid-hardware list detail with udisks2 njc's print screen |
||
|
Description
Mattia
2012-12-09 13:20:48 UTC
Created attachment 75748 [details]
partitionmanager window
Created attachment 75749 [details]
same disk from gparted
Is this still the case with latest SVN? I accidentally introduced integer overflow today (sorry) which is now fixed. Same thing, problem is still there. Can be a problem introduced by parted 3.1? Last time I've compiled for Fedora 17 (parted 3.0) it worked, now in Fedora 18 (parted 3.1) it doesn't... I will try to rebuild locally with parted 3.0 instead of using Fedora buildsystem to see if it changes something. Tried to compile with parted 3.0 under Fedora 18, but the problem persists. Luckily I had an outdated Fedora 17 virtual machine, I tried to compile last SVN of partitionmanager in that and it works... I'm going to do a full update of that machine and see if it give me the problem. Ok, so: last SVN version on Fedora 17 with parted 3.0 - works last SVN version on Fedora 18 with parted 3.1 - doesn't work last SVN version or previous compiled version for Fedora 17 on Fedora 18 with parted 3.0 - doesn't work It's not a parted version related problem. Some other information: the log in partitionmanager shows "Scanning devices - Device found: unknown" and I can see a lot (20 or more) of "partitionmanage" (yes, without the final 'r') zombie processes in top while the application is running. Could it be that Fedora 18 uses udisks2 and Fedora 17 uses udisks1? (In reply to comment #6) > Ok, so: last SVN version on Fedora 17 with parted 3.0 - works > last SVN version on Fedora 18 with parted 3.1 - doesn't work > last SVN version or previous compiled version for Fedora 17 on Fedora 18 > with parted 3.0 - doesn't work > > It's not a parted version related problem. > Some other information: the log in partitionmanager shows "Scanning devices > - Device found: unknown" and I can see a lot (20 or more) of > "partitionmanage" (yes, without the final 'r') zombie processes in top while > the application is running. Created attachment 75769 [details] systemsettings.desktop (In reply to comment #7) > Could it be that Fedora 18 uses udisks2 and Fedora 17 uses udisks1? > (In reply to comment #6) Just checked: yes, Fedora 17 ships udisks1 as default, while Fedora 18 uses udisks2. Is partitionmanager incompatible with udisks2? Should I figure out how to compile it to use udisks1? Partition manager does not use udisks directly. It uses Solid and whatever backend Solid provides. The question is whether kdelibs in Fedora support udisks2. I think that there were some effors to backport udisks2 support from KDE Frameworks 5 to kdelibs 4.x but I'm not sure if Fedora 18 includes them... But that would be really strange because how can they detect removable media in other KDE applications. I haven't yet tried udisks2 myself on Gentoo but kdelibs package has optional udisks2 USE flag... Well, in Fedora 18 I can see that all KDE packages depends on udisks2 (if I try to uninstall it, yum tries to remove also kdelibs package). So KDE is using udisks2. I will ask on Fedora development mailing list how I can bypass this problem, but I don't think they will rebuild all KDE stuff without udisks2 flag... I've compiled udisks2 and recompiled kdelibs to use it but for now I can't get partitionmanager to work with it at all. It simply crashes but according to backtrace the crash is in Solid. I suspect that this is not a bug in partitionmanager... Hopefully, future versions of kdelibs and Solid would work better with udisks2. Can you post backtraces for the crashes you encounter? I'll poke some solid/udisk guru (ltinkl for starters) to look into it. Created attachment 75782 [details]
backtrace of partition manager crash
I'm attaching the requested backtrace.
Can you please install all the needed debugging symbols to get a more meaningful BT? Interestingly, installing and running kde-partitionmanager-1.0.3-8.201202025svn.fc18 works fine on my fedora 18 box (no crash, detects my disks/partitions correctly). though, for various reasons selinux is off/disabled, could you try running in selinux permissive mode and see if that changes anything? I've recompiled Qt, glib and glibc on Gentoo and it still shows the same backtrace. I'm not sure why backtrace is not complete... sorry, I think I know why backtraces are incomplete. I'll upload a new one once I recompile Qt/kdelibs... Created attachment 75785 [details]
backtrace of partition manager crash
Debugging information for libsolid is still missing. This is really strange. I am sure that kdelibs, libsolid and solid-runtime were all compiled with debug symbols (and these symbols were not stripped). Something is really weird. (In reply to comment #19) > Debugging information for libsolid is still missing. (In reply to comment #15) > Interestingly, installing and running > kde-partitionmanager-1.0.3-8.201202025svn.fc18 works fine on my fedora 18 > box (no crash, detects my disks/partitions correctly). > > though, for various reasons selinux is off/disabled, could you try running > in selinux permissive mode and see if that changes anything? I tried on my main PC and in a virtual machine with both selinux on and off, but the result is still the same. I also installed today kdelibs updates and checked, no change. Can you please try the latest svn version? It's available in koji, but I didn't pushed it into updates-testing... http://koji.fedoraproject.org/koji/buildinfo?buildID=371979 I also had some random crash at startup, but now I'm not able to reproduce that... if I get the crash I will install debugging symbols to create a backtrace. That build is ok for me too. Full disclosure, forgot to mention this box of mine is running kde-4.9.90 Mattia, mind testing against kde-4.9.4 (if you hadn't already), it included some good solid/udisks2 fixes, https://admin.fedoraproject.org/updates/FEDORA-2012-20061 (In reply to comment #22) > That build is ok for me too. Full disclosure, forgot to mention this box of > mine is running kde-4.9.90 > > Mattia, mind testing against kde-4.9.4 (if you hadn't already), it included > some good solid/udisks2 fixes, > https://admin.fedoraproject.org/updates/FEDORA-2012-20061 Yes, I've installed kde-4.9.4 with today updates, but I get the same problem. I've cloned my Fedore 18 virtual machine, enabled rawhide repository and installed kdelibs 4.9.90 (and related dependencies): this way I confirm partitionmanager is working. OK, I've updated to KDE 4.9.4 and it seems that Solid related crashes are fixed. I think that we are seeing 2 different problems in this bug. It seems that one of them is fixed by 4.94. So what to make of this? This looks like it has the potential to take hours to even try and _reproduce_ it, not having KDE 4.9.90 or udisks2 running yet. Is there anything I need to do or even _can_ do? Or do we close this? Or reassign to solid? (In reply to comment #25) > So what to make of this? This looks like it has the potential to take hours > to even try and _reproduce_ it, not having KDE 4.9.90 or udisks2 running yet. > > Is there anything I need to do or even _can_ do? Or do we close this? Or > reassign to solid? Since partitionmanager works fine with kde 4.9.90 and udisks2 I think there's something wrong on how solid/kdelibs 4.9.4 interfaces with udisks2. So I think it should be reassigned to kdelibs? Let me amend that, fedora builds prior to kdelibs-4.9.90-3 were inadvertently using the udisks(1) backend, not udisks2. I've confirmed that udisks2 backend with kdelibs-4.9.90-3 behaves badly too. Ideally, if we could find a minimal test-case, based on the solid calls made in partitionmanager to highlight the problem(s), that would help identify what's going wrong. I'm not a programmer, but I did some tests... I attach two files made in my Virtual Machine, showing the output of 'solid-hardware list details' (only related to block_devices and drives). As you can see with udisks1 the udi = '/org/freedesktop/UDisks/devices/sda' is listed with a property of Block.device = '/dev/sda' (string) Instead in udisks2 the udi = '/org/freedesktop/UDisks2/drives/VBOX_HARDDISK_VB3ace5ba5_0dc3560f' is listed with a property of Block.device = '/dev/sda3' (string) I think that's the error, in fact partitionmanager shows '/dev/sda3' as to be the hard disk instead of '/dev/sda'. I checked also on my main PC, as you can look from the previous screenshot partitionmanager shows the disk as '/dev/sda5' and the output of solid-hardware shows "Block.device = '/dev/sda5' (string)" Created attachment 75849 [details]
output of solid-hardware list detail with udisks1
Created attachment 75850 [details]
output of solid-hardware list detail with udisks2
thanks, confirmed and reassigning to solid (for now) Can the problem be in the conditional of the IF at line 56 of solid / solid / backends / udisks2 / udisksblock.cpp ? I think it should say something like "IF the device is type: partition table than get the path". The actual conditional is always true and it gets the first partition it parses (wich is the last on the disk). (but, again, my knowledge of C is very poor and mine is only a guess) ping? Tested with kdelibs 4.9.98, same problem This bug happens to me as well. Fedora 18 w/ kde-unstable + kde-testing + kde (KDE 4.10) kde-partitionmanager-1.0.3-8.20120205svn.fc18.x86_64 It detects only one partition per device. I have no unencrypted swap partitions: it detects one random partition. On my setup, it detects /dev/sda4 rather than /dev/sda /dev/sdb11 rather than /dev/sdb. sda has a GPT partition table. /dev/sda4 happens to be a 14GiB ext4 partition. /dev/sda4 is seen as if it were a block device (as if it were /dev/sda): /dev/sda41 (!) is the "perceived" 14GiB partition. partitionmanager cannot recognize that it is in ext4 anyway. sdb has a msdos partition table. /dev/sdb11 is a plain dm-crypt partition. "No valid partition table found". Lukáš, can you please say us something on this? Can't reproduce, doesn't crash on KDE 4.10 Crashing isn't the problem (anymore, as far as I'm aware). The problem now is that apparently, partitionmanager doesn't grok the output from udisks2 backend. see the attachments here "output of solid-hardware list detail with udisks1" vs "output of solid-hardware list detail with udisks2" as an example of the difference(s). I guessing partitionmanager may make some invalid assumptions on the type or format of the data returned, but hard to say without looking at the code. (In reply to comment #37) > Can't reproduce, doesn't crash on KDE 4.10 My original problem wasn't a crash, it was that Partitionmanager detects the entire hard disk with the name of a partition on that disk (in my case instead of /dev/sda it detected /dev/sda5). Looking at the output of solid with 'solid-hardware list details' I found that seems a problem of libsolid-udisks2 that gets an udi related to a partition associated to what should be the entire hard disk. See comment #28 Created attachment 78315 [details]
njc's print screen
it's my print screen
Comment on attachment 78315 [details]
njc's print screen
It's my disks configuration:
[root@njc-n73sv ~]# fdisk -l
Disk /dev/sda: 750.2 GB, 750156374016 bytes, 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xf3c6f6a7
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 2048 52430847 26214400 1c Скрытый W95 FAT32 (LBA)
/dev/sda2 * 52430848 693467135 320518144 7 HPFS/NTFS/exFAT
/dev/sda3 693467136 1465147391 385840128 f W95 расшир. (LBA)
/dev/sda5 693469184 1465147391 385839104 7 HPFS/NTFS/exFAT
Disk /dev/sdb: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x366ec4cf
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 * 2048 1026047 512000 83 Linux
/dev/sdb2 1026048 103426047 51200000 83 Linux
/dev/sdb3 103426048 205826047 51200000 83 Linux
/dev/sdb4 205826048 976773119 385473536 5 Расширенный
/dev/sdb5 205830144 218118143 6144000 82 Linux своп / Solaris
/dev/sdb6 218130633 527719184 154794276 83 Linux
Partition 6 does not start on physical sector boundary.
/dev/sdb7 527722496 528746495 512000 83 Linux
/dev/sdb8 528748544 633606143 52428800 83 Linux
/dev/sdb9 633608192 645666815 6029312 82 Linux своп / Solaris
[root@njc-n73sv ~]#
Comment on attachment 78315 [details]
njc's print screen
[njc@njc-n73sv ~]$ uname -a
Linux njc-n73sv.localdomain 3.8.3-203.fc18.x86_64 #1 SMP Mon Mar 18 12:59:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[njc@njc-n73sv ~]$
and
KDE 4.10.1
KDE 4.10.2 libsolid still doesn't detect partitions in a correct way using udisks2. *** Bug 318608 has been marked as a duplicate of this bug. *** Running gentoo with solid 4.10.1. Downgrading udisks to 1.0.4-r5 don't solve the problem. The problem seems to be with libsolid. Can't test 4.9 with udisks2 because I remove backup of 4.9 install Sorry my test was wrong because I forget to unmerve udisks2. Make more test *** Bug 316005 has been marked as a duplicate of this bug. *** SVN commit 1358151 by stikonas: Add an initial support for UDisks2 solid backend. Currently, UDisks2 support can only be enabled at compile time. M +5 -0 CMakeLists.txt M +5 -1 src/plugins/libparted/libpartedbackend.cpp M +5 -0 src/util/helpers.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1358151 Excellent, builds fine, now partitionmanager lists both SSD and HDD correctly on my system. I confirm now partitionmanager works with udisks2 backend, thank you Andrius. Good work! I've noticed that partitionmanager fails to see the device if it contains no partition table. E.g. you first zero the device or fill it with the random data. I'll see if this can be fixed but it still works much better then before if you use udisks2, so it should be good as a temporary solution. I don't think that's the right approach to fix this. Having #ifdefs based on the Solid backend defeats the whole purpose of having the Solid abstraction in the first place! IMHO, this really needs to be fixed on the Solid end. (In reply to comment #53) > I don't think that's the right approach to fix this. Having #ifdefs based on > the Solid backend defeats the whole purpose of having the Solid abstraction > in the first place! IMHO, this really needs to be fixed on the Solid end. I agree but this bug was too serious and we need at least temporary solution. Of course this is somewhat ugly and it does not work 100% perfectly (partitionmanager doesn't see device if it doesn't contain partition table) but at least people are able to use it now. So, shouldn't this bug remain open and assigned to solid? Or someone that have identified the problem in solid code should open a new bug? Partition manager does not understand raid disks. Shows both parts of the raid group separatly but does not show the raid group as a unit. I suspect installer is using 'PartitionManager' and as a result unable to load kde as dual boot with win 7. Win 7 with Mint 15 and Mate 1.6 is no problem but KDE will not work. Installer is instructed to load grub to 'disk5' but always crashes when trying to load it to 'sda' - it was not told to load to sda !!!! Devices show as sda; sdb; sdc etc in PartitionManager but as disk1; disk2; disk3 etc in installer. I am totaly confused. *** Bug 332151 has been marked as a duplicate of this bug. *** I guess we can close this bug for now. Partitionmanager is not affected at all now and there is no obvious way to fix this. |