UEFI boot rejects keyboard/mouse "loading of unsigned module is rejected"

[Agababa]

Using latest Bookworm Pup64, installed to USB FAT32. Laptop is an Inspiron 15 3000 with a UEFI Secure Boot that has Dell SupportAssist tangled in it. I installed using the lightning-beam installer, not the worm one, and I chose to use the "both" option when asked if I wanted UEFI/MBR/etc. This is all on one 1GB FAT32 partition, and the filesystem the SFS uses is ext2. I went through the MOK installer process and added the .cer file (I can't see its name currently since I'm in a car in the dark, but it seemed like a default name like "puppycert.cer").

Puppy boots fine when the Secure Boot is set to Audit Mode, but when it's in regular Deployed Mode, I get errors in boot that my HID TouchPad and keyboard devices aren't being accepted, with the message "loading of unsigned module is rejected" and a 60 second pause after each one. I don't want to mess with my keys in UEFI blindly to risk any real damage, since I had to hunt down my BitLocker keys for Windows after not being careful. What should I do to fix the problem? I could keep using Audit Mode, but I'd prefer not to have to mess with settings every time I want to boot Puppy.

Thank you for your time.

[mikeslr]

Hi Agababa, and to the kennels.

Before we spend a lot of time trying to figure out why lightning-beam installer --like so many other installers-- fails to create a boot-able Puppy USB-Stick, may I suggest that you first try creating one using rufus. https://rufus.ie/en/

Follow the instructions here to deploy a Puppy which will not only boot, but will allow you to save your settings, customizations and user-installed-applications to your USB-Key. https://www.forum.puppylinux.com/viewto ... 522#p40522. Short version of that post: the latest offering by rufus works fine. "6. Under Persistence use the slider to have rufus create a persistent partition of the entire drive less about 2 Gbs."

[bigpup]

This is all on one 1GB FAT32 partition, and the filesystem the SFS uses is ext2. I went through the MOK installer process and added the .cer file

Probably did not correctly run the MOK installer.

The puppy.cer file, if correctly installed, will be with the other keys stored on the computer, and found and used at boot up.

Try running the MOK installer again and carefully use it, making sure to do everything correctly.

----------------------------------------------------------------------------------------

First I have seen anything about lightning-beam installer or worm one,

Got a download or information link to it?

[Agababa]

My apologies for not being clear. I made the initial install by Rufus on Windows, then used the built-in Puppy-installer (lightning bolt, first used Puppy and then Boot buttons) to install to a 2nd USB instead of FrugalPup (worm). I will have to try Rufus with the Persistence setting on, since I had it off before and it never saved my settings, only my video resolution. Will I still have to run Puppy-installer afterward to make it start the MOK process, or will it trigger without needing a second install?

[mikeslr]

Hi again, Agababa.

Ah, " lightning-beam installer" = built-in Puppy Installer. Sorry I can't help you using it to solve the MOK issue. I'm a creature of habit and haven't used Frugalpup-Installer (one of the modules Puppy Installer offers) for a couple of years. Almost the first thing I do is install grub2config, https://www.forum.puppylinux.com/viewto ... 703#p29703.

In creating grub2config, shinobar built on the work pioneered by gyrog, the developer of Frugalpup-installer. But unless my sometimes flaky memory is playing tricks, shinobar approached the problems users encounter from a different angle. grub2config requires the user to manually deploy the operating system files but automates the deployment of MOK (developed by gyrog); while frugalpup only requires a user to select the desired operating system but apparently doesn't (alway?) handle MOK automatically.

I've discussed using grub2config in detail here, https://www.forum.puppylinux.com/viewtopic.php?t=375. But basically, that is almost identical to how Puppys were deployed before they had to contend with UEFI [and I AM a creature of habit]:

(a) If necessary, format the storage medium to provide a small Fat32 boot partition, flagged as boot, and a (preferably) Linux Formatted to hold the operating system;
(b) Optionally create a named folder on the partition which will hold the operating system;
(c) If necessary mount the ISO to provide access to the system files;
(d) Copy the system files into the (folder on the) storage partition;
(e) Run grub2config.
Bookworm's system files consist of: initrd.gz, vmlinuz, all files ending with ".sfs", puppy.cer, and perhaps kbuild... and ucode.cpio. [Not sure of the purpose of the latter two]. I think the puppy.cer file is what UEFI looks for; i.e MOK. Other than wasting a little space, no harm results from copying the entire contents of the ISO.

Frugalpup may be able to handle some situations which grub2config can't. But I've never personally had, nor read about, such occasion, other than the one specifically mentioned on the grub2config thread: "Only one case the Grub2config does not support:
When you clean install Ubuntu Linux and/or derivatives on a legacy BIOS PC, the partition sda1 is ext4 formatted".

I'll leave it to bigpup and others who use frugalpup to guide your use of it.

[dimkr]

The kernel and the drivers are not signed, you'll need to disable secure boot.

[Agababa]

The kernel and the drivers are not signed, you'll need to disable secure boot.

Is this only the case for Bookworm Pup64, or will this be necessary across all Puppy versions?

[mikeslr]

Someone can correct me if I'm wrong. But as far as I know that will be necessary using any Puppy.

But keep this in mind. Despite its name, 'Secure boot" has little to do with security. At the computer convention immediately after MicroSoft insisted that computer manufacturers desiring to market computers with Windows installed --and 80+ percent of the pc market runs Windows-- "White hats" demonstrated that the entire UEFI mechanism could be circumvented by hackers in about 15 minutes. And once the circumvention technique was developed it could be used against any computer employing UEFI. In other words, UEFI is less secure than having a variety of boot mechanism so that each computer presents an individual challenge to hackers.

The main reason MicroSoft insisted upon UEFI was to make it more difficult for a computer owner to use anything other than Windows. A secondary objective at the time was to transition from a Long-term-lease of an operating system model to a short-term rental where, in order for your system to continue to perform, you'd have to purchase new components from Microsoft.

UEFI is the 'Emperor's New Cloths'. We're just stuck with having to deal with it. A properly deployed Puppy is almost entirely immune to malware. Ask how.

[rcrsn51]

You are conflating UEFI with Secure Boot.

The Starter Kit has discussions about UEFI and Secure Boot.