On systems installed where /dev/sd** disks are named /dev/nvme0n1p*, diskdrake starts up showing only nvme0n1p1 and none of the others. I'll attach screenshots of diskdrake and a df showing several other nvme0n1p* disks.
Created attachment 13640 [details] diskdrake screenshot
Created attachment 13641 [details] df screenshot
Created attachment 13642 [details] diskdrake on Mageia 9 Here's a diskdrake snapshot from my laptop. Fully up-to-date cauldron install showing it's working on that system.
CC: (none) => davidwhodgins
This is an up-to-date duplicate of bug#19171. If you start from the diskdrake screenshot I posted, switch to Expert mode, and switch back, the partition tabs are all painted correctly. Note that the key for this appears to be that diskdrake is started as root from a terminal. This is also an up-to-date cauldron system, updated several times a day (I have a boring life). Since this has more information, I'll mark the older one a duplicate.
Summary: diskdrake can't find most nvme0n1p* disks => diskdrake started from root prompt can't find most nvme0n1p* disks
*** Bug 19171 has been marked as a duplicate of this bug. ***
This problem is wider than you (Frank) describe, and not confined to nvme 'discs'; at least not here, I only have (I think) one SSD. Trying this on my own Cauldron system: * Launching diskdrake from a root terminal, no partitions are initially shown for the selected device. * Launching diskdrake from a user terminal, it asks for admin password, the initial display shows no partitions. * Launching diskdrake from a user terminal via sudo, no partitions shown initially. The 3 cases above, assume dismissed the backup popup, clicking 'Advanced' immediately displays partitions. * Going via MCC-Local Discs-Manage Disc Partitions shows them correctly. Assigning to the Mageia tools people. Flagging 'for errata' in case it does not get fixed before release; can be undone.
Source RPM: drakx-tools => drakxtools-18.52-1.mga9.src.rpmAssignee: bugsquad => mageiatoolsCC: (none) => lewyssmithKeywords: (none) => FOR_ERRATA9
I could reproduce and they key is that it only happens on machines with a single disk. We already have some code to workaround a bug in that situation http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/hd_gtk.pm?id=e44a107c6d3465a5f3afc9a5c243be86b341c099 (from bug #18076), but it is not enough to have things displayed properly. Calling $update_all->(1); instead of $notebook_widget->set_current_page(0); after $notebook_widget->remove_page(0); seems to fix the problem here but I am not sure what is going on and this code is a workaround on top of a workaround so it could benefit with understanding it more rather than refreshing one more time. Instead commenting "return if $initializing && $not_first;" also fixes it, to allow updating again while $initializing is true. There has been so many bugs and workarounds here that we should clean it up but that will require testing as standalone and in installer with one or several disks for each. http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/hd_gtk.pm?id=a6bbd53b018cff4c36b31347d72b8b915ffa8583 http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/hd_gtk.pm?id=cd7ce13e2f90bf25cedfcec1a606948b7b9897df http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/hd_gtk.pm?id=e44a107c6d3465a5f3afc9a5c243be86b341c099
Thanks for your instant response. It should not be difficult to test, because from command line, it happens immediately. We have not had any installer complaints that I know of, so something must be different there.
Summary: diskdrake started from root prompt can't find most nvme0n1p* disks => diskdrake started from terminal or console does not initially display partitions if only 1 disc
comment 7 explains why I don't see it even when I run diskdrake after using "su -" in konsole, as I have two nvme drives in my laptop.
Also, please clarify. Are the people seeing this bug using "su" or "su -" to become root?
"su -l" in my case.
In my comment 6, for the first case root GUI terminal I always do just 'su'; consciously preferring to remain in my home directory rather than switch to root's. Seems less dangerous.
CC: lewyssmith => (none)
(In reply to Lewis Smith from comment #12) > In my comment 6, for the first case root GUI terminal I always do just 'su'; > consciously preferring to remain in my home directory rather than switch to > root's. Seems less dangerous. The usual reason for recommending "su -l" is that just "su" can result in the inadvertent creation of files owned by root in a user directory, e. g. /home/xxxx.
(In reply to Lewis Smith from comment #12) > In my comment 6, for the first case root GUI terminal I always do just 'su'; > consciously preferring to remain in my home directory rather than switch to > root's. Seems less dangerous. https://wiki.mageia.org/en/Never_use_just_su Regarding the diskdrake problem, I can recreate it on my rpi4b which only has one drive, /dev/mmcblk0.
Summary: diskdrake started from terminal or console does not initially display partitions if only 1 disc => diskdrake started from terminal or console does not initially display partitions if only 1 disk
I have submitted drakxtools-18.55
CC: (none) => pterjan
Issue solved?
CC: (none) => fri