GNU bug report logs - #33607
Partition list loop

Previous Next

Package: parted;

Reported by: Paul Ausbeck <paula <at> soe.ucsc.edu>

Date: Tue, 4 Dec 2018 06:22:01 UTC

Severity: normal

To reply to this bug, email your comments to 33607 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-parted <at> gnu.org:
bug#33607; Package parted. (Tue, 04 Dec 2018 06:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Ausbeck <paula <at> soe.ucsc.edu>:
New bug report received and forwarded. Copy sent to bug-parted <at> gnu.org. (Tue, 04 Dec 2018 06:22:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Ausbeck <paula <at> soe.ucsc.edu>
To: bug-parted <at> gnu.org
Subject: Partition list loop
Date: Mon, 3 Dec 2018 21:04:19 -0800
I have a disk with three primary partitions and one extended partition. The extended partition originally contained 4 logical volumes sda5-8. sda5 and sda6 were 16GB, sda7 8GB, and sda8 the balance of the extended partition > 100GB. sda5 and sda6 contained debian jessie x86 and x64 boot filesystems. I wanted to install stretch filesystems on this disk so booting to sda6 I resized sda5 to fit into 8GB. I then used fdisk to delete sda5 and create two new 8GB partitions sda8 and sda9 where the 16GB sda5 formerly resided. When I committed the changes partprobe reported that the new partition table couldn't be read due to partitions being busy and I should reboot. After the reboot everything was as fdisk said it would be, partitions formerly sda6-8 were now sda5-7 and the new partitions were sda8-9.

Now this is where things went off the rails. I decided that before making any more changes I would reorder the partition table to be in disk order, using fdisk's extended command, x, then f. After fixing the partition order, fdisk listed all nine partitions in partition order. I then committed the changes and again got the partprobe message that I should reboot. Well, at this point the drive would not boot properly. The linux kernel loads but partprobe is looping through the logical partitions again and again and creating many copies of the same five partitions, up to a max it looks like of sda255.

If I run parted and try and print the partition table I get the following error:

Assertion (metadata length >0) at .././../libparted/labels/dos.c:2313 in function add_logical_part_metadata() failed.

At this point, I don't know exactly who to blame. Either fdisk has somehow created an unterminated, looping partition list, or parted/partprobe is erroneously processing a correct list. I'm reporting on the parted mailing list as I ran into your assertion and bug report instructions and thought you'd like to know about it.

Personally, I'm thinking that parted/partprobe shouldn't loop back through the same partitions reporting them as additional partitions, even if the partition list is telling them to do so.

Also, I'm hoping that someone on the parted list can tell me how to patch things up with dd.

I can boot from a USB stick and use fdisk to print its idea of the partition table, below.  Parted does not print the table but throws the above assertion. The table:

Command (m for help): p
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa0e33a5e

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048   2459647   2457600   1.2G  7 HPFS/NTFS/exFAT
/dev/sda2         2459648  84379647  81920000  39.1G  7 HPFS/NTFS/exFAT
/dev/sda3        84379648 166299647  81920000  39.1G  7 HPFS/NTFS/exFAT
/dev/sda4       166299648 488397167 322097520 153.6G  5 Extended
/dev/sda5       166301696 183078911  16777216     8G 83 Linux
/dev/sda6       183080960 199858175  16777216     8G 83 Linux
/dev/sda7       199858176 233412607  33554432    16G 83 Linux
/dev/sda8       233414656 250191871  16777216     8G 82 Linux swap / Solari
/dev/sda9       250193920 488397167 238203248 113.6G 83 Linux





Information forwarded to bug-parted <at> gnu.org:
bug#33607; Package parted. (Wed, 05 Dec 2018 23:30:02 GMT) Full text and rfc822 format available.

Message #8 received at 33607 <at> debbugs.gnu.org (full text, mbox):

From: Paul Ausbeck <paula <at> soe.ucsc.edu>
To: 33607 <at> debbugs.gnu.org
Subject: Recovered from partition list loop
Date: Wed, 5 Dec 2018 15:14:07 -0800
When I posted the original problem I was sort of hoping to get some recovery advice. However, I've now recovered the partition table and I'm now posting just to further document my experience. I'm now thinking that the bug I encountered is likely in the fdisk program, but I still think that parted/partprobe could be improved to better handle loops in the partition table.

To recover, I booted the system from a USB stick. At this point the disk partition table was still hosed and there were 255 associated devices, sda1 - sda255 in /dev. parted would still not print the hosed partition table, but bailed out as described previously. However, fdisk would print the table, but somehow saw only, I can't remember exactly, maybe 45 or 54 partitions. On a lark, I used fdisk to delete the extra partitions and wrote the edited table. Upon reboot, the disk was whole again with the correct/expected partition table in disk order. Go figure.

Cheers, Paul Ausbeck




Information forwarded to bug-parted <at> gnu.org:
bug#33607; Package parted. (Tue, 23 Apr 2019 15:32:01 GMT) Full text and rfc822 format available.

Message #11 received at 33607 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <phill <at> thesusis.net>
To: Paul Ausbeck <paula <at> soe.ucsc.edu>
Cc: 33607 <at> debbugs.gnu.org
Subject: Re: bug#33607: Recovered from partition list loop
Date: Tue, 23 Apr 2019 11:31:47 -0400
Was the kernel able to correctly read the partition table at boot or
after running blockdev --rereadpt?  If fdisk and the kernel are both
happy with it then it may just be a bug in parted.

Paul Ausbeck writes:

> When I posted the original problem I was sort of hoping to get some recovery advice. However, I've now recovered the partition table and I'm now posting just to further document my experience. I'm now thinking that the bug I encountered is likely in the fdisk program, but I still think that parted/partprobe could be improved to better handle loops in the partition table.
>
> To recover, I booted the system from a USB stick. At this point the disk partition table was still hosed and there were 255 associated devices, sda1 - sda255 in /dev. parted would still not print the hosed partition table, but bailed out as described previously. However, fdisk would print the table, but somehow saw only, I can't remember exactly, maybe 45 or 54 partitions. On a lark, I used fdisk to delete the extra partitions and wrote the edited table. Upon reboot, the disk was whole again with the correct/expected partition table in disk order. Go figure.
>
> Cheers, Paul Ausbeck





This bug report was last modified 6 years and 56 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.