How to dual boot "Precise Light" and "BionicPup64" from the same flash drive?

[m-cuda]

On a USB flash drive, I have installed "Precise Light" and "BionicPup64" to two separate GPT partitions, '(hd0,msdos3)' and '(hd0,msdos1)', respectively. Each installation has its own "/EFI/boot/bootx64.efi" and "/grub.cfg". However, on the UEFI boot no matter which partition I select the "Precise Light" grub.cfg menu is always displayed.

Conjecture:

bootx64.efi does not know the partition it was loaded from and searches all available partitions for a grub.cfg to use.

Is this conjecture correct? Is there any way to force bootx64.efi to use the grub.cfg from the same partition where the bootx64.efi lives?

N.B., This flash drive will be booted in UEFI mode only. Both installations are bootable. I confirmed this by escaping to the grub command prompt and manually entering the boot sequence. As a workaround I have the added following menu item to the "Precise Light" grub.cfg:

Code: Select all

menuentry "configfile for BionicPup64" {
    configfile (hd0,msdos1)'/grub.cfg'
}

This works, but when booting into BionicPup64 I need to visit two grub menus. I want to visit only one.

ADDENDUM
I think the question really boils down to:

After the UEFI firmware has loaded bootx64.efi into RAM and before transferring control to the bootx64.efi code does the UEFI firmware pass any parameters via CPU registers or in RAM anything specifying the partition that bootx64.efi was loaded from.

Empirically, I think not and the bootx64.efi code starts clean and has to search all partitions for grub.cfg.

The objective here is not to have a master boot menu whose contents is dependent on all the installed Puppies. (This has to be updated every time a new Puppy is installed on the disk. Something I want to avoid.) But use the boot menu of each installed Puppy independently. I can inconveniently achieve this manually by exiting to the grub command prompt and entering the appropriate grub configfile command. Is it possible to do better? In other words, I want to copy a Puppy partition from another drive and have it bootable without doing anything additional.

[bigpup]

This is how I put multiple Puppies on a USB drive.

You can do an install to USB using the frugalpup Installer.
It can install a boot loader that works with legacy bios or UEFI or both.

Frugalpup installer topic is here:
http://www.murga-linux.com/puppy/viewto ... 58e14c57f6

Bionicpup64 8.0 will have frugalpup installer after you do the latest Quickpet->Info->Bionicpup updates
Reboot and save so the new changes are being used.
Just make sure when you start frugalpup it is v20.
I would run it in Bionicpup64.

This is how to setup the USB and install Puppy to the USB.

You do have to manually setup the USB drive with partitions, before using Frugalpup installer.

Use Gparted program to delete all partitions on drive.
Make two partitions.
First one a small 300MB, formatted fat32, flagged boot.
2nd partition the rest of the drive, formatted ext 3 or 4.

Note:
If you use a GPT partition table. Only the UEFI boot loader can be installed.
A msdos partition table. Can install uefi, legacy, or both type boot loaders.

Have the Puppy version iso available at a location it can be accessed.

run menu->Setup->FrugalPup flexible frugal installer.

This is a program that requires you to make choices, just go slowly and read the provided info.

On main widow select the Puppy button.
This will go thru the install process.
Install Puppy version to the 2nd partition.
It will provide a way to make a directory(folder) to put the frugal install in.
Do that. Best if you name it the name of the Puppy version or similar.
Carefully read that pages information. Pressing OK does not make the directory. Pressing enter key does.
Complete install.

Back at main window.
Select boot button.
This will install the boot loader.
Choose to install to the first partition.
You can choose UEFI or legacy or both.
Both will install both types of boot loaders, so both will provide for UEFI and legacy booting.

When complete you should have Puppy version as a frugal install on the 2nd partition.
The Grub2 boot loader on the first partition.

Note:
On a normally setup UEFI (secure boot enabled) it will require installing the Puppy security key.
When you boot.
The Puppy security key install will run and walk you through installing the security key.

