On Sat, Sep 11, 2021 at 01:11:38AM +1000, Michael D. Setzer II via users wrote:
The G4L kernels require no kernel modules. That is one
the file system will work with any of the kernels with no
changes at all. Just build new kernel, and copy it to the
boot directly ad change the lines in the syslinux.cfg to
match the latest kernel. Don't have to make any changes.
So, that makes sense, and if this is a heavily customized,
boot-from-ram system, then it would work fine with all the drivers
compiled into the kernel and not as modules, although it would make
the kernel rather large.
After doing a dnf update on the build machine, have a
simple script that automatically copies any new program
files and libraries that were updated.
Wait, I'm confused, now you are talking about dnf, I thought this was
an all-in-one initrd system, what is using dnf?
The kernels have the EFI option in the .config file, so the
kernels should be able to be loaded via the EFI process
somehow, but so far I haven't gotten it to work. Maybe I'll
eventual figure it out, or maybe not. Like I've said,
Clonzilla went with booting a distribution that supported
UEFI, and then added there stuff to that. Could do the
same, but it requires a lot more steps then simple booting
from a CD or USB...
Where are you putting these kernels on the EFI volume?
For example, if you have the msdos-formatted volume mounted as
/boot/efi, the EFI firmware looks for this:
/boot/efi/EFI/BOOT/BOOTX64.EFI
... by default. You can make that be your kernel, a GRUB2 EFI
executable or the shimx64.efi, which is what Fedora systems uses. The
shimx64.efi executable is a signed UEFI executable that launches
GRUB2. But if you want to disable Secure Boot, you could just put it
in EFI/BOOT/BOOTX64.EFI and it should detect it by default.
Seen some post on Windows 11 hardware requirements,
and it might soon make only secure boot a requirement
for anyone.
The UEFI spec says that on x86_64 systems you should be able to
disable secure boot. Dell most likely has that option, because they
have a lot of customers who need it. (for example, if you use nvidia
and CUDA, you'll need to disable secure boot or manually install your
own signing keys)
Just seems there should be a way to get it to
work, but I'm retired and gives me something to play
with. I don't have any machines that require UEFI boot.
Perhaps I should setup a system with UEFI, and see if the
40_custome option works. I do know that a UEFI boot
system will fail to install memtest.
libvirtd lets you set up UEFI VMs, even on systems that don't have
UEFI boot, which is something I have. In virt-manager, just click to
configure the VM before starting the install, and go over into
Overview, you can change the Firmware from BIOS to UEFI. I believe
there's a secboot firmware option, even, although I've not tested it.
Then you can test to your heart's content.
--
Jonathan Billings <billings(a)negate.org>