Optionally produce installable, bootable BIOS and UEFI ext4 images

[dimkr]

I want Vanilla Dpup to have one working installer that covers at least 80% of use cases. Right now, it has two installers, neither supports UEFI. I don't like the idea of using binary blobs from an unknown source (like FrugalPup's EFI executables), and avoid the use of .pet packages at all costs (so PPM can be replaced in the future).

This installer is simple and easy to maintain: only extlinux or efilinux, only ext4, only frugal installations. There's only one configuration option: a checkbox that allows the user to disable the ext4 journal, to minimize writes at the cost of possible corruption on power failure.

BUILD_ISO=no activates the generation of these bootable images - the default is to build an ISO, with the old installers.

Tested on a virtual SCSI drive, a virtual NVMe drive, BIOS and UEFI (secure boot off).

[peabee]

As long as it remains option - no views. Unlikely to select it as an option in my builds. Does it have to be part of Woof-CE? An external prog to manipulate the contents of /sandbox3/build could achieve the same outcome if a builder wanted to package differently?

[01micko]

As long as it remains option - no views. Unlikely to select it as an option in my builds. Does it have to be part of Woof-CE? An external prog to manipulate the contents of /sandbox3/build could achieve the same outcome if a builder wanted to package differently?

Lets face the fact that many (not all) machines do not ship with an optical drive these days and has been so for at least 10 years. Why dd in iso to a stick/card when an image is more flexible?

[gyrog]

You can uefi boot from ext4?
Usually uefi "esp" is on a small fat32 partition.

[dimkr]

Does it have to be part of Woof-CE? An external prog to manipulate the contents of /sandbox3/build could achieve the same outcome if a builder wanted to package differently?

I think it's better to make this part of woof-CE, because 3builddistro, the images and the installer depend on each other's behavior. For example - the image building script assigns partition labels, and the installer looks for them. Other installers won't work with these images, and need to be removed during 3builddistro. It's kinda ugly (and super slow) to unpack the SFS, remove the old installers, then rebuild it, in a script that runs after 3builddistro.

Lets face the fact that many (not all) machines do not ship with an optical drive these days and has been so for at least 10 years.

And the forums are full of complaints about things like inability to produce a bootable flash drive using the ISO, inconsistent support for UEFI across different Puppy flavors, etc'. I want to put an end to this, and I don't mind if this proposed solution covers only 80% of cases (for example, it doesn't support dual boot, doesn't support other file systems, and doesn't support "full" installations).

You can uefi boot from ext4? Usually uefi "esp" is on a small fat32 partition.

Yes: the image contains a small FAT32 ESP, and a large ext4 partition.

[CollaboratorGCM]

I am like @peabee

Asking this in its simplest understanding, if an ISO file and an IMG file is merely a packaging of the Linux bootable content, does either have device dependence. Yes, we know ISOs were created as a distinguisher during the days of CD&DVDs. And we know that IMG files are also a distinguisher for thing capture or writable to HDD/SSD/USBs. Today, both Hybrids and disk images can be written by similar 'dd' commands. But a distinguisher is an identifier of compatibility, not one of content.

Further each person, here, knows that PUP ISOs are a form of Fugal and can be run as a frugal by merely booting its ISO file.

Lastly, in QEMU via the cli or the current GUI that is shipped, one can boot the PUPs ISO file and @barry's IMG file as well, directly to desktop.

QUESTIONS

• Am I missing something in this?
• Is this an attempt at some specialization that is missing in the industry or in PUPs?
• Is this a boot enhancement for booting and management of PUP's boot that other industry distro developers have overlooked for booting files directly to desktop?
• Or is this some facilitator that has been overlooked?

[dimkr]

* Am I missing something in this?

Maybe.

* Is this an attempt at some specialization that is missing in the industry or in PUPs?

If "a simpler kind of deliverables that is easier to produce and easier to use" or "working installer" means "specialization", I guess the answer is "yes".

(I'm ignoring other questions, because I don't understand them.)

[CollaboratorGCM]

Then, if I interpret your answer to mean "this is a fork" of some industry approach.

Or if I mis-interpret, this is something 'new'. It departs from the past.

[dimkr]

Then, if I interpret your answer to mean "this is a fork" of some industry approach.

Raw disk images - are they an "industry approach"?

Or if I mis-interpret, this is something 'new'. It departs from the past.

It does depart from Puppy's tradition: raw disk images with ext4 are not the same as .iso images.

[dimkr]

Stay tuned: updates will come in a separate PR 😸

[gyrog]

grub2 can directly boot an image file, by booting using the files inside the image file.
This facility is commonly used to boot a .iso file,
but also works with many other images, I have booted a .sfs file that contained just the Puppy files.
So it could boot an .ext4 image file. but it might get confused by an image file that contains 2 partitions.

[CollaboratorGCM]

I "think" this is known by the developers. But, something else seems to be afoot...I believe.

[dimkr]

I "think" this is known by the developers. But, something else seems to be afoot...I believe.

There's no "anti-ISO conspiracy".

ISO files increase size and complexity, and they're inconvenient to work with (partially, because they're read only).

I know there is a workaround for every limitation of this format, but the people who benefit the most from this format today are tinkerers who have a very specialized setup, like a flash drive with multiple ISO images, with a boot loader installed manually.

I'll say this again: I'm not replacing woof-CE's ISO generation, only adding an alternative. Ultra-orthodox followers of the ISO format images will not be affected by this PR.

[CollaboratorGCM]

Conspiracy??? I never suggested or meant that.

That is NOT what I meant. No, I meant that you are working on something a little different from what has been traditional. That should have seen in that response, earlier.

"something else seems to be afoot" intends to support the effort you are working on with both your efforts and what you already published.

Hope that is correct. And I am looking forward supporting you on that.