To install other Puppy versions to same drive.
Just do the complete install process again.
Every time you run the boot loader install.
It searches the drive for everything it finds and makes a boot menu entry for all.
So, it updates the boot loader it had already installed.

I have one USB drive with 7 different Puppy versions on it.
Each one in their own frugal installs.

Note:
The first partition (boot partition) is fat 32 format, because that is now a requirement of UEFI for a boot partition.
It expects to see a fat32 partition as the place to find the boot loader.

[m-cuda]

I found this tutorial on EFI programming - https://www.rodsbooks.com/efi-programming/hello.html. Following are some relevant excerpts from this tutorial:

Code: Select all

EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);

typedef struct _EFI_SYSTEM_TABLE {
    EFI_TABLE_HEADER                Hdr;

    CHAR16                          *FirmwareVendor;
    UINT32                          FirmwareRevision;

    EFI_HANDLE                      ConsoleInHandle;
    SIMPLE_INPUT_INTERFACE          *ConIn;

    EFI_HANDLE                      ConsoleOutHandle;
    SIMPLE_TEXT_OUTPUT_INTERFACE    *ConOut;

    EFI_HANDLE                      StandardErrorHandle;
    SIMPLE_TEXT_OUTPUT_INTERFACE    *StdErr;

    EFI_RUNTIME_SERVICES            *RuntimeServices;
    EFI_BOOT_SERVICES               *BootServices;

    UINTN                           NumberOfTableEntries;
    EFI_CONFIGURATION_TABLE         *ConfigurationTable;

} EFI_SYSTEM_TABLE;

I am a PHP programmer so the above is a bit above my pay grade but I think they may show (or may not show - c is not my thing) that the partition from where the .efi code is loaded from is not being passed to the loaded .efi code. So, bootx64.efi doesn't know the partition it was loaded from and must search all partitions for grub.cfg.

[mikewalsh]

@m-cuda :-

Sooo.....let me get this straight. You have multiple partitions; each set-up with its own Puppy, and each containing its own bootloader...yes? And you want to run it in such a way that no matter how many more partitions/Puppies/bootloaders you add, you NEVER need to update the boot method?

I can't see how it can be done.

I learnt several years ago that whenever you add another OS to an existing set-up, you have to make some changes to your boot method, whether you like it or not. In all honesty, I find these days that it's quicker to add stanzas to my grub.cfg manually than it is to re-run the Grub4DOS bootloader config app.

With my current method, running all Puppies from sub-directories on a single, large, "common" partition, all I need to do is to copy/paste an existing stanza, followed by editing 4 words. And that's ALL it takes.

Admittedly, although this new HP desktop is, naturally, a UEFI-equipped machine, all my Pups are booted via 'legacy' mode. I admit, I have very little experience of UEFI booting, and even less interest in doing so.....but from what I understand, GRUB2 is far more capable of doing this than Grub4DOS. And GRUB2 is one of my pet "hates"; a more useless, bloated, self-important piece of crap I have yet to come across, yet for all that it's the preferred bootloader of choice for ALL 'mainstream' distros (for reasons I have yet to fathom).

Do you have a particular reason for wanting to use UEFI-only? Like, well.....I don't know. Because all new machines are thus equipped, maybe? Are you intending to be able to use your flash-drive on any machine you may come across.....or is this one of those "maybe", "just-in-case" scenarios?

