Re: Questions on creating RPM Package??

[Michael D. Setzer II]

On 2 Jul 2021 at 7:35, stan via users wrote:

Date sent:      	Fri, 2 Jul 2021 07:35:17 -0700
To:             	[e-mail]
Subject:        	Re: Questions on creating RPM 
Package??
Organization:   	zohofree
Send reply to:  	Community support for Fedora 
users 
From:           	stan via users 

Copies to:      	stan
> On Fri, 02 Jul 2021 16:30:14 +1000
> "Michael D. Setzer II via users"  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:             	[e-mail]
> > From:           	Samuel Sieb 
> > Date sent:      	Thu, 1 Jul 2021 18:35:01 -0700
> > Send reply to:  	Community support for Fedora 
> > users
> > > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure