bug#62793: Assertion (max_size > 0) at cs/constraint.c:72 in function ped_constraint_init() failed.

[Brian C. Lane]

On Tue, Apr 11, 2023 at 09:22:11PM +0200, Håkon Johansen wrote:
> Package: parted
> Version: 3.5
> 
> ---------------------------------------
> Assertion (max_size > 0) at cs/constraint.c:72 in function
> ped_constraint_init() failed.
> 
> Aborted (core dumped)
> ---------------------------------------
> Output of: parted /dev/sda unit co print unit s print
> Model: Verbatim STORE N GO (scsi)
> Disk /dev/sda1: 124GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number Start End Size File system Name Flags
> 1 2097kB 42.9GB 42.9GB fat32 primary boot,esp
> 
> Model: Verbatim STORE N GO (scsi)
> Disk /dev/sda: 24166400s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> 
> Number Start End Size File system Name Flags
> 1 4096s 83886079s 83881984s fat32 primary boot,esp
> 
> 
> ------------------------------
> 
> Happened after issuing several commands (last was quit)
> 
> Håkon Johansen

Was this GPT disklabel created with parted? I see a couple things wrong
here. First is the 'Disk /dev/sda1: 124GB' which should not be referring
to a partition, especially when the 2nd print doesn't.

The sector count in the 2nd print is way off. The disk supposedly only
has 24166400s but the ending sector is 83886079s! And in the first print
it claims it has a size of 124GB which is a lot larger than the ~11GiB
the 2nd print claims.

My initial guess is that this disk is reporting inaccurate information
and that's confusing parted. I'd look at the bootup output from dmesg to
see what the kernel saw at boot time, and to check for disk errors in
dmesg/journald output.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart