FrugalPup 20 - Puppy frugal installer.

[bigpup]

Running in Xenialpup64 7.5

frugalpup_15v.sfs

On the fist window, none of the buttons work.
Exit one does work

[gyro]

On the fist window, none of the buttons work.
Exit one does work

Sorry about that, my bad.
I managed to miss a file '/usr/local/mi-utils/kill-parent-yad' when creating the sfs file.

I've uploaded a fixed version.
Please download extra sfs 'frugalpup_15v.sfs' from http://www.mediafire.com/folder/rdyc5lgzpeij1/frugalpup (2.5 MiB).

@bigpup, Thanks for testing.

gyro

[gyro]

FrugalPup 15w, StickPup 15w, DiskPup 15w and f2StickPup 15w - Puppy frugal installer.
This is another preview/beta version of FrugalPup 16 which will be released in conjuction with mio16...tar

Download extra sfs 'frugalpup_15w.sfs' from http://www.mediafire.com/folder/rdyc5lgzpeij1/frugalpup (2.5 MiB).

Changes:

1. New minimal frontend, 'f2StickPup', taking advantage of the new f2fs support.
This is like 'StickPup' except it formats the stick with a small fat32 partition and the remainder as an f2fs partition.
Grub2 is installed in the fat32 partition.
The sourced Puppy is installed in the f2fs partition.
This is a quick way to install a Puppy that can use a savefolder.

2. Some more improvements to descriptive text in some dialogs.
Particularly the initial dialogs in 'StickPup' and 'DiskPup'.

gyro

[gyro]

I think I will remove the "SecureBoot enabled" support currently in version 15v and version 15w, for version 16.
It's really "crippling" "SecureBoot" while appearing to support it.

And then try to implement full MOK support for version 17, i.e. where the user has to generate their own MOK if "SecureBoot" is enabled. And sign the stuff they want to boot, with their own key.

gyro

[foxpup]

FYI

I read and found out that Ubuntu has made grub2 efi's that will boot an unsigned kernel in Secure Boot.
The one you used in frugalpup<=13 from zilla-efi is from Bionic.
It is probably the last one Ubuntu has made that will boot unsigned kernels in Secure Boot.

As far as I know Ubuntu was the only distro that allowed unsigned kernels to boot in Secure Boot.
Fedora an debian certainly did not.
Ubuntu had good reasons and continued it for a long time, from QQ up to BB. But for some other reasons I cannot track down, they are getting more restrictive.
DD does not allow it anymore.
I would not be surprised that Microsoft is getting some hold on canonical.

Hmmm, I still like Secure Boot OFF best

[belham2]

FYI

As far as I know Ubuntu was the only distro that allowed unsigned kernels to boot in Secure Boot.
Fedora an debian certainly did not.

Hi Foxpup,

I updated one of MX-19 installs today, and I watched when the kernel was updated, it was designated as "unsigned".

MX-Linux is based on Debian, fairly strictly.

So I am wondering about the "unsigned" comment.

I will check my other Linux distros. I run about 7-8 of them thru the household here, outside of the pups and ddogs.

[bigpup]

I think I will remove the "SecureBoot enabled" support currently in version 15v and version 15w, for version 16.
It's really "crippling" "SecureBoot" while appearing to support it.

gyro

That is what I have been testing in 15w.
As you say. SecureBoot is not working.
I was hoping you had found the answer to making it work.
Doing an install to a USB flash drive and having secure boot disabled, does seem to work OK.

I am still testing some of the other options in 15w.
I will just report problems, if any.

Thanks very much for trying to develop a Puppy Linux installer, that will make an install, that will work with secure boot enabled!!

Booting from a USB flash drive, with secure boot disabled, is normal for about all UEFI computers.
However, if you install to an internal drive.
Some, (like the one I have) will only boot from internal drive, if secure boot is enabled.

[foxpup]

hello @belham2

it was designated as "unsigned"

I am (almost) sure it is. MX does ask to turn OFF Secure Boot because.
And it probably uses a shim+grub2 from debian or just grub2 without shim.

