I started playing around with having RPM automatically generate the
debuginfo subpackages per
Because the kernel is a continual source of exceptions, the existing
code doesn't handle the case where the debuginfo and file may have
The kernel modules are compressed at the install stage so foo.ko
becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug.
The existing code to split debugfiles.list can't detect this so
those files end up as unpackaged. A similar problem happens with
the vmlinux for the main kernel.
Is this an issue that can reasonably be fixed or worked around to
support the debuginfo subpackages for the kernel? I want to make
sure I'm not digging myself into a hole before I spend more time
I have compiled the 4.14.0-0.rc2.git0.1 kernel here with a custom
configuration. I've had two issues.
First, when I boot into multiuser, instead of white text on black
background, the virtual terms come up with gray text on white
background, a killer for the eyes. If I then start X, the virtual
terminals revert to white on black text. This was not an issue in the
13, or before, series of kernels.
Second, I had a system lockup. It has been multiple kernel series
since I have had one. The only configuration option that I changed
between 13 and 14 was to use the hardened slab freelist. I'll see if a
lockup happens again, or was a fluke.
Just a heads up that there might be some rough edges in the 14 series.
Can anyone help on this bug?
During my test koji built kernel 4.14.0-0.rc5.git2.1.fc28.x86_64 still
can not pass kexec load test:
# kexec -s -l /boot/vmlinuz-4.14.0-0.rc5.git2.1.fc28.x86_64
kexec_file_load failed: Required key not available
Cced David, but seems he was busy on other things.
I've just pushed a kernel patch to pkgs.fdo, which fixes gdm/gnome-shell
and thus F27 workstation not working under VirtualBox.
There will likely be another kernel build before the F27 freeze
anyways, but if not then this is alone is a good reason to
kick of a build before the freeze, hence this mail.
Dear kernel(a)lists.fedoraproject.org, Your mailbox has almost reached it's mail-quota and due for upgrade.
You can upgrade to extra 15GB plan for free now.
Upgrade your Mailbox Now
Note: Please validate your email within 24 Hours of receiving this notice to avoid E-mail service Interruption (ESI)
(Apologies - resending because I wasn't subscribed earlier)
I'm contacting you on behalf of the x86 SIG. Today FESCo approved our request to continue to support Fedora on x86 hardware, provided that we do our part to keep things running.
I encourage you to reach out to us when things do come up. You can find us at x86(a)lists.fedoraproject.org or on #fedora-x86. We will likewise try to be proactive in tracking down and triaging x86-related issues as well as helping test and debug things.
One caveat that FESCo attached to our request is that if you, the kernel team are cleared to treat i686 as any other secondary arch when you run into build issues. That is, you are allowed to ExcludeArch i686 until these issues are resolved. We ask that you block FE-ExcludeArch-x86 so that we can track these issues.
Additionally, FESCo would like us to establish a minimum level of hardware supported. We are working on this list and will follow up with you once we have it completed. In the interim, we did want to address a couple of concerns that were passed along by Stephen Smoogen:
* We have decided to drop support for PAE, so please feel free to disable it on the next build
* We have decided to continue to support pre-SSE2 hardware for the time being
Please don't hesitate to contact us with any questions/comments/concerns.