Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1886149
Summary: | ostree exited with code 1 during armhfp disk creation | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> | ||||||||
Component: | ostree | Assignee: | Jonathan Lebon <jlebon> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 33 | CC: | awilliam, dustymabe, jlebon, jonathan, miabbott, pbrobinson, robertthomasfairley, travier, walters | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | armhfp | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | AcceptedFreezeException | ||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2020-10-10 09:37:25 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: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 1269538, 1766778 | ||||||||||
Attachments: |
|
Description
Paul Whalen
2020-10-07 18:40:06 UTC
Created attachment 1719820 [details]
syslog
Created attachment 1719821 [details]
program.log
Created attachment 1719822 [details]
anaconda.log
It's possible the leak plugged in https://github.com/ostreedev/ostree/pull/2211 isn't the main cause of exhaustion. Would be helpful to have: - the number of dtbs is the OSTree - whether `ulimit -n` is lower on armhfp Proposing as a Freeze Exception for F33 final, it would be great to have this fixed and to include armhfp iot disk images in the release. Fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2020-6cfe7b5633. As usual, the Bodhi UI doesn't want to let me attach this RHBZ to the update for some reason. FEDORA-2020-6cfe7b5633 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6cfe7b5633 I've seen that on occasion too, FYI you can add it using the cli like "bodhi updates edit --bugs 1886149 FEDORA-2020-6cfe7b5633" We pulled this in to today's compose but hit the same error. Koji task - https://koji.fedoraproject.org/koji/taskinfo?taskID=52985114 Error visible in - https://kojipkgs.fedoraproject.org//work/tasks/5114/52985114/oz-armhfp.log Are we 100% sure that the OSTree in Anaconda isn't an older one? Last time this came up my conclusion was that must've been the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1880499#c17. In the logs you posted, you can see ImageFactory fetching the boot artifacts from https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Everything/armhfp/os: Starting new HTTPS connection (1): kojipkgs.fedoraproject.org:443 https://kojipkgs.fedoraproject.org:443 "HEAD /compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/vmlinuz HTTP/1.1" 200 0 Fetching the original install media from https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/vmlinuz Starting new HTTPS connection (1): kojipkgs.fedoraproject.org:443 https://kojipkgs.fedoraproject.org:443 "GET /compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/vmlinuz HTTP/1.1" 200 8610304 8408kB of 8408kB Fetching the original media Starting new HTTPS connection (1): kojipkgs.fedoraproject.org:443 https://kojipkgs.fedoraproject.org:443 "HEAD /compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/initrd.img HTTP/1.1" 200 0 Fetching the original install media from https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/initrd.img Starting new HTTPS connection (1): kojipkgs.fedoraproject.org:443 https://kojipkgs.fedoraproject.org:443 "GET /compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/images/pxeboot/initrd.img HTTP/1.1" 200 62144616 And looking in https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Everything/armhfp/os/Packages/o/, I see ostree-2020.6-4.fc33.armv7hl.rpm and not -5 (which is in https://bodhi.fedoraproject.org/updates/FEDORA-2020-6cfe7b5633). Does that compose get updated daily? How can we make sure that the new ostree makes it there? (In reply to Jonathan Lebon from comment #10) > Are we 100% sure that the OSTree in Anaconda isn't an older one? Last time > this came up my conclusion was that must've been the issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1880499#c17. Yep, that could be the problem +4 in the ticket, marking accepted FE. FEDORA-2020-6cfe7b5633 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6cfe7b5633` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6cfe7b5633 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Jonathan Lebon from comment #10) > Are we 100% sure that the OSTree in Anaconda isn't an older one? Last time > this came up my conclusion was that must've been the issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1880499#c17. Confirmed this works on rawhide once we had a successful mainline compose! FEDORA-2020-6cfe7b5633 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. The update wasn't marked to close the bug when it went stable, apparently. Does this still need to be open or can we close it now the update went stable? (In reply to Adam Williamson from comment #16) > The update wasn't marked to close the bug when it went stable, apparently. > Does this still need to be open or can we close it now the update went > stable? I edited the bodhi update using the cli and probably missed an option |