GNU bug report logs -
#21522
assertion metadata_length > 0 in add_logical_part_metadata failed
Previous Next
To reply to this bug, email your comments to 21522 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Sun, 20 Sep 2015 07:23:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
James Ring <sjr <at> jdns.org>
:
New bug report received and forwarded. Copy sent to
bug-parted <at> gnu.org
.
(Sun, 20 Sep 2015 07:23:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi there,
(please cc me on replies)
I ran into an assertion error in parted running on my Kubuntu box:
sjr <at> sjr-desktop:~$ sudo parted /dev/sdb print
Backtrace has 14 calls on stack:
14: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x44) [0x7feda0f8c2e4]
13: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e876) [0x7feda0f9f876]
12: /lib/x86_64-linux-gnu/libparted.so.2(+0xfd4a) [0x7feda0f90d4a]
11: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_add_partition+0x263)
[0x7feda0f91643]
10: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e155) [0x7feda0f9f155]
9: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e1f0) [0x7feda0f9f1f0]
8: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e18f) [0x7feda0f9f18f]
7: /lib/x86_64-linux-gnu/libparted.so.2(+0x1f2a5) [0x7feda0fa02a5]
6: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_new+0x48) [0x7feda0f91268]
5: parted() [0x407769]
4: parted(non_interactive_mode+0x92) [0x40cb22]
3: parted(main+0x10a8) [0x405e78]
2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7feda0768a40]
1: parted(_start+0x29) [0x405fc9]
You found a bug in GNU Parted! Here's what you have to do:
Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:
Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:
http://ftp.gnu.org/gnu/parted/
Please check this version prior to bug reporting.
If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:
http://www.gnu.org/software/parted
for further information.
Your report should contain the version of this release (3.2)
along with the error message below, the output of
parted DEVICE unit co print unit s print
and the following history of commands you entered.
Also include any additional information about your setup you
consider important.
Assertion (metadata_length > 0) at
../../../libparted/labels/dos.c:2313 in function
add_logical_part_metadata() failed.
Output of parted /dev/sdb unit co print unit s print is the same.
fdisk /dev/sdb:
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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: 0x25978550
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sdb2 206848 1022138367 1021931520 487.3G 7 HPFS/NTFS/exFAT
/dev/sdb3 1022138368 1025413119 3274752 1.6G 83 Linux
/dev/sdb4 1431537662 1953523711 521986050 248.9G 5 Extended
/dev/sdb5 1431537664 1930088447 498550784 237.7G 83 Linux
/dev/sdb6 1930088448 1953523711 23435264 11.2G 82 Linux swap / Solaris
sjr <at> sjr-desktop:~$ uname -a
Linux sjr-desktop 4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
sjr <at> sjr-desktop:~$ lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description: Ubuntu Wily Werewolf (development branch)
Release: 15.10
Codename: wily
Please let me know if I can be of any more help.
Regards,
James
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Sun, 20 Sep 2015 07:47:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
More info:
sjr <at> sjr-desktop:~$ sudo parted -v
parted (GNU parted) 3.2
sjr <at> sjr-desktop:~$ dpkg -l parted
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==========================================-==========================-==========================-==========================================================================================
ii parted 3.2-7ubuntu1
amd64 disk partition manipulator
Please let me know if I should file this against ubuntu instead.
On Sat, Sep 19, 2015 at 9:26 PM, James Ring <sjr <at> jdns.org> wrote:
> Hi there,
>
> (please cc me on replies)
>
> I ran into an assertion error in parted running on my Kubuntu box:
>
> sjr <at> sjr-desktop:~$ sudo parted /dev/sdb print
>
> Backtrace has 14 calls on stack:
>
> 14: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x44) [0x7feda0f8c2e4]
>
> 13: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e876) [0x7feda0f9f876]
>
> 12: /lib/x86_64-linux-gnu/libparted.so.2(+0xfd4a) [0x7feda0f90d4a]
>
> 11: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_add_partition+0x263)
> [0x7feda0f91643]
>
> 10: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e155) [0x7feda0f9f155]
>
> 9: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e1f0) [0x7feda0f9f1f0]
>
> 8: /lib/x86_64-linux-gnu/libparted.so.2(+0x1e18f) [0x7feda0f9f18f]
>
> 7: /lib/x86_64-linux-gnu/libparted.so.2(+0x1f2a5) [0x7feda0fa02a5]
>
> 6: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_new+0x48) [0x7feda0f91268]
>
> 5: parted() [0x407769]
>
> 4: parted(non_interactive_mode+0x92) [0x40cb22]
>
> 3: parted(main+0x10a8) [0x405e78]
>
> 2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7feda0768a40]
>
> 1: parted(_start+0x29) [0x405fc9]
>
>
>
> You found a bug in GNU Parted! Here's what you have to do:
>
>
> Don't panic! The bug has most likely not affected any of your data.
>
> Help us to fix this bug by doing the following:
>
>
> Check whether the bug has already been fixed by checking
>
> the last version of GNU Parted that you can find at:
>
>
> http://ftp.gnu.org/gnu/parted/
>
>
> Please check this version prior to bug reporting.
>
>
> If this has not been fixed yet or if you don't know how to check,
>
> please visit the GNU Parted website:
>
>
> http://www.gnu.org/software/parted
>
>
> for further information.
>
>
> Your report should contain the version of this release (3.2)
>
> along with the error message below, the output of
>
>
> parted DEVICE unit co print unit s print
>
>
> and the following history of commands you entered.
>
> Also include any additional information about your setup you
>
> consider important.
>
>
> Assertion (metadata_length > 0) at
> ../../../libparted/labels/dos.c:2313 in function
> add_logical_part_metadata() failed.
>
>
> Output of parted /dev/sdb unit co print unit s print is the same.
>
> fdisk /dev/sdb:
> Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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: 0x25978550
>
>
> Device Boot Start End Sectors Size Id Type
>
> /dev/sdb1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
>
> /dev/sdb2 206848 1022138367 1021931520 487.3G 7 HPFS/NTFS/exFAT
>
> /dev/sdb3 1022138368 1025413119 3274752 1.6G 83 Linux
>
> /dev/sdb4 1431537662 1953523711 521986050 248.9G 5 Extended
>
> /dev/sdb5 1431537664 1930088447 498550784 237.7G 83 Linux
>
> /dev/sdb6 1930088448 1953523711 23435264 11.2G 82 Linux swap / Solaris
>
> sjr <at> sjr-desktop:~$ uname -a
>
> Linux sjr-desktop 4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> sjr <at> sjr-desktop:~$ lsb_release -a
>
> LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
>
> Distributor ID: Ubuntu
>
> Description: Ubuntu Wily Werewolf (development branch)
>
> Release: 15.10
>
> Codename: wily
>
> Please let me know if I can be of any more help.
>
> Regards,
> James
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 17:08:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/20/2015 12:26 AM, James Ring wrote:
> Hi there,
>
> (please cc me on replies)
>
> I ran into an assertion error in parted running on my Kubuntu box:
>
> sjr <at> sjr-desktop:~$ sudo parted /dev/sdb print
Is this really the command that provoked this or was it something else?
I ask because you later show a print out of the partition table, which
you shouldn't be able to get if the print command is what is crashing.
Can you run sudo dd if=/dev/sdb count=1 | xxd and show the output?
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 18:07:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 21522 <at> debbugs.gnu.org (full text, mbox):
Hi Paul,
On Tue, Sep 22, 2015 at 10:06 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/20/2015 12:26 AM, James Ring wrote:
>> Hi there,
>>
>> (please cc me on replies)
>>
>> I ran into an assertion error in parted running on my Kubuntu box:
>>
>> sjr <at> sjr-desktop:~$ sudo parted /dev/sdb print
>
> Is this really the command that provoked this or was it something else?
Yeah, I just re-confirmed that this also causes the assertion failure.
> I ask because you later show a print out of the partition table, which
> you shouldn't be able to get if the print command is what is crashing.
> Can you run sudo dd if=/dev/sdb count=1 | xxd and show the output?
sjr <at> sjr-desktop:~$ sudo dd if=/dev/sdb count=1 | xxd
1+0 records in
1+0 records out
512 bytes (512 B) copied, 4.5406e-05 s, 11.3 MB/s
00000000: eb63 90d0 bc00 7c8e c08e d8be 007c bf00 .c....|......|..
00000010: 06b9 0002 fcf3 a450 681c 06cb fbb9 0400 .......Ph.......
00000020: bdbe 0780 7e00 007c 0b0f 850e 0183 c510 ....~..|........
00000030: e2f1 cd18 8856 0055 c646 1105 c646 1000 .....V.U.F...F..
00000040: b441 bbaa 55cd 135d 720f 81fb 55aa 7509 .A..U..]r...U.u.
00000050: f7c1 0100 7403 fe46 1066 0080 0100 0000 ....t..F.f......
00000060: 0000 0000 fffa 9090 f6c2 8074 05f6 c270 ...........t...p
00000070: 7402 b280 ea79 7c00 0031 c08e d88e d0bc t....y|..1......
00000080: 0020 fba0 647c 3cff 7402 88c2 52bb 1704 . ..d|<.t...R...
00000090: f607 0374 06be 887d e817 01be 057c b441 ...t...}.....|.A
000000a0: bbaa 55cd 135a 5272 3d81 fb55 aa75 3783 ..U..ZRr=..U.u7.
000000b0: e101 7432 31c0 8944 0440 8844 ff89 4402 ..t21..D.@.D..D.
000000c0: c704 1000 668b 1e5c 7c66 895c 0866 8b1e ....f..\|f.\.f..
000000d0: 607c 6689 5c0c c744 0600 70b4 42cd 1372 `|f.\..D..p.B..r
000000e0: 05bb 0070 eb76 b408 cd13 730d 5a84 d20f ...p.v....s.Z...
000000f0: 83d0 00be 937d e982 0066 0fb6 c688 64ff .....}...f....d.
00000100: 4066 8944 040f b6d1 c1e2 0288 e888 f440 @f.D...........@
00000110: 8944 080f b6c2 c0e8 0266 8904 66a1 607c .D.......f..f.`|
00000120: 6609 c075 4e66 a15c 7c66 31d2 66f7 3488 f..uNf.\|f1.f.4.
00000130: d131 d266 f774 043b 4408 7d37 fec1 88c5 .1.f.t.;D.}7....
00000140: 30c0 c1e8 0208 c188 d05a 88c6 bb00 708e 0........Z....p.
00000150: c331 dbb8 0102 cd13 721e 8cc3 601e b900 .1......r...`...
00000160: 018e db31 f6bf 0080 8ec6 fcf3 a51f 61ff ...1..........a.
00000170: 265a 7cbe 8e7d eb03 be9d 7de8 3400 bea2 &Z|..}....}.4...
00000180: 7de8 2e00 cd18 ebfe 4752 5542 2000 4765 }.......GRUB .Ge
00000190: 6f6d 0048 6172 6420 4469 736b 0052 6561 om.Hard Disk.Rea
000001a0: 6400 2045 7272 6f72 0d0a 00bb 0100 b40e d. Error........
000001b0: cd10 ac3c 0075 f4c3 5085 9725 0000 8020 ...<.u..P..%...
000001c0: 2100 07df 130c 0008 0000 0020 0300 00a3 !.......... ....
000001d0: 140d 07ef ffff 0028 0300 0070 e93c 00fe .......(...p.<..
000001e0: ffff 83fe ffff 0098 ec3c 00f8 3100 00fe .........<..1...
000001f0: ffff 05fe ffff fe87 5355 02e0 1c1f 55aa ........SU....U.
Hopefully gmail leaves the line wrapping alone in that paste...
Regards,
James
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 18:31:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/22/2015 2:06 PM, James Ring wrote:
> Hi Paul,
It's Phill, not Paul ;)
I'm still wondering how you got the partition table to print without
getting this crash? Also when I try to reproduce it, I get an odd error
from the mac partition table code about an invalid signature zero. I
might need a few more sectors from your boot track. Please run:
sudo dd if=/dev/sdb count=63 of=mbr
bzip2 mbr
And attach the file.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 18:41:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Phill,
On Tue, Sep 22, 2015 at 11:30 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/22/2015 2:06 PM, James Ring wrote:
>> Hi Paul,
>
> It's Phill, not Paul ;)
Sorry, my bad! :)
> I'm still wondering how you got the partition table to print without
> getting this crash? Also when I try to reproduce it, I get an odd error
> from the mac partition table code about an invalid signature zero. I
> might need a few more sectors from your boot track. Please run:
>
> sudo dd if=/dev/sdb count=63 of=mbr
> bzip2 mbr
>
> And attach the file.
Attached mbr.bz2, thanks for taking a look.
[mbr.bz2 (application/x-bzip2, attachment)]
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 18:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/22/2015 2:40 PM, James Ring wrote:
> Attached mbr.bz2, thanks for taking a look.
Same results, and I'm still waiting for an answer as to how you managed
to print the table when the print command crashes.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 19:01:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On Tue, Sep 22, 2015 at 11:51 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/22/2015 2:40 PM, James Ring wrote:
>> Attached mbr.bz2, thanks for taking a look.
>
> Same results, and I'm still waiting for an answer as to how you managed
> to print the table when the print command crashes.
That was just the output of fdisk -l /dev/sdb
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 20:42:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/22/2015 3:00 PM, James Ring wrote:
> On Tue, Sep 22, 2015 at 11:51 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
>> On 9/22/2015 2:40 PM, James Ring wrote:
>>> Attached mbr.bz2, thanks for taking a look.
>>
>> Same results, and I'm still waiting for an answer as to how you managed
>> to print the table when the print command crashes.
>
> That was just the output of fdisk -l /dev/sdb
/facepalm
Of course.. and since this involves an extended partition, I need your
EBR as well:
sudo dd if=/dev/sdb skip=1431537662 count=1 of=ebr
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 21:15:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On Tue, Sep 22, 2015 at 1:40 PM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/22/2015 3:00 PM, James Ring wrote:
>> On Tue, Sep 22, 2015 at 11:51 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
>>> On 9/22/2015 2:40 PM, James Ring wrote:
>>>> Attached mbr.bz2, thanks for taking a look.
>>>
>>> Same results, and I'm still waiting for an answer as to how you managed
>>> to print the table when the print command crashes.
>>
>> That was just the output of fdisk -l /dev/sdb
>
> /facepalm
>
> Of course.. and since this involves an extended partition, I need your
> EBR as well:
>
> sudo dd if=/dev/sdb skip=1431537662 count=1 of=ebr
sjr <at> sjr-desktop:/tmp$ sudo dd if=/dev/sdb skip=1431537662 count=1
of=/dev/stdout | xxd
1+0 records in
1+0 records out
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
512 bytes (512 B) copied00000010: 0000 0000 0000 0000 0000 0000 0000
0000 ................
, 0.000138598 s, 3.7 MB/s
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 00fe ................
000001c0: ffff 83fe ffff 0200 0000 0048 b71d 00fe ...........H....
000001d0: ffff 05fe ffff 0100 0000 0148 b71d 0000 ...........H....
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Tue, 22 Sep 2015 21:16:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 21522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry, there's interleaving, attached the ebr file instead.
On Tue, Sep 22, 2015 at 2:14 PM, James Ring <sjr <at> jdns.org> wrote:
> On Tue, Sep 22, 2015 at 1:40 PM, Phil Susi <psusi <at> ubuntu.com> wrote:
>> On 9/22/2015 3:00 PM, James Ring wrote:
>>> On Tue, Sep 22, 2015 at 11:51 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
>>>> On 9/22/2015 2:40 PM, James Ring wrote:
>>>>> Attached mbr.bz2, thanks for taking a look.
>>>>
>>>> Same results, and I'm still waiting for an answer as to how you managed
>>>> to print the table when the print command crashes.
>>>
>>> That was just the output of fdisk -l /dev/sdb
>>
>> /facepalm
>>
>> Of course.. and since this involves an extended partition, I need your
>> EBR as well:
>>
>> sudo dd if=/dev/sdb skip=1431537662 count=1 of=ebr
>
> sjr <at> sjr-desktop:/tmp$ sudo dd if=/dev/sdb skip=1431537662 count=1
> of=/dev/stdout | xxd
> 1+0 records in
> 1+0 records out
> 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 512 bytes (512 B) copied00000010: 0000 0000 0000 0000 0000 0000 0000
> 0000 ................
> , 0.000138598 s, 3.7 MB/s
> 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000001b0: 0000 0000 0000 0000 0000 0000 0000 00fe ................
> 000001c0: ffff 83fe ffff 0200 0000 0048 b71d 00fe ...........H....
> 000001d0: ffff 05fe ffff 0100 0000 0148 b71d 0000 ...........H....
> 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
[ebr (application/octet-stream, attachment)]
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Wed, 23 Sep 2015 12:55:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/22/2015 5:15 PM, James Ring wrote:
> Sorry, there's interleaving, attached the ebr file instead.
Strange... I still get the same thing, but miss the last logical
partition. I think I need the next sector following that last one for that.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Wed, 23 Sep 2015 16:32:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 21522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Sep 23, 2015 at 5:53 AM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/22/2015 5:15 PM, James Ring wrote:
>> Sorry, there's interleaving, attached the ebr file instead.
>
> Strange... I still get the same thing, but miss the last logical
> partition. I think I need the next sector following that last one for that.
Here is the output from
sudo dd if=/dev/sdb skip=1431537662 count=2 of=ebr
[ebr (application/octet-stream, attachment)]
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 00:16:01 GMT)
Full text and
rfc822 format available.
Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 19, 2015 at 09:26:20PM -0700, James Ring wrote:
> Your report should contain the version of this release (3.2)
>
> along with the error message below, the output of
>
>
> parted DEVICE unit co print unit s print
>
>
> and the following history of commands you entered.
>
> Also include any additional information about your setup you
>
> consider important.
>
>
> Assertion (metadata_length > 0) at
> ../../../libparted/labels/dos.c:2313 in function
> add_logical_part_metadata() failed.
>
>
> Output of parted /dev/sdb unit co print unit s print is the same.
>
> fdisk /dev/sdb:
> Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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: 0x25978550
>
>
> Device Boot Start End Sectors Size Id Type
>
> /dev/sdb1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
>
> /dev/sdb2 206848 1022138367 1021931520 487.3G 7 HPFS/NTFS/exFAT
>
> /dev/sdb3 1022138368 1025413119 3274752 1.6G 83 Linux
>
> /dev/sdb4 1431537662 1953523711 521986050 248.9G 5 Extended
>
> /dev/sdb5 1431537664 1930088447 498550784 237.7G 83 Linux
>
> /dev/sdb6 1930088448 1953523711 23435264 11.2G 82 Linux swap / Solaris
This isn't actually a bug, logical partitions need to have at least 1
sector between them for metadata storage. parted enforces this when
creating logical partitions, but other tools do not.
See the comments before _log_meta_overlap_constraint for some of the
background.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 14:55:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/23/2015 8:15 PM, Brian C. Lane wrote:
> This isn't actually a bug, logical partitions need to have at least 1
> sector between them for metadata storage. parted enforces this when
> creating logical partitions, but other tools do not.
While parted lays out the disk this way, it doesn't have to be. The EBR
for each chained logical volume can be placed anywhere in the extended
partition. In his case, it looks like both are at the start of the
extended partition. This is perfectly ok and parted should accept it.
Now that I have both EBRs I'm able to reproduce the crash and will try
to fix it.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 15:57:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 24, 2015 at 10:53:31AM -0400, Phil Susi wrote:
> On 9/23/2015 8:15 PM, Brian C. Lane wrote:
> > This isn't actually a bug, logical partitions need to have at least 1
> > sector between them for metadata storage. parted enforces this when
> > creating logical partitions, but other tools do not.
>
> While parted lays out the disk this way, it doesn't have to be. The EBR
> for each chained logical volume can be placed anywhere in the extended
> partition. In his case, it looks like both are at the start of the
> extended partition. This is perfectly ok and parted should accept it.
>
> Now that I have both EBRs I'm able to reproduce the crash and will try
> to fix it.
Are you sure? According to
https://en.wikipedia.org/wiki/Extended_boot_record the EBR is at the
start of each logical partition, and chains to the next. I suppose it is
possible that would work since it has separate pointers for the
partition and the next EBR but none of the authoritative diagrams I've
seen show that. eg.
https://technet.microsoft.com/en-us/library/cc977219.aspx also shows the
EBR at the start of the logical partition.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 17:23:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/24/2015 11:56 AM, Brian C. Lane wrote:
> Are you sure? According to
> https://en.wikipedia.org/wiki/Extended_boot_record the EBR is at the
> start of each logical partition, and chains to the next. I suppose it is
> possible that would work since it has separate pointers for the
> partition and the next EBR but none of the authoritative diagrams I've
> seen show that. eg.
> https://technet.microsoft.com/en-us/library/cc977219.aspx also shows the
> EBR at the start of the logical partition.
Yes, it should work anywhere, and it seems that both the linux kernel
partition table parser and fdisk are fine with it. I'm pretty sure that
DOS was also fine with such an arrangement, though anyone sane has
always put it just before the logical partition like all of the diagrams
show. What I wonder is why has this not been an issue before, and why
is it one now? That is, since it seems no partitioning tools have ever
done this before, which one is doing it now?
I've also been looking at the parted code for writing the partition
table and I'm beating my head against the desk now because I swear, it
can't possibly work the way it is. What am I missing here?
It *should* be writing the EBR for the next logical partition to start -
1, or prev->end + 1. Instead, it does this:
geom = ped_geometry_new (disk->dev, part->prev->geom.start,
part->geom.end - part->prev->geom.start + 1);
That says put it in the boot sector of the previous logical partition,
doesn't it?
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 17:46:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 24, 2015 at 01:21:50PM -0400, Phil Susi wrote:
> On 9/24/2015 11:56 AM, Brian C. Lane wrote:
> > Are you sure? According to
> > https://en.wikipedia.org/wiki/Extended_boot_record the EBR is at the
> > start of each logical partition, and chains to the next. I suppose it is
> > possible that would work since it has separate pointers for the
> > partition and the next EBR but none of the authoritative diagrams I've
> > seen show that. eg.
> > https://technet.microsoft.com/en-us/library/cc977219.aspx also shows the
> > EBR at the start of the logical partition.
>
> Yes, it should work anywhere, and it seems that both the linux kernel
> partition table parser and fdisk are fine with it. I'm pretty sure that
> DOS was also fine with such an arrangement, though anyone sane has
> always put it just before the logical partition like all of the diagrams
> show. What I wonder is why has this not been an issue before, and why
> is it one now? That is, since it seems no partitioning tools have ever
> done this before, which one is doing it now?
I've only seen 1 other bug like this in Fedora, and I basically told
them they need to recreate their disk or use some other tool. I'm not
sure we need to support such a corner case.
>
> I've also been looking at the parted code for writing the partition
> table and I'm beating my head against the desk now because I swear, it
> can't possibly work the way it is. What am I missing here?
>
> It *should* be writing the EBR for the next logical partition to start -
> 1, or prev->end + 1. Instead, it does this:
>
> geom = ped_geometry_new (disk->dev, part->prev->geom.start,
> part->geom.end - part->prev->geom.start + 1);
>
> That says put it in the boot sector of the previous logical partition,
> doesn't it?
The EBR code really needs more comments I think :) What's happening is
it is rewriting the extended partition and each of the logical
partitions in a loop. Note that below that code it calls itself
passing in the new part. So it will run out to the last logical
partition and then start writing tables, so you have to hold things
upside down and backwards to understand it :)
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 19:12:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On 9/24/2015 1:45 PM, Brian C. Lane wrote:
> I've only seen 1 other bug like this in Fedora, and I basically told
> them they need to recreate their disk or use some other tool. I'm not
> sure we need to support such a corner case.
Given that it doesn't look like this will be easy to fix and how
exceedingly rare it is ( which is kind of surprising to be honest ), I'm
starting to agree. On the other hand, we should at least throw a proper
error message that we don't like your goofy partition table rather than
crash with an assertion failure.
> The EBR code really needs more comments I think :) What's happening is
> it is rewriting the extended partition and each of the logical
> partitions in a loop. Note that below that code it calls itself
> passing in the new part. So it will run out to the last logical
> partition and then start writing tables, so you have to hold things
> upside down and backwards to understand it :)
Maybe I need to stand on my head? ;)
I see that it is iterating over all of the logical partitions using
recursion, and at each one, it fills out an EBR with the first slot
pointing to that logical partition, and the second slot should be
pointing to where the next partition's EBR will go... but that doesn't
look like what it is doing because where the next should go is not the
previous one's first sector. Also when it calls itself, it should be
passing the sector number of the next EBR corresponding to the logical
partition that next stack frame will handle. Yet instead it is passing
part->prev->geom.start, which is this partition's boot sector.
In other words, it is first called on partition 5, then it calls itself
on partition 6, but says to itself that the EBR for partition 6 is in
the first sector of partition 5.
Information forwarded
to
bug-parted <at> gnu.org
:
bug#21522
; Package
parted
.
(Thu, 24 Sep 2015 19:34:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 21522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 24, 2015 at 12:10 PM, Phil Susi <psusi <at> ubuntu.com> wrote:
> On 9/24/2015 1:45 PM, Brian C. Lane wrote:
>> I've only seen 1 other bug like this in Fedora, and I basically told
>> them they need to recreate their disk or use some other tool. I'm not
>> sure we need to support such a corner case.
>
> Given that it doesn't look like this will be easy to fix and how
> exceedingly rare it is ( which is kind of surprising to be honest ), I'm
> starting to agree. On the other hand, we should at least throw a proper
> error message that we don't like your goofy partition table rather than
> crash with an assertion failure.
I wish I could remember exactly how I partitioned the disk. I think I
resized the NTFS partition using the Windows 7 tools and then let the
Ubuntu installer partition the rest of the disk. I'm surprised the bug
is so rare, I don't think I did anything super strange.
Regards,
James
This bug report was last modified 9 years and 265 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.