On 2 Jul 2021 at 7:35, stan via users wrote:
Date sent: Fri, 2 Jul 2021 07:35:17 -0700
To: users(a)lists.fedoraproject.org
Subject: Re: Questions on creating RPM
Package??
Organization: zohofree
Send reply to: Community support for Fedora
users <users(a)lists.fedoraproject.org>
From: stan via users
<users(a)lists.fedoraproject.org>
Copies to: stan <upaitag(a)zoho.com>
On Fri, 02 Jul 2021 16:30:14 +1000
"Michael D. Setzer II via users" <users(a)lists.fedoraproject.org> 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(a)lists.fedoraproject.org
> From: Samuel Sieb <samuel(a)sieb.net>
> Date sent: Thu, 1 Jul 2021 18:35:01 -0700
> Send reply to: Community support for Fedora
> users <users(a)lists.fedoraproject.org>
>
> > 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.
It was just that it was simple to boot from a cd or
usb with the g4l before.
Adding it to the grub and later the grub2 was also
simple. Just putting the kernel file and
ramdisk.lzma file in /boot and the 40_custom file in
grub directory, and using grub2 to build a new
grub.cfg.
# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply
type the
# menu entries you want to add after this comment. Be careful not to
change
# the 'exec tail' line above.
menuentry G4L {
linux /bz5x12.14 root=/dev/ram0 telnetd=yes
initrd /ramdisk.lzma
}
Then it would just be an option at boot.
In my classroom, even had options that word
restore the windows partitions on machines in
about 10 minutes to image state, and others that
could use udpcast to restore all machines in lab at
once..
First computer was an IBM 1130 with 4K of Ram
and punched cards back in 10th grade.
Thanks for all the info. Was looking for a way to
keep it simple, but looks like having to allow for old
boot process is easiest solution. Users will have to
figure how to do it.
Thanks again.
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure