KLV-Airedale-beta+ Released, Ready for Download

[ozsouth]

I made a 5.10.109 64bit kernel today with everything in the nvme section enabled. See kernels section of forum.

[Ramachandra Iyer]

I made a 5.10.109 64bit kernel today with everything in the nvme section enabled. See kernels section of forum.

Thank you Sir. I will let you now the status.

[wiak]

No joy using WDL initrd (as in KLV-Airedale) with nvme drive as yet. Did a big test using weedogit frugal install of Zorin lite XFCE since the same machine runs that OS as a full install without issue and I noted the nvme modules were available. I thus moddied WDL initrd to modprobe all the nvme modules I could see and put lots of debug statements in my initrd/init run. Main results were as follows:

mount command in initrd/init said:

/dev/nvme0n1p5 on /mnt/nvme0n1p5 type ext4 (rw, relative)

i.e. init managed to mount it. Also busybox findfs command correctly found that nvme0n1p5 partition I am using from the associated given UUID.

But...

Straight after that mount command, I tried an ls command to see the contents of the mount, but got the following:

ls: can't open '/mnt/nvme0n1p5': Value too large for defined data type

I have been through this before, but googled and found one discussion related to same error on a docker thread that was suggesting busybox with uclibc was causing the problem because it uses 32bits for inode numbers and 64bit inode numbers were overflowing it. Work around given on that discussion was to use a busybox compiled with glibc instead. I haven't tried that yet (haven't got such and haven't compiled one...). Maybe the problem is something else of course. I'll also look into TerryH suggestion later but late here now so will have to wait.

https://bugs.busybox.net/show_bug.cgi?id=11651

[wiak]

SUCCESS.

Posting from weedogit Zorin frugal install (put onto my HP nvme drive partition) now.

As well as modprobing nvme in the WDL initrd/init the main problem was indeed (per my immediately above post) the busybox uclibc static version being used. I changed to this one:

https://www.busybox.net/downloads/binar ... sl/busybox

and boots fine to the nvme drive now.

If Puppy has similar issues (or any Dog) then I expect that busybox needs changed (or compiled) similarly.
I'll modify WDL initrd soonish such that KLV-Airedale will boot from nvme with appropriate nvme-enabled kernel (and weedogit distros with appropriate nvme modprobes).

[wiak]

