Description of problem: When attempting to build an armhfp disk image in F33 iot, the installation fails: ... Preparing deployment of fedora/devel/armhfp/iot Deployment starting: fedora/devel/armhfp/iot ================================================================================ ================================================================================ The following error occurred while installing. This is a fatal error and installation will be aborted. ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-iot', 'fedora-iot:fedora/devel/armhfp/iot'] exited with code 1 Checking the logs: 00:12:22,880 INF program: Relabeling /var (no stamp file 'var/.ostree-selabeled' found) 00:12:22,887 INF program: error: Installing kernel: openat(imx6dl-yapp4-hydra.dtb): Too many open files 00:12:22,888 DBG program: Return code: 1 Version-Release number of selected component (if applicable): ostree-2020.6-4.fc33 How reproducible: Everytime. Koji task - https://koji.fedoraproject.org/koji/taskinfo?taskID=52936648
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