GNU bug report logs - #32666
Assertion (metadata_length > 0) failed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32666 in the body.
You can then email your comments to 32666 AT debbugs.gnu.org in the normal way.

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

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

From: Nikolaus Rath <Nikolaus <at> rath.org>
To: bug-parted <at> gnu.org
Subject: Assertion (metadata_length > 0) failed
Date: Sat, 08 Sep 2018 21:28:16 +0100

Hello,

On my system, parted crashes with:

# parted /dev/sdb
GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Backtrace has 15 calls on stack:
  15: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x45) [0x7f638abdafc5]
  14: /lib/x86_64-linux-gnu/libparted.so.2(+0x23b3f) [0x7f638abf1b3f]
  13: /lib/x86_64-linux-gnu/libparted.so.2(+0x119fa) [0x7f638abdf9fa]
  12: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_add_partition+0x283) [0x7f638abe0313]
  11: /lib/x86_64-linux-gnu/libparted.so.2(+0x233ec) [0x7f638abf13ec]
  10: /lib/x86_64-linux-gnu/libparted.so.2(+0x23480) [0x7f638abf1480]
  9: /lib/x86_64-linux-gnu/libparted.so.2(+0x23480) [0x7f638abf1480]
  8: /lib/x86_64-linux-gnu/libparted.so.2(+0x23426) [0x7f638abf1426]
  7: /lib/x86_64-linux-gnu/libparted.so.2(+0x24455) [0x7f638abf2455]
  6: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_new+0x48) [0x7f638abdff18]
  5: parted(+0x73fe) [0x55d13304c3fe]
  4: parted(interactive_mode+0x120) [0x55d1330520b0]
  3: parted(main+0x142b) [0x55d13304b1eb]
  2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f638a3d82e1]
  1: parted(_start+0x2a) [0x55d13304b24a]


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:
[...]
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.

Aborted                                                                   


# parted /dev/sdb unit co print unit s print
Backtrace has 15 calls on stack:
  15: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x45) [0x7f7887268fc5]
[same as above]


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

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

From: Nikolaus Rath <nikolaus <at> rath.org>
To: 32666 <at> debbugs.gnu.org
Subject: fdisk output
Date: Sat, 08 Sep 2018 21:36:09 +0100

[Message part 1 (text/plain, inline)]

Here's what regular fdisk says:

# fdisk -l /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 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: 0xe7c4933a

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT/dev/sdb2          206848 738138111 737931264 351.9G  7 HPFS/NTFS/exFAT/dev/sdb3       738138112 739059711    921600   450M 27 Hidden
NTFS WinRE/dev/sdb4       739059712 976773119 237713408 113.4G  5 Extended
/dev/sdb5       739061760 739129343     67584    33M 83 Linux
/dev/sdb6       739131392 739588095    456704   223M 83 Linux
/dev/sdb7       739588096 773142527  33554432    16G 8e Linux LVM
/dev/sdb8       773144576 976773119 203628544  97.1G 8e Linux LVM

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[Message part 2 (text/html, inline)]

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

From: Kevin Locke <kevin <at> kevinlocke.name>
To: 32666 <at> debbugs.gnu.org
Subject: Re: Assertion (metadata_length > 0) failed
Date: Mon, 24 Sep 2018 20:46:39 -0600

On Sat, 2018-09-08 at 21:28 +0100, Nikolaus Rath wrote:
> On my system, parted crashes with:
>
> [...]
>
> Assertion (metadata_length > 0) at ../../../libparted/labels/dos.c:2313 in function
> add_logical_part_metadata() failed.
> 
> Aborted                                                                   

I encountered the same assertion failure from the resizepart command.
I was able to get a full backtrace after building from current master
(f0cfa958) with CFLAGS="-g -O0" as a result of running the command:

parted /dev/sdb resizepart 5 976824319s

#0  __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff7b3f2f1 in __GI_abort () at abort.c:79
#2  0x00007ffff7f7c80b in ped_assert (
    cond_text=0x7ffff7fb75bc "metadata_length > 0", 
    file=0x7ffff7fb7191 "dos.c", line=2305, 
    function=0x7ffff7fb7930 <__PRETTY_FUNCTION__.5302> "add_logical_part_metadata") at debug.c:111
#3  0x00007ffff7f9ad96 in add_logical_part_metadata (disk=0x55555559b210, 
    log_part=0x5555555a1f80) at dos.c:2305
#4  0x00007ffff7f9b13b in msdos_alloc_metadata (disk=0x55555559b210)
    at dos.c:2436
#5  0x00007ffff7f8135f in _disk_alloc_metadata (disk=0x55555559b210)
    at disk.c:1010
#6  0x00007ffff7f81782 in _disk_pop_update_mode (disk=0x55555559b210)
    at disk.c:1163
#7  0x00007ffff7f83968 in ped_disk_set_partition_geom (disk=0x55555559b210, 
    part=0x5555555a1eb0, constraint=0x5555555949d0, start=976562176, 
    end=976824319) at disk.c:2171
#8  0x000055555555da09 in do_resizepart (dev=0x7fffffffe4c0, 
    diskp=0x7fffffffe4b8) at parted.c:1576
#9  0x0000555555559f09 in command_run (cmd=0x555555574b40, dev=0x7fffffffe4c0, 
    diskp=0x7fffffffe4b8) at command.c:141