You can check signing of shim (microsoft), grub2-efi (debian or nothing for MX) and the kernel (for MX not signed) with

Code: Select all

pesign -i 'path/to/file' -l

Install pesign through PPM.

You probably run with Secure Boot OFF
or you have Secure Boot ON and you use shim+grub2 from ubuntu QQ-BB.
You could have shim+grub2 from Ubuntu installed by setting up a dual boot with an ubuntu install or from using frugalpup (<=13).

Interesting read:
An Overview of Secure Boot in Debian

In fact I use Ubuntu's shim+GRUB to boot Debian Stretch on my laptop without turning off secure boot.

[mikeslr]

Hi gyro & All,

On one occasion I used LICK under Windows 7 to create a Puppy on a USB-Key. The Puppy was one in an efi file was provided in the ISO. If I recall correctly, I was able to boot the USB-Key from my computers which do not employ the UEFI mechanism, and from my wife's computer which does require that the system be UEFI compliant.

I wonder if frugal installer will (also?) create a USB-Puppy bootable from both 'Bios' and UEFI computers?

[gyro]

I wonder if frugal installer will (also?) create a USB-Puppy bootable from both 'Bios' and UEFI computers?

Yes, it does, BUT it only works reliably for UEFI with "SecureBoot" disabled.
And when version 16 is released, it should only work with "SecureBoot" disabled.

gyro

[gyro]

UEFI booting with "SecureBoot" disabled, is easy, if anything, easier than mbr/bios.

But once we introduce "SecureBoot" enabled, things become a whole lot more complicated.
Just one of the problems is that not all implementations of uefi behave the same way.
I have a Lenovo IdeaPad with uefi Windows 10, that won't even recognise any uefi usb stick I have produced.
Wheras a HP stream with uefi Windows 8 behaves in an expected manner. i.e. with "SecureBoot" enabled FrugalPup v15w produced usb sticks work fine, after the included MOK is "enrolled". As a matter of fact too well, because it's booting an unsigned Grub2 and unsigned Puppy without even a hint of a complaint. so it could be booting anything.

The only thing you can be sure of with various implementations of uefi is that it will boot Windows, with "SecureBoot" enabled.

From my limited research it would seem that for small distro's like Puppy, the "appropriate" way to do "SecureBoot" is to use a MOK (Machine Owner Key), whose private key is used to sign the ".efi" program that follows the signed shim, and whose public key is "enrolled" once for each machine.
So we will probably have to accept that the "crude" "enroll the MOK" process will be required, unless "SecureBoot" is disabled.

It's the whole MOK thing, along with the facilities available in Grub2, that I whish to pursue for version 17 of FrugalPup.

gyro

[gyro]

As you say. SecureBoot is not working.

Did you "enroll" the MOK from the "ENROLL_THIS_KEY_IN_MOKMANAGER.cer" file?
This has to be done once on each machine for booting to work with "SecureBoot" enabled.

gyro

[bigpup]

I think I did "enroll" the MOK from the "ENROLL_THIS_KEY_IN_MOKMANAGER.cer" file.
Is there a way to be sure?

[gyro]

I think I did "enroll" the MOK from the "ENROLL_THIS_KEY_IN_MOKMANAGER.cer" file.
Is there a way to be sure?

I'm not sure.
The "mokutil" package is supposed to tbe able to list MOK's.
On bionicpup64, "mokutil" partially worked, in that I could "reset" the MOK repository, but it would not list the "enrolled" MOK's.
On bionicpup32, "mokutil" would not do anything, complained about a lack of EFI support.
(In each case I installed "mokutil" via PPM.)

On my HP stream, the issue never arose.
If the MOK was not "enrolled", on boot I got the "mokmanager" blue screens and I had to "enroll" the MOK.
(This happened on the first boot, and after I had "reset" the MOK repository).
If the MOK was "enrolled" the boot proceeded without a hitch.

A note on "mokutil", it doesn't change the MOK directly, it makes requests to "mokmanager".

Thanks for testing.
This "SecureBoot" and MOK stuff, needs a lot more research.
So I'd going to leave it until after I've released "mio16" and "FrugalPup v16", and make it the number 1 issue for v17.