I'm genuinely curious, I admit.....and out of that same curiosity, I'm now wondering; how are you selecting the partition to boot from? You must be using a boot 'menu' of some sort.....or are you selecting these through the "one-time boot menu" thingy most machines are equipped with? I take it you ARE aware that most machines always expect to find the boot information in the first few sectors of any drive, whether MBR or GPT (and regardless of the number of OSs you may be booting?

Mike.

[bigpup]

I guess telling someone how to do it the easy way is just not what they want.

You probably never tried what I told you on using Frugalpup Installer.

The drive is going to need one main boot loader that is on the first partition.
It will have entries to boot everything that is on the drive.
Where ever they are located on the drive.
You only need one boot loader.

I have a USB drive with 6 partitions and Puppy frugal installs all over it in different partitions.
Many partitions have several Puppy frugal installs in them.
It has one boot loader on the first partition and that partition is flagged boot.
Every Puppy install has an entry in this boot loaders menu.
The drive boots.
The menu comes up.
I pick which Puppy to boot.

Most computers bios always expect to find the boot loader on the first partition and flagging the partition boot, makes sure they look on that partition and only it.

If you are using this USB to boot a computer with UEFI.
The first partition on the drive will be considered the boot partition and it needs to be formatted fat 32 and flagged boot.
Why?
That is standard requirements of UEFI
In UEFI the boot loader and it's files go on this partition.

[m-cuda]

@mikewalsh wrote

I'm genuinely curious, I admit.....and out of that same curiosity, I'm now wondering; how are you selecting the partition to boot from? You must be using a boot 'menu' of some sort.....or are you selecting these through the "one-time boot menu" thingy most machines are equipped with?

The very first code that is executed on an UEFI machine is the UEFI firmware. On my machine (a Dell Inspiron 11 model 3180 laptop) if there are multiple partitions with a "/EFI/boot/bootx64.efi" then the UEFI firmware shows a multi item menu with a menu item for each partition with a "bootx64.efi". From this UEFI menu I select the partition to boot from.

I take it you ARE aware that most machines always expect to find the boot information in the first few sectors of any drive, whether MBR or GPT (and regardless of the number of OSs you may be booting?

For UEFI machines I don't think this is correct. UEFI firmware is much more capable than the old BIOS. In particular, it is capable of reading a FAT32 file system. So, it finds the boot loader "/EFI/boot/bootx64.efi" using the FAT32 file system structure. Contrast this with the old BIOS which was not capable of reading any file system so it finds the boot loader using the disk sector address of the boot loader which is found in the MBR which is in the first sector of the disk. In fact I think you can actually delete the boat loader 'syslinux' and the machine will still boot. This is because deleting a file only removes the entry in the directory. The contents of the file is left intact until it is overwritten by a new file. The BIOS does not use the directory at all but uses a disk sector address and thus can still find the intact 'syslinux'.

Admittedly, although this new HP desktop is, naturally, a UEFI-equipped machine, all my Pups are booted via 'legacy' mode. I admit, I have very little experience of UEFI booting, and even less interest in doing so.....but from what I understand, GRUB2 is far more capable of doing this than Grub4DOS. And GRUB2 is one of my pet "hates"; a more useless, bloated, self-important piece of crap I have yet to come across, yet for all that it's the preferred bootloader of choice for ALL 'mainstream' distros (for reasons I have yet to fathom).

One of the primary advantage of UEFI booting is it can insure that only trusted code is booted so mainstream distros where security is a priority use a security enabled UEFI boot process. This of course is not true for Puppy Linux.

[m-cuda]

@bigphil wrote

Most computers bios always expect to find the boot loader on the first partition and flagging the partition boot, makes sure they look on that partition and only it.

If you are using this USB to boot a computer with UEFI.
The first partition on the drive will be considered the boot partition and it needs to be formatted fat 32 and flagged boot.
Why?
That is standard requirements of UEFI
In UEFI the boot loader and it's files go on this partition.

This is not true of the UEFI firmware on my machine (a Dell Inspiron 11 model 3180 laptop). It can find and boot the boot loader - bootx64.efi - from any FAT32 partition on the disk. It may be that the implementation of the UEFI firmware on this machine is non-standard but I personally don't care. If there is a non-standard beneficial feature that I can use for 5 years I will use it. It also may be that this "enhancement to the standard" may be widely available as it would require very little additional firmware code and it is really useful.

[mikewalsh]

@m-cuda :-

Dell are well-known for implementing non-standard hardware/firmware combos. I've been using their gear for over 20 years; trust me, I know..!!

That sounds like a very non-standard UEFI implementation, if you ask me.....but hey! if it works for you (and you can find a way to do what you want), that's all that matters.

Mike.

[foxpup]

Conjecture:

bootx64.efi does not know the partition it was loaded from and searches all available partitions for a grub.cfg to use.

Is this conjecture correct? Is there any way to force bootx64.efi to use the grub.cfg from the same partition where the bootx64.efi lives?

Yes the conjecture is right. Where it is going to look is 'programmed' before the bootx64.efi was compiled.
So if you want it differently, you will have to program and compile the bootx64.efi yourself.

Compiling a grub efi binary is not that hard to do in itself.
If you also want it to boot with secure boot on, you may have some more work to do.

Chances are these 2 bootx64.efi from Precise and from Bionicpup are (almost) copies. Bit of a waste it is.
You better use 1 and bring together your entries in the grub.cfg that is found.
Keep it simple.
Bigpup's instructions are excellent.
Everything is prepared for your convenience already and tested many times.
You cannot do better yourself.

[m-cuda]

@foxpup wrote

Bigpup's instructions are excellent.
Everything is prepared for your convenience already and tested many times.
You cannot do better yourself.

This is not true. For a UEFI only boot partition something much simpler will work. Think about it for a few minutes.

[JASpup]

I boot three Linux 64 distros with this Windows tool:

https://www.pendrivelinux.com/downloads ... .0.3.2.exe

It uses a single partition and a GRUB 2 bootloader.

[foxpup]

This is not true. For a UEFI only boot partition something much simpler will work. Think about it for a few minutes.

I guess you mean

In other words, I want to copy a Puppy partition from another drive and have it bootable without doing anything additional.

and

So, bootx64.efi doesn't know the partition it was loaded from and must search all partitions for grub.cfg.

But that will not be fast booting.
You can have that with supergrub or rEFInd ... or if you program and compile your own efi grub binaries
I do not recommend it for everyday booting.

[bigpup]

You can do about anything 10 different ways.
That does not make it true, that 9 of them are the best way to do it.

[puddlemoon]

At the risk of being the 11th wheel here...,
I would 2nd @foxpup's suggestion of rEFInd...
I also have a dell with an unusual uefi... In fact I had to specify the refindx64.efi in bios to get that machine to boot refind. But also I just use it as a matter of preference on all my uefi machines.

So if you're not quite getting there with your special uefi and don't want to have to reinstall bootloaders for each change of puppy I believe rEFInd is a good option. Created by the author you mentioned earlier.

http://www.rodsbooks.com/refind/

It can find and boot the kernel (2.4 or above) directly from the root (or /boot) of any partition without configuration. I use many puppies in one partition (each in their folder) which requires manual boot entries but if you use a separate partition for each puppy then you should be able to manual install/ remove puppies at will without touching anything.
check it out.

I genuinely hope that doesn't complicate anything...

[m-cuda]

@mikewalsh wrote:

@m-cuda :-

Dell are well-known for implementing non-standard hardware/firmware combos. I've been using their gear for over 20 years; trust me, I know..!!

That sounds like a very non-standard UEFI implementation, if you ask me....

I have read many articles on the Internet that state that the ESP partition must be the first partition on a GPT disk. But, in fact on my machine (a Dell Inspiron 11 model 3180 laptop) I can do an EFI boot of bootx64.efi from the last partition of a MBR disk. So, what exactly is the truth. Here is an excerpt from Intel's "Extensible Firmware Interface Specification" - https://www.intel.com/content/dam/www/p ... fi-110.zip

2 Overview

EFI allows the consolidation of boot menus from the OS loader and platform firmware into a single
platform firmware menu. These platform firmware menus will allow the selection of any EFI OS
loader from any partition on any boot medium that is supported by EFI boot services. An EFI OS
loader can support multiple options that can appear on the user interface. It is also possible to
include legacy boot options, such as booting from the A: or C: drive in the platform firmware
boot menus.

Note the phrase "from any partition on any boot medium". Maybe the Dell implementation is following the standard and the Internet is wrong.

[bigpup]

ESP partition must be the first partition on a GPT disk. But, in fact on my machine (a Dell Inspiron 11 model 3180 laptop) I can do an EFI boot of bootx64.efi from the last partition of a MBR disk.

You are talking about completely different drive setups.
GPT is not the same as MBR.

MBR partition tabled drive.

The bootloader is stored in the first block of the bootable medium.
totally outside of the partitions.
Other boot files used by the boot loader are stored in the partitions.

GPT partition tabled drive.
The bootloader is stored on a specific partition of the bootable medium.
There is no first block of the bootable medium.
The specific partition is usually the first partition, a small size, formatted fat 32, flagged boot.

the operating system uses a selected partition as the storage location for the bootloader, though the underlying file system and the partition tables used can vary greatly. The decisive factor here is always the firmware, which stipulates a specific file format for the boot manager in this bootloader storage model. For devices with UEFI, for example, the format is PE/COFF (Portable Executable / Common Object File Format).

UEFI booting, with Secure boot enabled, usually requires a security key for the operating system, for it to boot.
Booting a UEFI with secure boot disabled in the UEFI setup puts it into a completely different way it will boot.
It does generally go into the old bios way of booting, but it does depend on what version of UEFI firmware is in the computer and how the computer manufacture tweaked the UEFI firmware code.
If the UEFI offers legacy mode or CSM mode that also changes booting ability.

[m-cuda]

@bigpup wrote

You are talking about completely different drive setups.
GPT is not the same as MBR.

I really know very well the difference between a GPT formatted disk and a MBR formatted disk.

I have a MBR formatted disk (gparted -> View -> Device Information -> Partition table: msdos). The second partition on this drive has a FAT32 filesystem with a bootx64.efi file in a /EFI directory. I can do a EFI boot from this partition.

This totally surprised me as I have read many times in Internet articles that the ESP partition must live in a GPT formatted drive. I discovered this by accident. I had used gparted to backup an existing ESP partition from another disk by copying the ESP partition to the MBR formatted flash drive. The next time I rebooted this backup partition showed up in the UEFI boot menu. I selected this menu item and was totally surprised when the machine booted.

This may not contradict Intel's "Extensible Firmware Interface Specification"

EFI allows the consolidation of boot menus from the OS loader and platform firmware into a single
platform firmware menu. These platform firmware menus will allow the selection of any EFI OS
loader from any partition on any boot medium that is supported by EFI boot services.

Note the phrase "from any partition on any boot medium that is supported by EFI boot services". Is it not possible that MBR formatted disks are a boot medium that is supported by EFI boot services.

There is no technical reason why EFI booting cannot be done from a MBR formatted drive - it is just another container for file system partitions - and nothing about EFI booting is dependent upon features of the container. Further, it is trivial for existing UEFI firmware to implement this feature as existing UEFI firmware support a CSM mode which means the code for accessing MBR formatted drives already exists.

[Clarity]

Supporting what @bigpup shows

I have a MBR formatted disk (gparted -> View -> Device Information -> Partition table: msdos). I can do a EFI boot from this partition.

msdos.jpg (42.49 KiB) Viewed 544 times

I have been using SuperGRUB2 (SG2D). a 15MB ISO that creates a bootable USB to find and boot 2020 WoofCE PUP ISOs for most of this year. I keep all of the ISOs in a single folder /boot-isos which SG2D finds and list. And I have no problems booting them.

ISOs.jpg (144.72 KiB) Viewed 544 times

Works on both my UEFI PCs as well as my BIOS 64bit PCs.

[rcrsn51]

There is no technical reason why EFI booting cannot be done from a MBR formatted drive - it is just another container for file system partitions - and nothing about EFI booting is dependent upon features of the container. Further, it is trivial for existing UEFI firmware to implement this feature as existing UEFI firmware support a CSM mode which means the code for accessing MBR formatted drives already exists.

From here.

The UEFI specification requires MBR partition tables to be fully supported.[1] However, some UEFI implementations immediately switch to the BIOS-based CSM booting upon detecting certain types of partition table on the boot disk, effectively preventing UEFI booting to be performed from EFI system partitions contained on MBR-partitioned disks.[5]

I have seen such a machine. However, the situation probably only applies to hard drives.

[m-cuda]

@rcrsn51

It cannot be doing compatibility CSM BIOS booting.

The flash drive was a data only drive, i.e., its MBR only has a partition table and was never patched with boot code. Further, since I only do UEFI booting, my Puppy partitions do not have the MBR boot loader ldlinux.sys. Even if it did the boot code of the MBR would need to know the physical sector address of the boot loader which would be in a very unusual location since this Puppy partition is the second partition of the disk. The first partition is a data only and has no boot loaders. (To install a MBR boot loader requires that specialized software that can manipulate the MBR which lives outside of any file system. This software must patch the MBR with the disk sector address of the boot loader. This software was never run. I really only copied the partition using gparted.)

This partition showed up in the UEFI boot menu. I selected this menu item and it booted. Since, this partition was in the UEFI boot menu, the UEFI firmware recognized this partition as EFI bootable.

@rcrsn51 - thank-you very much for your post. Although, it does not apply in this case, it was something I was not aware of and may be useful to know.

ADDENDUM
I totally, misread your post. I thought you were telling me that my machine was switching to CSM BIOS booting. Now, that I have read it again I understand you are telling why some UEFI implementations require GPT disk for EFI booting. I can be quite stupid but knowing this I always rethink everything and sometimes I get it right the second time.

[m-cuda]

@Clarity wrote

I have a MBR formatted disk (gparted -> View -> Device Information -> Partition table: msdos). I can do a EFI boot from this partition.

Actually, this supports my position not bigpup's.

[bigpup]

I was not saying what you are doing is not possible.
You basically have the MBR drive setup like a GPT drive with all the boot files and boot loader in a partition on the drive.
Because of the files you have on the partition, it is being seen as the efi partition by the UEFI firmware.

One question.
In the computers UEFI setup.
Is secure boot enabled?

I will say again.
All UEFI firmware versions are not the same.
UEFI firmware has changed over the years and can be modified by computer manufacture.
The last few years, they have settled into this is how all UEFI firmware will work, more or less!

Again you can do things 10 different ways.
But only one way is the normal accepted correct way.

[foxpup]

I have read many articles on the Internet that state that the ESP partition must be the first partition on a GPT disk.

I never have read such thing. You are the first to state this.

EFI boot only needs a fat32/esp partition. There can even be multiple such boot partitions.
legacy BIOS boot looks for an mbr. There is no mbr on gpt. msdos does have an mbr.

[m-cuda]

@foxpup wrote

m-cuda wrote: ↑Sun Dec 13, 2020 1:25 pm
I have read many articles on the Internet that state that the ESP partition must be the first partition on a GPT disk.

I never have read such thing. You are the first to state this.

From two earlier posts on this same topic by bigpup
Fri Dec 11, 2020 2:40 am - viewtopic.php?p=12137#p12137

If you are using this USB to boot a computer with UEFI.
The first partition on the drive will be considered the boot partition and it needs to be formatted fat 32 and flagged boot.
Why?
That is standard requirements of UEFI
In UEFI the boot loader and it's files go on this partition.

Sun Nov 15, 2020 7:54 am - viewtopic.php?p=10108#p10108

Note:
The first partition (boot partition) is fat 32 format, because that is now a requirement of UEFI for a boot partition.
It expects to see a fat32 partition as the place to find the boot loader.

So at least bigpup must have read similar articles, Anyway, I am saying this from my memory of things I read many years ago. If my memory is wrong I sincerely apologize. In fact, I remember reading many contradictory articles, the ESP must be the first partition on a GPT drive, there can be only one ESP partition on a GPT drive, there can be multiple ESP partitions. I believe I can find these articles again if I looked for them but it isn't worth the effort. So, I concede that I must have mis-remembered and I am very sorry for the inaccuracy. Your assertion "EFI boot only needs a fat32/esp partition. There can even be multiple such boot partitions." is true of the UEFI implementation on my Dell laptop and that is the only thing that matters to me.

[foxpup]

Well, I still do not read that EFI has to be from gpt.
EFI will work on msdos devices too.

It is not necessary that the boot/esp fat32 partition is the first partition on the device.
As I already said, there can be more than one boot/esp fat32 partition.
You do not know beforehand on which partition EFI will look first, at first,
though you can determine/force which EFI binary will be used first, in the BIOS settings for example.

There are many different implementation of EFI, unfortunately, so you may encounter all kind of abominations.
Remember that if you see strange behaviour.

By the way, I do consider legacy boot superior to EFI, for personal computers anyway.

[m-cuda]

@foxpup wrote:

Well, I still do not read that EFI has to be from gpt.
EFI will work on msdos devices too.

Although, I remember reading somewhere that you need a GPT disk to do EFI booting. It is clear to me the design of EFI booting is meant to support booting from both GPT and MBR disk. There are many contradictory articles on the Internet I unfortunately probably read and believed an incorrect one. You are quite right and I am very wrong and I am sorry.

Maybe the author of that article was concerned with:

@rcrsn51 wrote:

From here - https://en.wikipedia.org/wiki/EFI_system_partition.

The UEFI specification requires MBR partition tables to be fully supported.[1] However, some UEFI implementations immediately switch to the BIOS-based CSM booting upon detecting certain types of partition table on the boot disk, effectively preventing UEFI booting to be performed from EFI system partitions contained on MBR-partitioned disks.[5]

[m-cuda]

@foxpup wrote

By the way, I do consider legacy boot superior to EFI, for personal computers anyway.

The problem with legacy boot is the old BIOS cannot verify that the boot loader is secure. Although, not relevant for Puppy some other distros now verify all software - boot loader, kernel, kernel modules are secure, i.e., they are verified against a digital signature. Although, there is no technical reason that BIOS code could not do this as far as I know no BIOS does this.

[foxpup]

The problem with legacy boot is the old BIOS cannot verify that the boot loader is secure. Although, not relevant for Puppy some other distros now verify all software - boot loader, kernel, kernel modules are secure, i.e., they are verified against a digital signature. Although, there is no technical reason that BIOS code could not do this as far as I know no BIOS does this.

I do not consider 'secure boot' to contribute to substantial security.

[m-cuda]

@foxpup wrote:

I do not consider 'secure boot' to contribute to substantial security.

Secure boot is used by Windows, chromebooks, Android phones, Linux servers and probably by Apple machines (I don't like Apple so I don't follow their technology closely). Only some Linux desktops do not use secure boot. There must be a reason why secure boot is so widely deployed.

I an certain that some users of this forum and especially you will severely criticize me for this. But, this is my honest opinion.

For the things that I do on the hardware I can afford ($200) Puppy is the best OS I have found (far better than Windows) with one huge exception - relative to all other OS's that I know of security on Puppy is very weak. Because it does not use a multi-layered defense. Secure boot is only one layer (there are many others) that are implemented by other OS's but not by Puppy. (And unlike all other Linux distros that I know about Puppy doesn't even use the built in DAC layer wisely.)

In my opinion some users of this forum have a false sense of security. Just because you cannot conceive of a threat does not mean a threat does not exists. It may mean your power to conceive was inadequate. The Spectre vulnerability existed for more than 20 years (really since the beginning of modern CPU architectures with speculative execution) before it was found in 2017. It was inconceivable to engineers that the following statement was not true:

If process A cannot read the memory of process B then it is impossible for process A to determine the contents of the memory of process B.

However, using the Spectre vulnerability process A can determine the contents of the memory of process B without actually reading the memory of process B.

I believe and I think the engineers of Windows, Chromebooks, Android phones, ... believe that inconceivable vulnerabilities still exists and they may be found and exploited by people much smarter than me. So, it is safer to assume that your system may be penetrated and have multiple secondary defenses to mitigate the damage of the penetration.

This is like the question "Should I prepare for a once in a hundred years hurricane?". It is difficult to think about something that occurs only once in a hundred years. I think most people will answer this question based on their experience. If you have not experienced a once in a hundred years hurricane then you answer no - it is a waste of time and resources. If you have then you answer yes - it is important to limit the magnitude of the damage. However, the answer to this question should not be based on personal experience but on cost/benefit analysis. Is the cost of the additional security measures worth the damage that will be prevented. This is a difficult question to answer for improbable events. I think the engineers of Windows, chromebooks, Android phones, ... all have decided to implement as many secondary defenses as is practical but the engineers of Puppy have not. I personally agree with the engineers of Windows, chromebooks, Android phones, ...

[Clarity]

IMHO: "I thnk" that WoofCE PUPs going forward will (maybe must) put a stake in the ground on the cut-off for PCs going forward. 64bit PCs have been a manufacturing STANDARD since 2006. And manufacturers have been supporting secure-boot UEFI since around 2008-2009 for server needs but standard on non-servers too.

A statement should be offered to nailed the future direction into this community's consciousness even as it will be met with objections.

My view is that Puppy Linux has me the needs of ALL BIOS and distro for 32bit with those past 32bit distro continuing to boot and run for 32bit PCs in today's world.

Many of those who will be upset allude to a false notion of benefit when used on a 64biy PC. In some of my test, I have found forum posts which are inaccurate of a "major" performance difference in 32bit use on 64bit PCs. My findings does not mean that members are purposely reporting inaccurately, rather, that their test or their hardware or their evaluation does not seem to warrant a need to continue running a 32bit PUP version versus a 64bit version on any 64bit platform.

I have NO intention for this statement to be any topic of getting under anyone's skin, rather, Puppy Linux's future may depend on all focused on the PCs we now have from the past decade (+ half). The resources (contributors) seem to be dwindling somewhat and to keep the focus alive, we MAY need to concentrate resources of the machines we are inheriting today.

For example, no one was using a TV as a monitor even as far back as 5 years ago. Today, many of us are using HDMI for BOTH monitor and sound! For these to work properly OOTB for users, resource commitments must be dedicated to determine PC cabling: if it is done for BOTH 32bit and 64bit that constitutes DOUBLE the resources needed to develop as well as DOUBLE to support as the 2 distros are different.

This is just one example not to mention Tovald's own statements about 32bit: Including the manufacturers and distro builders movements

Again, this just a comment as I observe where technology has brought us to. And, again, 32bit past PUP distros still work amirably on 32bit and 64bit PCs. The concern I raise is "going forward".

Oh, in case it is missed in my words, UEFI and Secure boot needs the attention that this thread is shedding light upon. So, I draw attention that it should be focused for booting 64bit PCs seeking ways to make that the primary approach future WoofCE PUPs address for booting. 2020 WoofCE seems to have added GRUB2 and EFI to move the needle. Now it'll need some more nudging toward key-management and GRUB2 utilities built-into the 2021 PUPs-DOGs for all 64bit PC use; no users should be required to install these!