The previous commit fixed a lot of the test, but the '64bit cloud' and
'aarch64 cloud' tests still fail, there is no login prompt on the tty.
Also, make sure that the autovt@.service symlink is in -udev subpackage.
OpenQA still fails. Now we get a graphical console on tty1 when the
needles expect a text login. And in other cases we get nothing, when
the tests expect a text login. Let's just manually recreate the
previous state. When kmsconvt@.service has an [Install] section with
Alias= and DefaultInstance=, then 'systemctl enable kmsconvt@' creates
the enablement symlinks as expected, hiding our symlink in
/usr/lib/systemd/, so we could proceed with the changes in kmscon if
systemd passes the tests.
1. Revert "Stop enabling getty@tty1.service"
This reverts commit e301db0151.
My assessment was wrong. We *did* create the symlink, probably through
the preset-all call. Also, this change didn't cause any change to the
OpenQA results.
2. Move the autovt@.service symlink to /usr/lib/ to make an
Lorax/Anaconda hack work again. If this works, kmscon will need to do
the same thing.
Before the recent changes to fix scriptlets and do presets, we didn't
create this symlink, so let's drop it again to see if this fixes the
OpenQA failures.
One level of escaping was consumed by rpm, one level was consumed by
the shell, we need one more for systemd. I saw the failure previously,
but didn't consider it important because we didn't need to do anything
for the affected units. But it turns out that the whole operation
failed, so we weren't presetting any of the units. This caused
getty@.service to not be enabled, even though presets specified that
it should. This code is being more robust in
https://github.com/systemd/systemd/pull/40504, but adding one more
level of escaping should resolve the issue too.
We want getty@.service to be enabled through presets, so that the
autovt@.service alias is created (or not). See
https://fedoraproject.org/wiki/Changes/UseKmsconVTConsole.
getty@.service was changed upstream to have a full [Install] section,
but we need to handle installation of the unit here. This will now
create the autovt@.service alias when enabled.
While looking at this, I noticed that the getty units are in the main
package. They don't have to be, virtual terminals are only available
if we have "hardware", i.e. the -udev subpackage is appropriate.
Same for the tpm2 stuff.
List of affected files:
/etc/systemd/system/getty.target.wants
/usr/lib/systemd/system-generators/systemd-getty-generator
/usr/lib/systemd/system-generators/systemd-tpm2-generator
/usr/lib/systemd/system/console-getty.service
/usr/lib/systemd/system/container-getty@.service
/usr/lib/systemd/system/getty-pre.target
/usr/lib/systemd/system/getty.target
/usr/lib/systemd/system/getty@.service
/usr/lib/systemd/system/multi-user.target.wants/getty.target
/usr/lib/systemd/system/serial-getty@.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-tpm2-setup-early.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-tpm2-setup.service
/usr/lib/systemd/system/systemd-tpm2-clear.service
/usr/lib/systemd/system/systemd-tpm2-setup-early.service
/usr/lib/systemd/system/systemd-tpm2-setup.service
/usr/lib/systemd/system/tpm2.target
/usr/lib/systemd/systemd-tpm2-clear
/usr/lib/systemd/systemd-tpm2-setup
/usr/share/man/man8/systemd-getty-generator.8.gz
/usr/share/man/man8/systemd-tpm2-clear.service.8.gz
/usr/share/man/man8/systemd-tpm2-generator.8.gz
/usr/share/man/man8/systemd-tpm2-setup-early.service.8.gz
/usr/share/man/man8/systemd-tpm2-setup.8.gz
/usr/share/man/man8/systemd-tpm2-setup.service.8.gz
I considered leaving getty.target in the main package, so that
foreign units that refer to it don't generate a warning about missing
units, but I think that those packages should not be installed on
systems without systemd-udev, so it's fine if the warning appears.
This reverts commit 56377438ba. Dropping
of the option currently doesn't disable anything, it just moves the
file. I don't think we gain anything by moving the file and actually
this causes problems [1], so let's just return to status quo ante.
[1] file /etc/init.d conflicts between attempted installs of systemd-259.999+69+g6ceb76bfc-2548.1.x86_64 and chkconfig-1.33-3.fc44.x86_64
[skip changelog]
Neither dbus nor pam are required in the initrd so
let's make both recommended dependencies instead
of required dependencies so that we can build
initrds without either of them getting pulled in.
The shell expansion we use to determine the top-level directory will
get expanded even if we don't execute %prep, so add a %_build_in_place
check to make sure we don't try to search for the top-level directory
if --build-in-place is set.
Upstream is moving towards making a lot more libraries dlopen() style
dependencies. Let's make sure to add these as Requires to corresponding
packages so they still get pulled in.
2ace9416e8 broke packit as the fallback
url wasn't listed first anymore. Make sure the fallback URL is listed
first again as clearly documented just above the conditionals.
systemd-networkd-resolve-hook.socket will be introduced by
https://github.com/systemd/systemd/pull/39293 but we need the spec
to handle the socket for the upgrade/downgrade test to pass so adding
it early behind the upstream bcond.
