Bug 2049500
| Summary: | osbuild fails to add a custom partition | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Christophe Besson <cbesson> |
| Component: | osbuild-composer | Assignee: | Image Builder team <osbuilders> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.5 | CC: | atodorov, ckellner, jabia, jrusz, obudai, sbarcomb |
| Target Milestone: | rc | Keywords: | Reproducer |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | osbuild-composer-46-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-10 13:49:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The code for the file system partitioning customisation needs some fixing to cover some special cases. I am in the processes for restructuring it and will fix this in the process! Fixed in osbuild-composer 46. I was able to reproduce the bug according to the description. I tested it in RHEL-8.6.0-20220305.2 with osbuild-composer.x86_64 46-1.el8 and osbuild.noarch 50-1.el8 and it is fixed. So moving it to VERIFIED status. (In reply to Juan Abia from comment #7) > I was able to reproduce the bug according to the description. I tested it in > RHEL-8.6.0-20220305.2 with osbuild-composer.x86_64 46-1.el8 and > osbuild.noarch 50-1.el8 and it is fixed. So moving it to VERIFIED status. @Juan, how exactly have you tested that b/c the proposed test automation script fails on 8.6, see ? https://github.com/osbuild/osbuild-composer/pull/2412 I am moving the status back to ON_QA until we figure out why there's a failure in CI. > @Juan,
> how exactly have you tested that b/c the proposed test automation script
> fails on 8.6, see ?
> https://github.com/osbuild/osbuild-composer/pull/2412
Steps done to verify the bug:
- reserve beaker machine with the compose specified before
- install osbuild-composer and composer-cli
- Create osbuild-composer repo overdrive so BaseOS and AppStream repos point to nightly rpms
- Create base blueprint and add the customization described in the first comment
- Start compose, and wait for it to finish.
Before I tried with osbuild-composer 46, I checked the bug was present on version 33. But I got a different output from what you are getting in the PR. Also, the compose in my case failed almost instantly, while the one on your PR takes some time.
I'm not certain but I'd say you are getting a different problem than this bug.
(In reply to Juan Abia from comment #9) > > @Juan, > > how exactly have you tested that b/c the proposed test automation script > > fails on 8.6, see ? > > https://github.com/osbuild/osbuild-composer/pull/2412 > > Steps done to verify the bug: > > - reserve beaker machine with the compose specified before > - install osbuild-composer and composer-cli > - Create osbuild-composer repo overdrive so BaseOS and AppStream repos > point to nightly rpms > - Create base blueprint and add the customization described in the first > comment > - Start compose, and wait for it to finish. > > > Before I tried with osbuild-composer 46, I checked the bug was present on > version 33. But I got a different output from what you are getting in the > PR. Also, the compose in my case failed almost instantly, while the one on > your PR takes some time. > OK, sounds legit. Moving back to VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (osbuild-composer bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:1841 |
Description of problem: Customer added a /data in his blueprint, but it fails during the compose. It seems osbuild didn't compute properly the start sector of this additional partition. Version-Release number of selected component (if applicable): osbuild-35-3 osbuild-composer-33.2-1 How reproducible: Always Steps to Reproduce: Add the following customization to your blueprint: [[customizations.filesystem]] mountpoint = "/data" size = 2147483648 Actual results: Stage: image:1-org.osbuild.sfdisk null Output: [/usr/lib/tmpfiles.d/journal-nocow.conf:26] Failed to resolve specifier: uninitialized /etc detected, skipping All rules containing unresolvable specifiers will be skipped. Failed to create file /sys/fs/selinux/checkreqprot: Read-only file system label: gpt label-id: D209C89E-EA5E-4FBD-B161-B461CCE297E0 start="2048", size="2048", type="21686148-6449-6E6F-744E-656564454649", uuid="FAC7F1FB-3E8D-4137-A512-961DE09A5549", bootable start="2101248", size="18446744073709547420", type="0FC63DAF-8483-4772-8E79-3D69D8477DE4", uuid="6264D520-3FB9-423F-8AB8-7A0A8E3D3562" start="4096", size="2097152", type="0FC63DAF-8483-4772-8E79-3D69D8477DE4", uuid="6d3677ee-1365-4202-969f-c7aade4cdd54" Sector 2101248 already used. Failed to add #2 partition: Numerical result out of range Traceback (most recent call last): File "/run/osbuild/bin/org.osbuild.sfdisk", line 203, in <module> ret = main(args["devices"], args["options"]) File "/run/osbuild/bin/org.osbuild.sfdisk", line 194, in main pt.write_to(device) File "/run/osbuild/bin/org.osbuild.sfdisk", line 151, in write_to check=True) File "/usr/lib64/python3.6/subprocess.py", line 438, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['sfdisk', '-q', '--no-tell-kernel', '/dev/loop0']' returned non-zero exit status 1. Expected results: label: gpt label-id: D209C89E-EA5E-4FBD-B161-B461CCE297E0 start="2048", size="2048", type="21686148-6449-6E6F-744E-656564454649", uuid="FAC7F1FB-3E8D-4137-A512-961DE09A5549", bootable start="4198400", size="12578716", type="0FC63DAF-8483-4772-8E79-3D69D8477DE4", uuid="6264D520-3FB9-423F-8AB8-7A0A8E3D3562" start="4096", size="4194304", type="0FC63DAF-8483-4772-8E79-3D69D8477DE4", uuid="18648a65-54e3-4592-82f6-f9f69acdc254" { "partitiontable": { "label": "gpt", "id": "D209C89E-EA5E-4FBD-B161-B461CCE297E0", "device": "/dev/loop0", "unit": "sectors", "firstlba": 2048, "lastlba": 16777182, "partitions": [ {"node": "/dev/loop0p1", "start": 2048, "size": 2048, "type": "21686148-6449-6E6F-744E-656564454649", "uuid": "FAC7F1FB-3E8D-4137-A512-961DE09A5549"}, {"node": "/dev/loop0p2", "start": 4198400, "size": 12578716, "type": "0FC63DAF-8483-4772-8E79-3D69D8477DE4", "uuid": "6264D520-3FB9-423F-8AB8-7A0A8E3D3562"}, {"node": "/dev/loop0p3", "start": 4096, "size": 4194304, "type": "0FC63DAF-8483-4772-8E79-3D69D8477DE4", "uuid": "18648A65-54E3-4592-82F6-F9F69ACDC254"} ] } } Additional info: * Note I changed several times the size, as I didn't know if it was in kB, MB or in sector size... So the above outputs are likely inaccurate. * From `man sfdisk` we have the below output from the "name-field input" section, but it's not documented in the osbuild documentation (upstream or downstream). size=number Specify the partition size in sectors. The number may be followed by the multiplicative suffixes (KiB, MiB, GiB, TiB, PiB, EiB, ZiB and YiB), then it's interpreted as size in bytes and the size is aligned according to device I/O limits. * Defining explicitly the size of the rootfs in another customization.filesystem section fixed the issue on my side. * rpm -qf /usr/lib/osbuild/stages/org.osbuild.sfdisk osbuild-35-3.el8.noarch