So I now, per my above posts, have a working weedogged frugal install of Zorin lite XFCE, which is great. However... tried similar with KLV-Airedale beta11, but for some reason grub2 complaining invalid signature (I think related to KLV vmlinuz); a bit odd since I had usb stick KLV booting previously. I might just try copying that one across to the nvme and sorting out its WDL initrd - no time at the moment though. EDIT: quickly tried the usb KLV-Airedale copied across to nvme drive with modified WDL initrd (busybox and modprobe nvme) but again complained needs signed vmlinuz (yet KLV continues to boot fine from usb stick). So for the moment I can weedogit Zorin and boot that in WDL frugal install, but not KLV-Airedale for some secure boot reason or other - I know not enough about secure boot - appears I could make a KLV-Airedale if booting it with Zorin kernel (but that's not a huge kernel type so would need to always transplant the modules into the main 07 KLV root filesystem...). Maybe I've missed some subtle detail that would also get standard KLV to boot (and as I've said, I cannot turn off secure-boot on this machine because I'm dual booting with Win 11 Pro and that needs secure boot going as it stands). I'll give rockedge's special kernel a try tomorrow but may not have the nvme driver included in the kernel??

[fredx181]

@rockedge and @All , new xlunch package:
xlunch-4.1_3.x86_64.xbps
https://drive.google.com/uc?export=down ... ya_LPWWXsa

With some workarounds I could make it show now also the specific XFCE applications (mostly for settings) that were not showing with previous setup.
Note that this is made for KLV only with XFCE (shows now also applications where the .desktop file contains OnlyShowIn=XFCE ) and probably not perfect, e.g. some 'ghost' icons may still show instead of the real icon.
EDIT: FYI, if you run "Update entries for Xlunch..." from Menu it could be that it says that xlunch-menu is already running, then "xlunch-menu-gen" (from /root/Startup) is active in "persistent" mode (which means it will check for new added applications automatically)

Xlunch

Screenshot_652x366.png (451.51 KiB) Viewed 1870 times

[Clarity]

@wiak Does the distro signature have to be registered in the firmware (UEFI) if booting natively from the HDD/system-drive?

SG2D EFI version will register its signature in the firmware on its 1st use. Subsequently it makes simple to launch any of its contained ISO files.

Dunno if this is useful info.

Edit: Retracted an earlier comment, as I am not sure of my accuracy of another member who may have useful info.

[wiak]

@wiak Does the distro signature have to be registered in the firmware (UEFI) if booting natively from the HDD/system-drive?

SG2D EFI version will register its signature in the firmware on its 1st use. Subsequently it makes simple to launch any of its contained ISO files.

In earlier tries I used Mok manager to register puppy.cer and when I full installed Zorin I had to do the same again for its certificate. However, it seems that my system is complaining about vmlinuz itself, which I presume (perhaps wrongly) isn't signed. Full installed Zorin's grub2 implementation starts up fine (which is presumably signed?) and either my full install of Zorin or my weedogit frugal install of Zorin then starts up fine using my modified WDL initrd for the frugal Zorin. However, trying to boot KLV-Airedale from that same grub2 menu, and with my modified (for nvme use) WDL initrd results in the error message that the KLV vmlinuz has the wrong 'signature'; my feeling is that Zorin has a signed vmlinuz (that uses its Mok to EFI installed cert to verify) but KLV vmlinuz is not signed with puppy certificate. Do Puppy kernels get signed? If not I doubt any Pup would boot on my secure-boot system since it seems to be configured to check certificates on whole boot chain. As far as SG2D would be concerned, I doubt that would help since, effectively, SG2D only handles the grub2 part of the booting using iso-mode for the underlying distro so the underlying vmlinuz likely to fail certificate signature check too IMO (though I don't know since I am not knowledgable on matters of secure EFI booting).

The odd thing that somewhat contradicts my 'theory' is that KLV-Airedale does successfully boot from usb stick so I don't see why booting it instead from nvme would result in vmlinuz being signature checked differently, but that nvme SSD being part of the internal laptop hardware perhaps does get included more thoroughly in the boot certificate check procedure. Big difference with the weedogit frugal install of Zorin is that the previous problem was in the initrd (nvme module not modprobed, and the busybox using 32bit inodes only), but with KLV boot the system fails BEFORE the initrd even gets loaded since system refuses to load the kernel complaining it has 'incorrect signature'. I suspect if I could sign it as Zorin's it would work (but I can't); nor do I know how to sign it as Puppy's such than EFI registered puppy.cer would allow it to boot(?). Does anyone know how to 'sign' a kernel?

Out of curiousity, today I'm going to see if I can get KLV-Airedale to boot with Zorin kernel (which requires me to store some Zorin modules inside the initrd and also inside the main 07KLV rootfilesystem sfs; somehow I expect that will work.

[wiak]

To get weedogit frugal install of Zorin to work, by the way, I only needed to add 'nvme' to the end of the initrd/init modprobe code. nvme-core is a dependency of that so modprobe loads it automatically anyway. As I said I also needed that different non uclibc version of busybox to work with the nvme drive.

For KLV, nvme driver needs to be built into the kernel itself. Will still need that alternative busybox version of WDL initrd to work (the modprobe stuff is irrelevant for typical KLV install since drivers directly built into the kernel).

But... does seem like I'd need a signed kernel for my laptop secure secure secure boot setup... Won't be an issue for everyone though - and not at all if they disable secure boot I suppose.

[rockedge]

@wiak I was able to successfully compile a kernel huge 5.16.14-klvx that has both overlayfs (built-in) and aufs5. Set up for SMP PREEMPT, virtualization, nvme support is built in and hugepages enabled.

• huge-5.16.14-KLV aufs5 = NO, overlayfs = builtin

• huge-5.16.14-klvx aufs5 = YES, overlayfs = builtin

I am arranging the kernel components for use in KLV-Airedale.

[Clarity]

@rockedge great!

Do Puppy kernels get signed?

FATDOG and I think @fredx181 DOGs too.

Does anyone know how to 'sign' a kernel?

@jamesbond and the mmebers over at @fatdog know and are helpful.
'Signed' will only continue to become more and more important as we march into the future with hardware. Good approach it seems you are taking as you continue to get ahead of the advances allowing to boot with or without secure firmware fully enabled. Great!

[wiak]

@wiak I was able to successfully compile a kernel huge 5.16.14-klvx that has both overlayfs (built-in) and aufs5. Set up for SMP PREEMPT, virtualization, nvme support is built in and hugepages enabled.

• huge-5.16.14-KLV aufs5 = NO, overlayfs = builtin

• huge-5.16.14-klvx aufs5 = YES, overlayfs = builtin

I am arranging the kernel components for use in KLV-Airedale.

Thanks rockedge, I'll give your new kernels a spin later today or tomorrow.

But interesting news: I can confirm that current KLV-Airedale64 beta11 is booting fine installed as frugal installation onto my new HP laptop's nvme SSD when secure-boot is DISABLED (posting from it right now) - I guess that means it has sufficient nvme driver support already built in. Did however require my newest WDL initrd containing that alternative busybox compilation. It still won't boot on this laptop if secure-boot is enabled, since it then appears to also need a signed kernel to presumably match the EFI BIOS certificate. That's fine for now.

My worry would be for the future - very strict secure boot could become defacto with no alternatives in future laptops I fear. Microsoft, Ubuntu, Debian, and Redhat all appear to have reached operating agreements about that so their distros should be able to be booted fine. However, the likes of Arch Linux and Void Linux and Puppy Linux and so on (which uses its own kernel compile) could be in trouble unless they start signing kernels in appropriate required way. Arch Linux wiki in fact states that Arch is not yet working with secure boot - I hope they will work on that limitation.

The situation could also spell the end of aufs since self-compiled/patched kernels will not be usable unless somehow 'signed' and certified to EFI or whatever is required. Luckily WDL initrd frugal install capability is obviously not itself effected by this situation, since uses kernel official overlayfs and not aufs, so using official upstream kernels of Ubuntu, Debian, or RedHat should allow production of WDL_distros using these particular upstream repos and official package managers. I do hope Arch and Void will start producing signed kernels that can be used with secure boot too though. I can't leave secure-boot disabled on this particular laptop since a business machine that my partner wants to keep working with Win 11 Pro, but at least I can now use weedogged Zorin on it and thus use all the same utility addons for WDL intird that are being developed on KLV-Airedale. Also I can continue to run KLV-Airedale itself, but from usb stick; however, I'm more likely to repurpose my old main dev machine primarily for KLV-Airedale use so installed to hard drive on that particular machine (the 2008 HP Elitebook 2530p 12in screen core2duo 4GB laptop I mainly use - which runs very fast and smooth with KLV and all Pup/Dogs for that matter).

[wiak]

@rockedge great!

Do Puppy kernels get signed?

FATDOG and I think @fredx181 DOGs too.

I believe, but am not sure, that latest DebianDogs use official upstream kernels, so are signed by default. However, older DebianDogs used aufs-patched kernel so I'm not so sure their kernels were 'signed'. Many did include puppy.cer for grub2 to work (and could be registered with EFI) but I suspect that alone is not enough.

[Clarity]

Tovalds has been on-board with this for awhile and is evident in his work.

"Looking at the tea leaves" it is my observation, like you, that within 5 years most of the Linux community will view non-signed distros as obsolete or arcane.

Time marches and we continue to adapt to the positive movements.

[wiak]

But interesting news: I can confirm that current KLV-Airedale64 beta11 is booting fine installed as frugal installation onto my new HP laptop's nvme SSD when secure-boot is DISABLED (posting from it right now) - I guess that means it has sufficient nvme driver support already built in. Did however require my newest WDL initrd containing that alternative busybox compilation. It still won't boot on this laptop if secure-boot is enabled, since it then appears to also need a signed kernel to presumably match the EFI BIOS certificate. That's fine for now.

I'll endeavour to publish new WDL initrd either later tonight or tomorrow so future KLV-Airedales can be frugal installed successfully onto nvme drives (at least when secure boot is disabled). As I've said, weedogit Zorin lite variant will also work and even when secure boot enabled - assuming its certificate is registered in the EFI bios via Mok (WDL_ZorinXFCE works even with secure boot because of its signed kernel I think).

I'll try an actual Pup later (I do have puppy.cer registered in the EFI), but I suspect it will also be no-go with secure boot, on this super-strict laptop, because of unsigned kernel (unless I'm wrong about that).

[rockedge]

@rockedge and @All , new xlunch package:
xlunch-4.1_3.x86_64.xbps
https://drive.google.com/uc?export=down ... ya_LPWWXsa

xlunch is a big part of the KLV-Boxer models. JWM-Rox combination and the menu system in the WDL-Void64's and 32's. I started with xlunch in WeeDog-Void's and started first experimenting with it with FirstRib builds

I really like it and I am going to try to use a whisker menu and xlunch setup on KLV-Airedale-beta12

[wiak]

new v505rc1 release of WDL initrd. Fetch it using the usual get/fetch script provided at this link: https://weedoglinux.rockedge.org/viewto ... p=355#p355

contains new static busybox that works with nvme drives (older ones didn't). Also uploaded revised weedogit.sh script - the WDL initrd/init also contains nvme modprobe so that's needed for weedogit other distros if installed to nvme-type SSD drives. As I've already posted, current KLV-Airedale beta11 kernel already contains kernel driver for nvme so the new modprobe addition isn't important for that one. KLV-Airedale beta11 has been tested with this new WDL initrd v505rc1 to work from internal nvme SSD frugal install (albeit with secure boot disabled on my new HP laptop, which turns out to be a particularly fussy machine in terms of tight kernel certificate signing security).

[fredx181]

@rockedge and @All , new xlunch package:
xlunch-4.1_3.x86_64.xbps
https://drive.google.com/uc?export=down ... ya_LPWWXsa

xlunch is a big part of the KLV-Boxer models. JWM-Rox combination and the menu system in the WDL-Void64's and 32's. I started with xlunch in WeeDog-Void's and started first experimenting with it with FirstRib builds

I really like it and I am going to try to use a whisker menu and xlunch setup on KLV-Airedale-beta12

Nice ! You may want to consider not including the symlink xlunch-menu-gen in /root/Startup (persistent mode) as it's increasing RAM usage at initial boot (the Whisker Menu is taking more RAM as well, btw).

@wiak I can confirm that replacing the busybox binary in initrd.gz with the alternative one makes KLV-beta12 boot on nvme harddisk, great find, thanks !

[wiak]

Successfully booted and now posting from beta12, but using newest initrd ver505rc1 to allow this frugal install on this HP laptop's nvme harddrive (albeit with secure boot disabled on my machine).

[rockedge]

@wiak good news for sure!
Is initrd ver505rc1 ready for inclusion from beta12 onwards?

[wiak]

@wiak good news for sure!
Is initrd ver505rc1 ready for inclusion from beta12 onwards?

Yes, it is rockedge. Just test it and let me know if any issues, but should be fine. Only changed busybox and included module nvme (module isn't used by KLV anyway).

[rockedge]

Since the most recent GRUB2 update (2.02+dfsg1-5ubuntu1) in Ubuntu, GRUB2 does not load unsigned kernels anymore, as long as Secure Boot is enabled. Users of Ubuntu 18.04 will be notified during upgrade of the grub-efi package, that this kernel is not signed and the upgrade will abort.

I am looking into what it will take to create a signed kernel and ran across this information.

[wiak]

Since the most recent GRUB2 update (2.02+dfsg1-5ubuntu1) in Ubuntu, GRUB2 does not load unsigned kernels anymore, as long as Secure Boot is enabled. Users of Ubuntu 18.04 will be notified during upgrade of the grub-efi package, that this kernel is not signed and the upgrade will abort.

I am looking into what it will take to create a signed kernel and ran across this information.

Yes, that's the issue. I also came across this page: https://gloveboxes.github.io/Ubuntu-for ... -boot.html

[rockedge]

this has good info
https://stegard.net/2016/10/virtualbox- ... untu-fail/

[wiak]

Doesn't stop there though - could also require, for example, signed kernel modules: https://blog.delouw.ch/2017/04/18/signi ... d-modules/

[rockedge]

@wiak it looks daunting.....but I am looking how to begin to try it out

[wiak]

My worry is what I read here: https://askubuntu.com/questions/1352946 ... e-to-21-04

Mind you that link still seems to be talking about kernel signing issue only.

It could be that my Weedogged frugal zorin is working ok with secure boot on this machine because all modules are also signed, but I don't know - just guessing.

[wiak]

@wiak it looks daunting.....but I am looking how to begin to try it out

Yes, we need to deal with it all eventually. Maybe just need signed kernels to get it all working at this stage.

The following site really does evidence the danger of secure boot world, dominated by Microsoft at that time anyway, to Linux: https://blog.delouw.ch/2017/04/18/signi ... d-modules/

[rockedge]

This could wipe out most Linux distro's if a legacy BIOS boot option is not available anymore from the computer makers.

It will be very hard to ever use a custom kernel for example one built via the kernel-kit or any module built against those custom kernel source, like the drivers for VirtualBox will have to be signed modules. Hence the set of instructions detailing a how to sign a VBox module or the signed kernel will not load it.

Some how this is all very dis-heartening. We're going to be learning how to do this somewhat it looks like.

Simply disgusted that again I'm being told how to be "secure"

[wiak]

This could wipe out most Linux distro's if a legacy BIOS boot option is not available anymore from the computer makers.

It will be very hard to ever use a custom kernel for example one built via the kernel-kit or any module built against those custom kernel source, like the drivers for VirtualBox will have to be signed modules. Hence the set of instructions detailing a how to sign a VBox module or the signed kernel will not load it.

Some how this is all very dis-heartening. We're going to be learning how to do this somewhat it looks like.

Simply disgusted that again I'm being told how to be "secure"

The boot mechanism is a major attack vector by malware so I guess we just have to learn and go with the flow. Redhat and Ubuntu are clearly going to defend their position on the matter so I doubt will be any threat to Linux per se. My main concern would simply be about self-signing - just hope no hardware standard ever means computers created whose EFI system will not work with self-signed binaries. It may be that there is nothing to worry about, except that we can't bury our heads in the sand since not everyone is going to be turning secure boot off even if they can. So including working signed kernels with distros we produce is probably going to be essential so we have to learn how to do it. My own problems lately were that I didn't know what to expect so wasn't sure if my failure to boot issues were something to do with EFI secure boot or something else (e.g. in the initrd). Turned out to be a bit of both, which certainly complicated getting things to work and especially since I did not and do not wish to brick a new machine by mucking about with it too much in terms of adding certificates via Mok utilities and so on. Easy working with technical matters I'm familiar with, but a different matter altogether when the issues are in an area I have no experience in (and have to rely on googling and 'perhaps' risky experiments). Previously I never had any secure-boot capable hardware, and more recently, had a machine that was secure-boot capable, but pretty old so maybe not so security tricky. This sudden arrival of a new business machine was a different matter - scared to even try and get dual-booting working on it at all like alone deal with secure-boot signing issues I knew nothing about... but if you don't have that kind of hardware (or also nvme disk involved in the problems I was facing) then you can't test these matters at all, which is not good for others who may use the work you publish. For the moment, the option to turn off secure boot remains a good one at least!

Another link - this one including a further link to fedora article regarding Testing secure boot with KVM (virtual machines):
https://sourceware.org/systemtap/wiki/SecureBoot
https://fedoraproject.org/wiki/Using_UE ... t_with_KVM
Per usual, Arch Wiki contains a lot of info on signing for example kernel and boot manager (even tho they say their official install image does not support secure boot any more):
https://wiki.archlinux.org/title/Unifie ... ecure_Boot

I have to say that it is all very complicated to digest though, and hard (painful) to become inspired enough to bother (though someone has to do it eventually...).

Here is some related dmesg info from my currently booted secure boot system (I am currently using full installed Zorin):

Code: Select all

dmesg | grep -i secure
[    0.000000] secureboot: Secure boot enabled
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[    0.007432] secureboot: Secure boot enabled
[    0.802247] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
[    0.804605] integrity: Loaded X.509 cert 'HP Inc.: HP UEFI Secure Boot DB 2017: d9c01b50cfcae89d3b05345c163aa76e5dd589e7'
[    0.805653] integrity: Loaded X.509 cert 'zorin Secure Boot Module Signature key: d04e984150b8256bbd9f51fb163b12565e33e04c'
[    4.105203] Bluetooth: hci0: Secure boot is enabled

Shows the certificates I used Mok to load to EFI. The business has two such machines; I don't seem to have the puppy cer loaded on this one (according to my limited understanding).

For detailed info you can also use:

Code: Select all

# mokutil --help
Usage:
  mokutil OPTIONS [ARGS...]

Options:
  --help				Show help
  --list-enrolled			List the enrolled keys
  --list-new				List the keys to be enrolled
  --list-delete				List the keys to be deleted
  --import <der file...>		Import keys
  --delete <der file...>		Delete specific keys

So, to see enrolled keys:

Code: Select all

mokutil --list-enrolled

This machine is also using a 'TPM', which is "an international standard for a secure cryptoprocessor, which is a dedicated microprocessor designed to secure hardware by integrating cryptographic keys into devices." - don't ask me what that means to the overall issues involved! I think that is what TerryH post was referring to since there is a module that can be loaded that is related to it (I have not dabbled with that as yet); no, he was referring to 'vmp', whatever that is.

Mucking around slightly further on current booted Zorin system, I get this:

Code: Select all

root@william-HP-ProBook-430-G8-Notebook-PC:/boot# uname -a
Linux william-HP-ProBook-430-G8-Notebook-PC 5.13.0-39-generic #44~20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
# sbverify --list /boot/vmlinuz-5.13.0-39-generic 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2017)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
root@william-HP-ProBook-430-G8-Notebook-PC:/usr/lib/modules/5.13.0-39-generic/kernel/drivers/nvme/host#

I was expecting it to say something related to Zorin, but instead seems Ubuntu related certificate involved.

Also I tried (without knowing what I'm doing):

Code: Select all

# sbverify --list /usr/lib/modules/5.13.0-39-generic/kernel/drivers/nvme/host/nvme.ko
Invalid DOS header magic
Can't open image /usr/lib/modules/5.13.0-39-generic/kernel/drivers/nvme/host/nvme.ko
root@william-HP-ProBook-430-G8-Notebook-PC:/usr/lib/modules/5.13.0-39-generic/kernel/drivers/nvme/host#

Perhaps means the modules themselves aren't signed or maybe that sbverify command isn't being used by myself properly here...

https://wiki.archlinux.org/title/Unifie ... ecure_Boot

To sign your kernel and boot manager use sbsign, e.g.:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/BOOTx64.EFI
Warning: Signing kernel only will not protect the initramfs from tampering. See Unified kernel image to know how to produce a combined image that you can then manually sign with sbsign.

Unified kernel image
A unified kernel image is a single executable which can be booted directly from UEFI firmware, or automatically sourced by boot-loaders with little or no configuration.

Although Arch supported kernels themselves can be loaded by UEFI firmware, a unified image allows to incorporate:

a UEFI stub loader like systemd-stub(7),
a kernel image,
an initramfs image.
the kernel command line,
optionally, a splash screen.
The resulting executable, and therefore all these elements can then be easily signed for use with Secure Boot.

The following was check on fossapup kernel:

Code: Select all

william@william-HP-ProBook-430-G8-Notebook-PC:/media/william/linux/fossapup64$ sbverify --list vmlinuz 
No signature table present

similarly for VoidPup64:

Code: Select all

root@william-HP-ProBook-430-G8-Notebook-PC:/mnt/+home+william+Downloads+VoidPup64-22.02+3.iso# sbverify --list vmlinuz 
No signature table present

Same 'No signature table present' with Vanilla Dpup vmlinuz.

But, Clarity is correct about FatDog:

Code: Select all

root@william-HP-ProBook-430-G8-Notebook-PC:/mnt/+home+william+Downloads+Fatdog64-812.iso# sbverify --list vmlinuz
signature 1
image signature issuers:
 - /CN=Fatdog64
image signature certificates:
 - subject: /CN=Fatdog64
   issuer:  /CN=Fatdog64

Just noticed this very useful link on FatDog website re: how they did it: https://mjg59.dreamwidth.org/20303.html

Earlier DebianDogs (Debian, Ubuntu, whatever) likely do not have signed kernels either, though most recent ones might (short of time to build and check, sorry) - for example BusterDog, if using official Debian kernel which will be Debian signed (an advantage of using an official overlayfs-capable, non-aufs-patched, official upstream kernel of big distros like Ubuntu, Debian, and RedHat).

So, looks like, I could install FatDog on this machine (assuming it sees the nvme SSD harddrive...) and get it to work with machine's Secure Boot. I will try later.
EDIT: I opened up the FatDog iso and copied its files into a folder, but I was hoping to see the fatdog cer or similar key so I could try and register it with Mok utils, but I can't for the life of me find it - I don't really want to dd to a usb stick and try booting that first since I don't have a blank usb stick handy... I'm suspecting now that it is in one of these usb boot images provided in FatDog iso... Oh well, later again maybe.

EDIT2: Okay found it after using command: mount -o loop,offset=1048576 usb-boot-gpt.img temp/
Then in my dir temp I see the file fatdog64-2041.cer, which I'll try registering with mokutils, but actually I don't know how to boot FatDog so will have to check grub2 example for that if I find one... I'm feeling a bit reckless - I hope I don't break anything or I'm in big trouble.

Crazy stuff eh!!!...