This is a very odd result, but it seems to be a true one: a network install image built with this update fails to boot to the graphical installer environment because X start fails, with keyboard-related errors.
[ 34.291] (EE) Error compiling keymap (server-1) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/server-1.xkm"'
[ 34.291] (EE) XKB: Couldn't compile keymap
[ 34.291] (EE) XKB: Failed to load keymap. Loading default keymap instead.
[ 34.338] (EE) Error compiling keymap (server-1) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/server-1.xkm"'
[ 34.338] (EE) XKB: Couldn't compile keymap
[ 34.338] XKB: Failed to compile keymap
[ 34.338] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[ 34.338] (EE)
Fatal server error:
[ 34.338] (EE) Failed to activate virtual core keyboard: 2(EE)
[ 34.338] (EE)
it's hard to see how the changes in this update cause that, but...somehow they seem to. The failure has repeated 8 times across the two openQA servers, while the same tests run on a later update - FEDORA-2021-f85cec6472 - passed, suggesting this isn't just caused by something else having changed between the last time this test passed and the time this update was tested...
Leaving negative feedback at least till we figure out what's going on.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Aha, looks like this was actually caused by disk space exhaustion. The openQA installer image build test sets the root FS size to 2GiB, and with this update it was completely full and there was no space to write to when X startup reached this stage.
Our Pungi config has used a root FS size of 3GiB for all installer images since F32, so I've updated the openQA test to match that and re-run it. There's no point in openQA expecting things to fit in 2GiB if our official builder doesn't. Still, it does look like this update caused more space to be used up in the installer root FS, which is never a good thing; we may need to identify the extra bits and update the lorax template file trimming stuff to remove them if they're not needed. Will reverse feedback if re-run tests pass.
This update has been submitted for testing by pbrobinson.
This update's test gating status has been changed to 'ignored'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
This is a very odd result, but it seems to be a true one: a network install image built with this update fails to boot to the graphical installer environment because X start fails, with keyboard-related errors.
it's hard to see how the changes in this update cause that, but...somehow they seem to. The failure has repeated 8 times across the two openQA servers, while the same tests run on a later update - FEDORA-2021-f85cec6472 - passed, suggesting this isn't just caused by something else having changed between the last time this test passed and the time this update was tested...
Leaving negative feedback at least till we figure out what's going on.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Example failure: https://openqa.fedoraproject.org/tests/772664 , logs on the "Logs & Assets" tab, the keyboard error is visible in the X log.
Aha, looks like this was actually caused by disk space exhaustion. The openQA installer image build test sets the root FS size to 2GiB, and with this update it was completely full and there was no space to write to when X startup reached this stage.
Our Pungi config has used a root FS size of 3GiB for all installer images since F32, so I've updated the openQA test to match that and re-run it. There's no point in openQA expecting things to fit in 2GiB if our official builder doesn't. Still, it does look like this update caused more space to be used up in the installer root FS, which is never a good thing; we may need to identify the extra bits and update the lorax template file trimming stuff to remove them if they're not needed. Will reverse feedback if re-run tests pass.
Tests passed with 3GiB rootfs size.
@pbrobinson, thx for the updated code. Do You know why this is tagged as a security update? The changelog seems inconspicuous since the last version
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/
Works
This update can be pushed to stable now if the maintainer wishes
Works
This update has been obsoleted by linux-firmware-20210315-119.fc32.