Am 08.10.22 um 16:24 schrieb Leon Fauster:
> Hey folks, I wonder if anyone also suffers from the following:
>
> I updated the BIOS/Firmware of a DELL notebook from 1.8 to 1.9. and
> after this the latest C9S
>
> kernel-5.14.0-171.el9.x86_64
>
> can't be booted anymore (secure boot on) but the two older ones do boot:
>
> kernel-5.14.0-165.el9.x86_64
> kernel-5.14.0-168.el9.x86_64
>
> The grub error message when trying to boot kernel-5.14.0-171.el9.x86_64
> looks like:
>
> error: ../../grub-core/kern/efi/sb.c:183:bad shim signature.
> error: ../../grub-core/loader/i386/efi/linux.c:259:you need to load the
> kernel first.
>
> I wonder how this happens. The firmware is classified as bug-fix update.
>
> Not sure if DBX list was update. fwupdmgr shows "Current version: 83"
> If so, it does not make sense that older kernels can be used to boot the
> system. So, a big question mark how to solve this issue? Any hints ...?
>
>
> # sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI
> 3ae459e79408b5287ce70c5b86ddcc92c243c7442d6769a330390598b7a351b1
> /boot/efi/EFI/BOOT/BOOTX64.EFI
>
It seems that the kernel-5.14.0 of the release 17X-series
do not get signed with the CentOS key anymore!
https://bugzilla.redhat.com/show_bug.cgi?id=2138019
TLDR:
/boot/vmlinuz-5.14.0-16*
versus
/boot/vmlinuz-5.14.0-17*
shows
The signer's common name is CentOS Secure Boot Signing 201
versus
The signer's common name is Red Hat Test Certificate
Is this issue already receiving the right attention?
--
Thanks
Leon
Hi all,
The CentOS Board is looking at renaming Dojos, our series of free mini-
conferences. Please give your input on this Discussion post:
https://discussion.fedoraproject.org/t/renaming-centos-dojos/43351
Note that Fedora and CentOS share an accounts system, so if you have a
CentOS account, you already have a login for Fedora Discussion.
Thanks,
Shaun
Hi all,
I've uploaded the recordings of last week's board meeting:
https://youtu.be/FA0ddn-IWes
If you'd like to discuss any issues with the board, we'll have an open
board office hours this Thursday, October 20, at 14:00 UTC:
https://us06web.zoom.us/j/87623425120
Thanks,
Shaun
When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.
At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it
October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes. They will be in the Fedora archives,
and the mirror managers will point at them.
Question: What will you be dressed as on Halloween?
Answer (Troy): A Penguin
EPEL Steering Committee
[1] - https://pagure.io/epel/issue/198
Gratitude for this e-mail, i'm a software developer, with works C, C++,Lua,
Python
and i hope so much to contribute community
i'm Ramon, and i looking for some experience with linux and software
development
cordially thanks
(I've sent this before, but it seems to have never reached the mailing
list, so re-sending again; although less interesting today, when RHEL 8.7
and 9.1 Beta are already out, yet I believe the thoughts about Stream
concept are worth looking at).
As you likely know, CentOS Stream is a new concept that allows the
community to see what future RHEL brings. Let me touch on a few specific
things that you can test in CentOS Stream 8 and 9 for some time already,
and couldn't see in a released RHEL until recently.
Module streams concept is used in CentOS Stream 8 and 9 (and thus also in
the future RHEL-8.x and RHEL-9.x versions) for delivering alternative
versions of popular stacks for developers (except other components). You
can for example try the latest Node.js version 18, Ruby 3.1, or Maven 3.8.
How? Let's see an example with a CentOS Stream 9 container image:
First, pull the CentOS Stream 9 image using podman and run it:
#> podman pull centos:stream9
#> podman run -ti --rm centos:stream9
Then, use dnf to list available modules
[root@ad0a3f9d2aa3 /]# dnf module list
Here you see a couple of modular streams that are not enabled by default
but are available in the repository in parallel to the default version
(which is 3.0 in the case of Ruby and CentOS Stream 9).
Now, the most important part, enable the latest available version of Ruby
and install some packages:
[root@ad0a3f9d2aa3 /]# dnf -y module enable ruby:3.1
[root@ad0a3f9d2aa3 /]# dnf -y install ruby
And finally, check what version we actually have:
[root@ad0a3f9d2aa3 /]# ruby --version
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
And you can follow a similar pattern for other module streams, that are on
their way to the next RHEL minor release. This way, CentOS Stream and RHEL
users can test the new content earlier than before and provide feedback in
the BZ [2].
[1] https://www.centos.org/centos-stream/
[2]
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20…
Enjoy!
Honza