bug#35306: crash in do_resizepart function

On Wed, Apr 17, 2019 at 01:32:18PM +0200, Jozef Mlich wrote: > Hi, > > I was trying to resize partition in image file and it ended with crash > > /usr/sbin/parted ./rootfs.img resizepart 1 > (gdb) bt full > #0 0x77d79123 in free () from /lib64/libc.so.6 > No symbol table info available.

bug#35306: crash in do_resizepart function

On Tue, Apr 23, 2019 at 01:53:41PM -0400, Phillip Susi wrote: > Can you provide a copy of your partition table so that we can try to > reproduce this? > > Jozef Mlich writes: > > > Hi, > > > > I was trying to resize partition in image file and it ended with crash > > > > /usr/sbin/parted ./rootfs

bug#35306: crash in do_resizepart function

Can you provide a copy of your partition table so that we can try to reproduce this? Jozef Mlich writes: > Hi, > > I was trying to resize partition in image file and it ended with crash > > /usr/sbin/parted ./rootfs.img resizepart 1 > (gdb) bt full > #0 0x77d79123 in free () from /lib64/

bug#35378: bug in parted

Mikhail Kagalenko writes: > Assertion (metadata_length > 0) at ../../../libparted/labels/dos.c:2313 in > function add_logical_part_metadata() failed. This happens because parted requires a space between logical partitions to put the EBR. Some other unknown parittioning tool under unknown circum

bug#34353: GNU Parted 3.2 – A 'loop' as partition table is reported as result from an mkfs.ext4 function

That was meant to be to -done. Phillip Susi writes: > 'loop' is an intentional pseudo disklabel that means there is no > partition table.

bug#34353: GNU Parted 3.2 – A 'loop' as partition table is reported as result from an mkfs.ext4 function

'loop' is an intentional pseudo disklabel that means there is no partition table. Ricky Tigg writes: > Hi. Initial situation: > > (parted) print > Error: /dev/sdc: unrecognised disk label > Model: Kingston DataTraveler 102 (scsi) > Disk /dev/sdc: 8007MB > Sector size (logical/physical): 512B/512B

bug#33389: parted not recognizing partitions in "non-standard" MBRs with valid partition tables

Unfortunately to figure out what went wrong would require examining the partition table, which it appears you have destroyed. If you happened to have saved a copy and can provide it, please do so and we can reopen the bug. Marc Stenson writes: > Hello, > > While parted 2.3 had no issues with wha

bug#33692: Maybe Bug?

Unfortunately, I can not read it since you actually attached an odt file instead of simply copy/paste like you said. If you still have this information, please send it in plain text. Alex Mackay writes: > Hello, > > I was using parted and it told me I found a bug. I wasn't using anything > other

bug#33607: Recovered from partition list loop

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 > adv

bug#33634: Strange behavior from gparted

Closing bug since it is unrelated to parted, and not a bug. Brent W. Baccala writes: > Hi - > > I just using gparted 0.32.0 on Ubuntu Bionic 18.04 to move and resize a > partition. > > Initially, there was a 25 GB partition and a 100 GB partition followed by a > 574 GB partition. The operation

bug#33520: problem with bad drive... any hope?

This doesn't appear to be related to parted. You should check dmesg for more information on why mkfs failed. carl hansen writes: > start reading at the end. > > > GParted 0.32.0 --enable-libparted-dmraid --enable-online-resize > >Libparted 3.2 > >Create Primary Partition #1 (ext4, 3.