On Fri, 02 Jul 2021 16:30:14 +1000 "Michael D. Setzer II via users" <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Thanks for the reply. Comments below > > On 1 Jul 2021 at 18:35, Samuel Sieb wrote: > > Subject: Re: Questions on creating RPM > Package?? > To: users@xxxxxxxxxxxxxxxxxxxxxxx > From: Samuel Sieb <samuel@xxxxxxxx> > Date sent: Thu, 1 Jul 2021 18:35:01 -0700 > Send reply to: Community support for Fedora > users <users@xxxxxxxxxxxxxxxxxxxxxxx> > > > On 2021-06-28 3:39 p.m., Michael D. Setzer II via users wrote: > > > That would then add options to the grub boot menu > > > similar to how memtest worked to add option. It > > > would load kernel image, and then g4l in ram to > > > run. Looked at memtest, but note that they don't > > > have an option with the EFI version, which was my > > > new question with shift to more systems using that? > > > Issues with creating signed kernels? > > > > I think memtest just didn't work with EFI at all, but there is also > > the more general problem of secure boot. You have to sign the > > kernel you use with a recognized key. Is it a special kernel or > > can you use the default Fedora kernel? > > > > I've seen a page where memtest talked about the > problems they had with having to build special > kernels, and then issues with then having to get > new signed kernels every time they changed > anything, and thus decided it wasn't worth it? > I have memtest included with my g4l project. > > It uses a kernel that is built from the source code of > kernel.org to include most disk and network > support to handle various hardware. If you want to use a signed kernel, your public key has to be in the UEFI key repository in order to use your kernel. That is, just like Fedora does, you would need to add your public key to that repository. Once it is added, you could sign all your newer kernels with the same private key, and the public key would work for all of them. The trouble is that people might not want to add a third party key to their EFI key repository, because it has security implications. > Have actually looked at trying to use the fedora live > cd, but that is like a 2G file. It has most of the > support files, but would require adding a number of > little things and the primary script?? Haven't actual > tested it. Project uses busybox for much of the > support, but this would be using Fedora files > completely. Yes, using a Fedora kernel will work, because the public key of the private key it is signed with is already in the EFI key repository. It has to be a stock kernel as you have no access to the private key that Fedora uses to sign their kernels, so you cannot sign any kernel builds you do with that key. > Recently had a machine with the EFI setup, and > wanted to run memtest on it, and couldn't. Ended > up using my g4l boot flash and just had to change > bios to allow the regular bios boot, but don't know if > uses want to do that? I think this is the way to go. If they are using your recovery program, they have already agreed that your kernel is secure. Turning off secure boot to use it introduces no new security risk. I'm assuming that they get it from the official Fedora repositories, so it has been signed, and thus can be taken as unaltered. I have personal instructions on how to create a public/private key pair, put them in the proper places, and sign a kernel. I have posted them to the devel list in the past, and could post them here if you want. But, my recommendation is to go with the unsigned kernel requiring secure boot to be turned off to boot it. And second would be to use a Fedora signed kernel. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
