Comments

1644 Comments

OK, tests now pass.

Note: in theory we should also check if anything else in the distro depends on any of the updated sonames.

Oh, you built it on the side tag, great. Updated.

ah, shoot, this is a side tag update, so I can't either. Let's see if we can just tag it into the side tag...

This seems to be the problem:

- package freeipa-server-trust-ad-4.9.10-1.fc35.x86_64 requires libsmbconf.so.0(SMBCONF_0)(64bit), but none of the providers can be installed

The samba-client-libs in the update provides libsmbconf.so.0(SMBCONF_0.0.1)(64bit). So either that soname bump needs to be reverted, or freeipa needs to be rebuilt against this version of samba and included in the update.

@ab

This changes library sonames, and it breaks some dependencies. It's hard to tell what, unfortunately, because of the way the test works.

The test starts from a default install of Server - which has libsmbclient, libwbclient, samba-client-libs, and samba-common installed - then installs this update. At that point, all those packages are updated. Then it sets the system up as a FreeIPA server, which includes installing the freeipa-server package group. At that point, all those packages get downgraded to 4.15.7-0.fc35 again. That indicates that something in the freeipa-server package group's dependencies needs rebuilding against the new samba, but I'm not sure what, and there are so many changed sonames in the update it would be pretty tedious to query the requires for every single one; I'm not sure if there's a handy tool to make this easier.

yeah, to be fair, I didn't quite understand the problem properly at first. I thought it was more restricted than it is. You're saying that any time the DHCP server provides a search domain that doesn't wind up in /etc/resolv.conf on the installed system, right?

@imsedgar I don't think that's quite accurate. It does solve the crash, and will work as expected for I think most installs. You only found a fairly specific case where it doesn't behave as intended. It still seems a lot better than the current situation (all netinsts crash), unless I'm missing something.

After digging into it some more I couldn't really figure out what's going on, but the package doesn't seem to anything egregious to make stuff bigger. So I'm just going to bump the disk size used in openQA as I don't really have anything else practical to do here. Will do that and re-run the affected tests.

The openQA failure here is interesting: somehow, with the new grub2 builds (this affects F35, F36 and Rawhide), anaconda's required space calculation changes. We run the affected test with a 10G disk, and with the new grub2, anaconda thinks it needs more than 10G for KDE and GNOME live installs. With older grub2, it thinks 10G is enough space.

I don't know exactly what changed. anaconda thinks it's 700-800M short, so I don't think the change is as simple as "grub2 got that much bigger", because at a quick check none of the packages is close to that size.

I'm going to run a few checks manually and see if I can figure out what's going on.

Note that anaconda's calculation here is completely wrong anyway, but it's still concerning that it thinks 10G is OK before this update but not after it, and I'd like to figure out why that is rather than just bumping the test's disk size or whatever.

OK, we did the stable push, tests are being re-run.

This seems to break openQA server deployment. After the server part proper is complete, when the server gets deployed as a client of itself, it seems to not believe the system is an IPA server:

https://openqa.fedoraproject.org/tests/1288772#step/role_deploy_domain_controller/31

Logs are here.

don't worry about the failed test, it's because openQA decided to re-run a test on this update after a recent reboot, and it was using the older 3.6.0-1.fc36 build not the newer 3.6.0-3.fc36 one.

The openQA failures here are likely because the nss update is pending stable, not yet stable. We can re-run the tests after the stable push.

If I boot with enforcing=0, I get to a desktop as expected. These AVCs are shown by ausearch and the journal:


time->Wed May 25 21:30:13 2022 type=AVC msg=audit(1653528613.466:247): avc: denied { transition } for pid=1417 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-0" ino=8247 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1


time->Wed May 25 21:30:13 2022 type=AVC msg=audit(1653528613.467:248): avc: denied { entrypoint } for pid=1417 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-0" ino=8247 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1

Live images built with this still boot to a login screen. Here's an affected KDE live image: https://openqa.stg.fedoraproject.org/tests/1819100/asset/iso/01819099-Fedora-KDE-Live-x86_64-FEDORA-2022-0feca8b2c9.iso

It's probably been garbage-collected by now. I'll see if the problem persists with the new update and link to the ISO there if so.

As well as whatever CI is catching, openQA automated tests (only run in staging for now, which is why you don't see them on the results tab) show that live images boot to a login screen with this update. They should not, they should boot to a logged-in desktop.

Filed https://github.com/weldr/lorax/pull/1229 to try and claw back most of the lost space in installer images.