#10 0x00005555555638f6 in interactive_mode (dev=0x7fffffffe4c0, 
    disk=0x7fffffffe4b8, cmd_list=0x55555556b6c0 <commands>) at ui.c:1630
#11 0x000055555555fae2 in main (argc=0, argv=0x7fffffffe5c8) at parted.c:2356

The output of `parted /dev/sdb unit co print unit s print`:

Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size   Type      File system  Flags
 1      1049kB  269MB   268MB  primary
 2      269MB   404MB   134MB  primary
 3      404MB   500GB   500GB  primary
 4      500GB   1000GB  500GB  extended               lba
 5      500GB   500GB   134MB  logical
 6      500GB   996GB   496GB  logical

Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sdb: 1953525168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start       End          Size        Type      File system  Flags
 1      2048s       526335s      524288s     primary
 2      526336s     788479s      262144s     primary
 3      788480s     976562174s   975773695s  primary
 4      976562175s  1953525167s  976962993s  extended               lba
 5      976562176s  976824318s   262143s     logical
 6      976824320s  1945136559s  968312240s  logical

Let me know if there is any other information I can provide.

Thanks,
Kevin

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

From: "Brian C. Lane" <bcl <at> redhat.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#32666: Assertion (metadata_length > 0) failed
Date: Mon, 15 Oct 2018 09:11:05 -0700

On Mon, Sep 24, 2018 at 08:46:39PM -0600, Kevin Locke wrote:

[snip]

> Model: ATA Samsung SSD 860 (scsi)
> Disk /dev/sdb: 1953525168s
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
> Disk Flags: 
> 
> Number  Start       End          Size        Type      File system  Flags
>  1      2048s       526335s      524288s     primary
>  2      526336s     788479s      262144s     primary
>  3      788480s     976562174s   975773695s  primary
>  4      976562175s  1953525167s  976962993s  extended               lba
>  5      976562176s  976824318s   262143s     logical
>  6      976824320s  1945136559s  968312240s  logical
> 
> Let me know if there is any other information I can provide.

Was this disk originally created by a current version of parted? The
assertion isn't actually a bug unless it was parted creating it. It's
telling us that the logical partitions haven't been created with enough
space in front of them (2 sectors) for the extended boot record.

eg. Partition 5 there should start at 976562177

-- 
Brian C. Lane (PST8PDT)

Message #19 received at 32666-done <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <phill <at> thesusis.net>
To: Nikolaus Rath <nikolaus <at> rath.org>
Cc: 32666-done <at> debbugs.gnu.org
Subject: Re: bug#32666: fdisk output
Date: Mon, 22 Apr 2019 16:12:48 -0400

Nikolaus Rath writes:

> /dev/sdb6       739131392 739588095    456704   223M 83 Linux
> /dev/sdb7       739588096 773142527  33554432    16G 8e Linux LVM

sdb7 starts in the very next sector after sdb6, so there is no room here
for the EBR.

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

From: Nikolaus Rath <Nikolaus <at> rath.org>
To: Phillip Susi <phill <at> thesusis.net>
Cc: 32666 <at> debbugs.gnu.org
Subject: Re: bug#32666: fdisk output
Date: Wed, 24 Apr 2019 16:08:26 +0100

On Apr 22 2019, Phillip Susi <phill <at> thesusis.net> wrote:
> Nikolaus Rath writes:
>
>> /dev/sdb6       739131392 739588095    456704   223M 83 Linux
>> /dev/sdb7       739588096 773142527  33554432    16G 8e Linux LVM
>
> sdb7 starts in the very next sector after sdb6, so there is no room here
> for the EBR.

...right, but should that really result in a hard crash of the fdisk
program? I think the proper behavior would be to print exactly what you
wrote and exit gracefully :-)


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

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

From: "Brian C. Lane" <bcl <at> redhat.com>
To: Nikolaus Rath <Nikolaus <at> rath.org>
Cc: 32666 <at> debbugs.gnu.org, Phillip Susi <phill <at> thesusis.net>
Subject: Re: bug#32666: fdisk output
Date: Wed, 24 Apr 2019 08:33:38 -0700

On Wed, Apr 24, 2019 at 04:08:26PM +0100, Nikolaus Rath wrote:
> On Apr 22 2019, Phillip Susi <phill <at> thesusis.net> wrote:
> > Nikolaus Rath writes:
> >
> >> /dev/sdb6       739131392 739588095    456704   223M 83 Linux
> >> /dev/sdb7       739588096 773142527  33554432    16G 8e Linux LVM
> >
> > sdb7 starts in the very next sector after sdb6, so there is no room here
> > for the EBR.
> 
> ...right, but should that really result in a hard crash of the fdisk
> program? I think the proper behavior would be to print exactly what you
> wrote and exit gracefully :-)

Given the number of times this has come up it's probably worth looking
into changing the assertion to something more understandable.

-- 
Brian C. Lane (PST8PDT)

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

From: Phillip Susi <phill <at> thesusis.net>
To: "Brian C. Lane" <bcl <at> redhat.com>
Cc: 32666 <at> debbugs.gnu.org, Nikolaus Rath <Nikolaus <at> rath.org>
Subject: Re: bug#32666: fdisk output
Date: Wed, 24 Apr 2019 11:42:47 -0400

Brian C. Lane writes:
> Given the number of times this has come up it's probably worth looking
> into changing the assertion to something more understandable.

I'd rather actually fix it to support having the EBR be located
somewhere else.  I have been meaning to do that for a few years now ;)

Previous Next

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