After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 357384 - Only First Hard Drive Accessible
Only First Hard Drive Accessible
Status: RESOLVED NOTABUG
Product: gparted
Classification: Other
Component: application
0.2.5
Other Linux
: Normal minor
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2006-09-23 22:15 UTC by Jeff Greene
Modified: 2006-10-03 14:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Jeff Greene 2006-09-23 22:15:22 UTC
GParted is supposed to list all of my hard drives in the top right corner, but only the first one is shown. The other hard drives have partitions mounted and are viewable from other applications. I am running Ubuntu Edgy Knot 3.
Comment 1 Plors (Bart H) 2006-09-24 06:23:22 UTC
Hi Jeff,
Before reporting bugs you should always try with the latest gparted (0.3.1). You can also download our latest livecd (~30MiB) from http://gparted.sourceforge.net/livecd.php

Please report back with the results, thnx.

(PS. as a workaround you can start gparted from commandline with a device as argument. e.g. gparted /dev/hda )
Comment 2 Plors (Bart H) 2006-09-27 10:33:31 UTC
hi, had a chance to test this already?
Comment 3 Jeff Greene 2006-09-27 13:38:13 UTC
I did not use the livecd, but I did compile the latest version from source and it still did not detect both hard drives. Your workaround did fix the problem though.
Comment 4 Plors (Bart H) 2006-09-27 13:47:17 UTC
ok, please give me some more information about these disks? also i'd like to see the output of 'fdisk -lu' and if possible you should try the latest livecd.

thnx
Comment 5 Jeff Greene 2006-09-27 13:56:49 UTC
SATA1 is a Seagate 320GB HD
SATA2 is a Western Digital 250GB HD

cat /proc/scsi/scsi:
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ST3320620AS      Rev: 3.AA
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD2500KS-00M Rev: 02.0
  Type:   Direct-Access                    ANSI SCSI revision: 05


fdisk -lu:
Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    83891429    41945683+  83  Linux
/dev/sda2        83891430   623032829   269570700   83  Linux
/dev/sda3       623032830   625137344     1052257+  82  Linux swap / Solaris

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63   488392064   244196001   83  Linux
Comment 6 Jeff Greene 2006-09-27 14:10:26 UTC
Could my /etc/fstab file be the problem?

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=562ce90c-41c0-4b70-b723-583bf5af6433 /               ext3    defaults,errors=remount-ro 0       1
# /dev/sdb1
UUID=4c8367ab-6500-4714-8b5c-0916008f618d /media/Backup   ext3    defaults        0       2
# /dev/sda2
UUID=5728de75-f4c5-4722-9c94-32ce5082eaa6 /media/Data     ext3    defaults        0       2
# /dev/sda3
UUID=11ed7d99-f8b3-4a5f-a650-ee2453c76c8e none            swap    sw              0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/hdd        /media/cdrom1   udf,iso9660 user,noauto     0       0
Comment 7 Jeff Greene 2006-09-27 15:13:42 UTC
I tried it with the livecd and the hard drives were both detected from the start. It must be some new configuration with Edgy. I am thinking it has to do with the UUIDs in the /etc/fstab file. I did not see those there in Dapper.
Comment 8 Plors (Bart H) 2006-09-27 15:28:56 UTC
ok, in that case the fault is with Edgy somewhere. /etc/fstab is not used for detection, so it has nothing to do with this.

It's only a bit suprising that fstab -lu detects your sdb correctly and gparted doesn't. 
Comment 9 Plors (Bart H) 2006-09-27 15:29:40 UTC
oh btw, i'm catching a flight tonight so from now on i can't respond anymore, see you in a couple of days :)
Comment 10 Colin Watson 2006-10-03 12:48:33 UTC
This is because I pulled in a broken patch from upstream CVS, actually. :-) You've since reverted that patch - it was the one to work around libparted's probing of floppy/CD devices - but since the patch to fix libparted wasn't available at that point I decided to use it.

For what it's worth, the bug was that minor is not always 0 for partitions; for instance, /dev/hdb has minor number 64, and /dev/sdb has minor number 16. I made the code look like this instead (requiring #include <sys/types.h> and #include <regex.h>); this mirrors similar code in libparted.

                //try to find all available devices
                std::ifstream proc_partitions( "/proc/partitions" ) ;
                if ( proc_partitions )
                {
                        std::string line ;
                        bool skip = false ;
                        regex_t non_partition ;
                        // allow e.g. hda or rd/c0d0, but not hda1 or rd/c0d0p1
                        if ( regcomp( &non_partition, "^(.*/)?(.*[^0-9/]|[^0-9/]+[0-9]+[^0-9/]+[0-9]+)$", REG_EXTENDED | REG_NOSUB | REG_NEWLINE ) )
                                skip = true ;
                        while ( !skip && getline( proc_partitions, line ) )
                        {
                                char device[512] ;
                                if ( sscanf( line .c_str(), "%*d %*d %*d %s", device ) == 1 &&
                                     strncmp( device, "dm-", 3 ) != 0 &&
                                     strncmp( device, "loop", 4 ) != 0 &&
                                     strncmp( device, "ram", 3 ) != 0 &&
                                     !regexec( &non_partition, device, 0, 0, 0 ) )
                                        device_paths .push_back( "/dev/" + Glib::ustring( device ) ) ;
                        }
                        regfree( &non_partition );

                        proc_partitions .close() ;
                }
Comment 11 Colin Watson 2006-10-03 12:49:47 UTC
(I think you can safely reject this bug. https://launchpad.net/distros/ubuntu/+source/gparted/+bug/60868 tracks the issue in Ubuntu.)
Comment 12 Plors (Bart H) 2006-10-03 13:28:16 UTC
that explains a lot :)
i reverted the patch after realizing the minor doesn't have to be 0 and after hearing issues with probing will be resolved in libparted-1.8.

I think it's also save to simply scan for the line with the lowest minor. This results in less code.

ah well, thanks for clearing this up, i didn't realize how 'edgy' Edgy is :P
Comment 13 Colin Watson 2006-10-03 13:41:57 UTC
Scanning for the lowest minor doesn't work. For example:

major minor  #blocks  name

   8     0    8388608 sda
   8     1    8008371 sda1
   8     2          1 sda2
   8     5     377496 sda5
   8    16    8388608 sdb
   7     0     610644 loop0

You need to know about the different minor allocation strategies for different major numbers in order to try scanning for the lowest minor, which would be very fragile.
Comment 14 Plors (Bart H) 2006-10-03 13:52:32 UTC
never seen a /proc/partitions like this before (i thought each device is supposed to have its own unique major?), but yes, in this case you are right and this wouldn't work.
Comment 15 Jeff Greene 2006-10-03 13:58:01 UTC
I am not sure exactly what you are talking about, but here is my /proc/partitions file:
major minor  #blocks  name

   8     0  312571224 sda
   8     1   41945683 sda1
   8     2  269570700 sda2
   8     3    1052257 sda3
   8    16  244198584 sdb
   8    17  244196001 sdb1
Comment 16 Colin Watson 2006-10-03 14:41:31 UTC
plors: No, every device certainly does not have its own unique major number; it's closer to every type of device (although even that's not quite accurate). See Documentation/devices.txt in the Linux kernel source for details.