gyro

[bigpup]

Still trying Frugalpup 15w.

Does this Mok enrolled thing put anything in the UEFI bios?

I ask because i got the same as you the first time I tried Frugalpup 15w.

if the MOK was not "enrolled", on boot I got the "mokmanager" blue screens and I had to "enroll" the MOK.

I enrolled, but the USB flash drive would not boot.
I figured maybe just a bad install.

I tried a completely new fresh install of Bionicpup64 8.0 on the same USB.
The USB was clean, with nothing on it, formatted fat32.
For boot option selected UEFI.
This booted with no problem with secure boot enabled.
This time I never got the "mokmanager" blue screens.
It just booted as normal.

[gyro]

Does this Mok enrolled thing put anything in the UEFI bios?

Yes.
When a MOK is successfully "enrolled" it gets stored in NVRAM, so it's available in that computer for ever, and you should not see a blue "mokmanager" screen again no matter how may different usb sticks you create with FrugalPup v15w.
(Unless you request the removable of the MOK using "mokutil --reset".)

gyro

[bigpup]

When a MOK is successfully "enrolled" it gets stored in NVRAM, so it's available in that computer for ever, and you should not see a blue "mokmanager" screen again no matter how may different usb sticks you create with FrugalPup v15w.

That must have happened the first time I did it.

So, that first install to the USB flash must have just been a bad install of the Puppy version. MOK must have worked OK. It did get to a boot menu, just gave errors about booting the installed Puppy version.
Now that I think about it. Those were the kind of errors a bad install would give.

Maybe keep this Mok stuff in FrugalPup and give it some time for others to try it.
See what others say about using it.

I know for sure that all UEFI is not the same.
The computer manufacture has some control of how it is going to work.
Hopefully, they would use the full normal version.
(one computer seems to have this full normal UEFI)
Plus, you are dealing with when was the UEFI developed.
Older versions are not the same as the newest UEFI.
UEFI has been tweaked and supposedly improved.
Legacy boot is now CSM.
CSM has options. (on my computer it does)

Note:
I have a much older computer with UEFI.
To even see a USB drive as something to boot from.
Secure boot has to be disabled.
Disable secure boot.
I can boot it with Grub4dos boot loader on a USB drive.

[bigpup]

On bionicpup64, "mokutil" partially worked, in that I could "reset" the MOK repository, but it would not list the "enrolled" MOK's.
On bionicpup32, "mokutil" would not do anything, complained about a lack of EFI support.
(In each case I installed "mokutil" via PPM.)

Well, I have been using FrugalPup 15w running in Bionicpup32 8.0

I installed "mokutil" via PPM

From PPM, this is a mokutil package compiled for Ubuntu.
Tried running this mokutil in a terminal to see if it shows errors

I notice several versions of Mokutil listed here for Ubuntu Bionic Beaver:
https://pkgs.org/download/mokutil
Wonder which one you got from PPM?

[mikeslr]

Hi gyro,

Edit: relax for awhile -- may have been a problem with the Key.

I know you're working on 15, but I noticed a problem with 13. So thought, if the code hasn't been changed you might want to examine it.

I selected Frugalpup intending to install to a folder on a freshly gparted USB-Stick. During the routine I was asked I wanted to install Puppy files to a folder. Opted "yes" and a Gui opened to create and name one. But when the last/confirm window appeared it indicated that the installation of Puppy files would be to the root of the device, not a folder.

Cancelled. Created a folder on the stick, then restarted Frugalpup, selected the folder and the last/confirm window now showed that Puppy files would be placed in that folder.

[gyro]

@mikeslr,

You may have run into a limitation of the yad "directory" dialog.
When you use the "Create Folder" button and get a field to enter the name of the new folder, you have to hit the "Enter" key after typing the name.
The new folder will then be added to the path above.
Then you can click the "OK" button.
If you click "OK" without the folder being registered in the path, it is not created and ignored.

Hmm...probably could do with some more destriptive text, explaining the need to hit the "Enter" key.

gyro