fedora-qa / relval

#27 size-check doesn't check the uncompressed size of disk images
Opened by kparal. Modified

Open
Close Issue

Relval automatically checks sizes of deliverables and reports bugs when they are oversize. But it looks like this correctly works just for ISO images. For compressed disk images (raw.xz), it should check the size of the uncompressed disk image, because that's what needs to fit to the target medium (an SD card, most commonly).

In the F39 cycle, some disk images went oversize and we didn't receive a bug report from relval. See https://bugzilla.redhat.com/show_bug.cgi?id=2247611 .

But I don't know if we can detect the uncompressed size without a direct access to the file. It looks like relval would have to download it first.

$ xz -l Fedora-Minimal-39-1.5.aarch64.raw.xz 
Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
    1     256    761,7 MiB  6 144,0 MiB  0,124  CRC64   Fedora-Minimal-39-1.5.aarch64.raw.xz
# try to get this info from just the file header
$ dd if=Fedora-Minimal-39-1.5.aarch64.raw.xz of=test.xz bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,00276787 s, 379 MB/s
$ xz -l test.xz 
xz: test.xz: Compressed data is corrupt
$ xz --ignore-check -l test.xz 
xz: test.xz: Compressed data is corrupt

From man xz:

  -l, --list
         Print  information about compressed files.  No uncompressed output is produced, and no files are cre‐
         ated or removed.  In list mode, the program cannot read the compressed data from  standard  input  or
         from other unseekable sources.

well, note the test case says:

"This test does not apply to disk image files (e.g. ARM and Cloud disk images): their compressed size is not relevant to their deployment, and restrictions on their uncompressed size are applied during the compose process."

the criterion only says "The release-blocking images must meet current size requirements."

So things are rather unclear here. Note the reference to "restrictions...during the compose process": this is, AIUI, referring to the disk_size property we set for disk image builds in the Pungi config, e.g. here we set a disk_size of 16 for the Workstation image. That appears to be in power-of-two gigabytes, which is why we wind up with a 17179869184 byte image.

I guess we've been bumping that size whenever an image fails to compose, and not really treating it as a release-blocking issue, like that text implies we should. e.g. it was bumped from 15 to 16 in commit 8b2c85799cce5c096484cdebe1dbe521eaf7fe92 .

possibly what we need here is comments in the pungi config alongside disk_size values for release-blocking images, saying if those sizes go higher than the ones specified in the blocking image list, that's a problem? @kevin wdyt?

Yeah, the one thing I worry about is say when a blocking image hits the size limit on a compose on a friday and there's no easy win on reducing it, we can't bump the limit until the right folks agree, which means we have no rawhide composes for many days. ;(

We could avoid that by just allowing rawhide to bump up, but then check when we branch? but then it's more things we have to hurry and do at branching time which is already really busy.

Or we just allow bumping, but require a answer on the increase after?

yeah, I was thinking along the lines of "you have to file a blocker bug if you have to bump the size past the limit".

Sure, that could be workable.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/relval/issues/27

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.