GNOME Bugzilla – Bug 632345
GParted does not handle properly more than 15 partitions on a disk
Last modified: 2012-04-09 20:13:27 UTC
I have two PATA hard drives. The first (master) has Windows, the second (slave) has several Linux partitions. GParted worked well on the second hard drive up to and including sdb16, which is the 15th real partition (as sdb4 is the extended partition that does not have useful data). There seem to be two related bugs handling more than 15 partitions: - Usually (but not always) GParted cannot create the file system after creating the partition. - Usually (but not always) GParted cannot display correctly the partition. As far as I can tell the issue is not when GParted calls parted/libparted, but rather when when GParted calls programs in e2fsprogs (for example to create a file system or check it). For example, at the moment I have sdb17 and sdb18. sdb18 has no file system (because previously GParted failed creating it). So GParted correctly displays it with a warning triangle besides it. However there is nothing wrong with sdb17 as can be seen here: --- [root@dell-d3000 ~]# fsck -f /dev/sdb17 fsck from util-linux-ng 2.17.2 e2fsck 1.41.10 (10-Feb-2009) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information f14-kde-test-2: 81652/524288 files (0.2% non-contiguous), 579542/2096474 blocks --- Yet GParted displays it with a warning triangle and key icons besides it and when I right-click for Information it says: "Unable to find mount point. Unable to read the contents of the file system! Because of this some operations may be unavailable" . This issue applies both to GParted 0.62 and 0.64. Below is my parted listing: ----- (parted) print Model: ATA WDC WD5000AAKB-0 (scsi) Disk /dev/sdb: 976773168s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 63s 6297479s 6297417s primary linux-swap(v1) 2 6297480s 23069339s 16771860s primary ext4 boot 3 23069340s 41929649s 18860310s primary ext4 4 41929774s 976768064s 934838291s extended 11 41929776s 125821079s 83891304s logical ext4 5 125837271s 209712509s 83875239s logical ext4 12 209712573s 335549654s 125837082s logical ext4 6 438301458s 492826004s 54524547s logical ext2 7 566227053s 671083244s 104856192s logical ext4 18 800615403s 817387199s 16771797s logical 17 817387263s 834159059s 16771797s logical ext4 16 834159123s 850930919s 16771797s logical ext4 8 850930983s 871895744s 20964762s logical ext4 15 871895808s 892908764s 21012957s logical ext4 14 892908828s 909680624s 16771797s logical ext3 13 909680688s 926452484s 16771797s logical ext3 9 926452548s 943224344s 16771797s logical ext4 10 943224408s 976768064s 33543657s logical ext4 (parted)
Created attachment 191927 [details] GParted log file with failure to format non-existent device /dev/sda17 Thank you Picsium for reporting this problem. I can confirm the problem exists with the GParted 0.8.1, (lib)parted 2.4, and Ubuntu 11.04. As you mentioned, (lib)parted appears to be able to create the partition. In my situation the device /dev/sda17 does not appear to be have been created. I confirmed that the command "ls -l /dev/sda17" did not exist. Devices larger than sda15 require a new major and minor number combination so perhaps there is a problem with the kernel? Following is the output of "ls -l /dev/sda*" which demonstrates the change in major number for devices >= sda16: $ ls -l /dev/sda* brw-rw---- 1 root disk 8, 0 2011-07-13 16:29 /dev/sda brw-rw---- 1 root disk 8, 1 2011-07-13 16:29 /dev/sda1 brw-rw---- 1 root disk 8, 10 2011-07-13 16:29 /dev/sda10 brw-rw---- 1 root disk 8, 11 2011-07-13 16:29 /dev/sda11 brw-rw---- 1 root disk 8, 12 2011-07-13 16:29 /dev/sda12 brw-rw---- 1 root disk 8, 13 2011-07-13 16:29 /dev/sda13 brw-rw---- 1 root disk 8, 14 2011-07-13 16:29 /dev/sda14 brw-rw---- 1 root disk 8, 15 2011-07-13 16:29 /dev/sda15 brw-rw---- 1 root disk 259, 0 2011-07-13 16:29 /dev/sda16 brw-rw---- 1 root disk 8, 2 2011-07-13 16:29 /dev/sda2 brw-rw---- 1 root disk 8, 3 2011-07-13 16:29 /dev/sda3 brw-rw---- 1 root disk 8, 4 2011-07-13 16:29 /dev/sda4 brw-rw---- 1 root disk 8, 5 2011-07-13 16:29 /dev/sda5 brw-rw---- 1 root disk 8, 6 2011-07-13 16:29 /dev/sda6 brw-rw---- 1 root disk 8, 7 2011-07-13 16:29 /dev/sda7 brw-rw---- 1 root disk 8, 8 2011-07-13 16:29 /dev/sda8 brw-rw---- 1 root disk 8, 9 2011-07-13 16:29 /dev/sda9 $
Marking bug as confirmed.
This problem has been re-confirmed with GParted Live 0.9.1-1.
This is a bug in libparted that has been fixed. I have a pending upload to backport the fix to the old version of libparted that Ubuntu ships with that should hopefully make it into Ubuntu 12.04. Since this isn't a bug in gparted, this report should probably be closed.
The relevant link to track this > 15 partions and the loop device improvement in Ubuntu is as follows: https://code.launchpad.net/~psusi/ubuntu/precise/parted/fixloop
Using Ubuntu 11.10 (Linux-3.0.0), the recently released parted-3.1, and the current git version of GParted (commit 0fda1d011d79c2e0e4d884e03947f2e4e8cec986), I have successfully created 30+ partitions on a GPT partition table. All partitions received a corresponding /dev/sdb# device entry and were able to be formatted. :-)
This definitely looks like it was a bug in parted that is now fixed. Using Ubuntu 11.04 (Linux-2.6.38), parted-3.1, and the current git version of GParted, I successfully created and formatted 20 partitions. $ ls -l /dev/sde* brw-rw---- 1 root disk 8, 64 2012-03-03 17:18 /dev/sde brw-rw---- 1 root disk 8, 65 2012-03-03 17:18 /dev/sde1 brw-rw---- 1 root disk 8, 74 2012-03-03 17:18 /dev/sde10 brw-rw---- 1 root disk 8, 75 2012-03-03 17:18 /dev/sde11 brw-rw---- 1 root disk 8, 76 2012-03-03 17:18 /dev/sde12 brw-rw---- 1 root disk 8, 77 2012-03-03 17:18 /dev/sde13 brw-rw---- 1 root disk 8, 78 2012-03-03 17:18 /dev/sde14 brw-rw---- 1 root disk 8, 79 2012-03-03 17:18 /dev/sde15 brw-rw---- 1 root disk 259, 0 2012-03-03 17:18 /dev/sde16 brw-rw---- 1 root disk 259, 1 2012-03-03 17:18 /dev/sde17 brw-rw---- 1 root disk 259, 2 2012-03-03 17:18 /dev/sde18 brw-rw---- 1 root disk 259, 3 2012-03-03 17:18 /dev/sde19 brw-rw---- 1 root disk 8, 66 2012-03-03 17:18 /dev/sde2 brw-rw---- 1 root disk 259, 4 2012-03-03 17:18 /dev/sde20 brw-rw---- 1 root disk 8, 67 2012-03-03 17:18 /dev/sde3 brw-rw---- 1 root disk 8, 68 2012-03-03 17:18 /dev/sde4 brw-rw---- 1 root disk 8, 69 2012-03-03 17:18 /dev/sde5 brw-rw---- 1 root disk 8, 70 2012-03-03 17:18 /dev/sde6 brw-rw---- 1 root disk 8, 71 2012-03-03 17:18 /dev/sde7 brw-rw---- 1 root disk 8, 72 2012-03-03 17:18 /dev/sde8 brw-rw---- 1 root disk 8, 73 2012-03-03 17:18 /dev/sde9 $ Thanks Phillip Susi for finding and fixing this parted bug. :-)
Status -> fixed ?
If you think so then I can certainly mark this bug report as fixed. The reason I was thinking of holding off on closing this report is because if a user compiles and links with parted-3.1 using an official release of GParted (0.12.0), then they will not receive the benefit of resizing FAT16/FAT32, and HFS/HFS+ file systems. The enhancement to use the new libparted-fs-resize library was just committed to the repository on March 3rd, 2012. Enable new fs resize library available with parted-3.1 (#668281) http://git.gnome.org/browse/gparted/commit/?id=0fda1d011d79c2e0e4d884e03947f2e4e8cec986 Is there an advantage if I close the report now, as opposed to when the next version of GParted is released?
The enhancements for this bug report have been included in GParted 0.12.1 released on April 9, 2012.