F96-CE_4 Latest Stable Release

[Clarity]

Case 1 and Case 2, resulting pictures from above tests.
Case 1

Successful arrival at FirstRUN

V4.jpg (38.58 KiB) Viewed 3516 times

Case 2

STops at F96 console prompt

V5.jpg (20.54 KiB) Viewed 3516 times

[wiak]

I read above tests but can't see what different test was done. Same commandline? What difference do you mean?

[Clarity]

Hi@wiak

can't see what different test was done. Same commandline? What difference do you mean?

Are you referencing the VM stanza options in the 'scenario' or something in the actual 'case' sections?

[wiak]

Hi@wiak

can't see what different test was done. Same commandline? What difference do you mean?

Are you referencing the VM stanza options in the 'scenario' or something in the actual 'case' sections?

I could see you sometimes tried different audio and video options but otherwise couldn't work out what the difference was between the different cases. The all said testing via VM accessing external Ventoy usb and I couldn't identify what was changed each time.

[JustCurious]

what is stable version of soemthing older than F96-CE, for example based on 18.04 ubuntu?
what kind of browser does it have?

[Clarity]

... couldn't identify what was changed each time.

Oh, I see.

What is different is that F96 stops before desktop when Ventoy's "Normal" option is taken vs the GRUB2 option. The screen in Case 1 #3 shows GRUB2 selected which boots to desktop. But if the Normal option is taken, instead, F96 only boots to prompt where the user cannot get it to start the desktop.

The case 2 (2nd screen here) shows where F96 stops when Ventoy's Normal is chosen instead of Grub2

[Clarity]

Just completed test of Ventoy USB on bare-metal. Ventoy's GRUB2 offer is required to get current F96CE v4 to boot to desktop.

Thus, again, as in many past tests of other forum distros, what I find in tests results using QEMU VMs usually map to what I see in bare-metal tests.

CASE 1 on Bare-metal leads to desktop exactly as it did in the VM. And fails to achieve desktop exactly as found in Case 2.

On bare-metal, I ran one additional case.
Case 9 - Do a test starting SG2D ISO file under Ventoy

1. Download SG2D;s ISO to the BOOTISOS folder on the Ventoy USB

2. Boot the USB selecting SG2D

3. When Ventoy offers GRUB2 option, choose it (do not choose Normal)

4. Allow SG2D to proceed to list the ISO files it sees

5. Choose F96

6. F96 boots to desktop

In Case 10 - Only 1 change from Case 9

• Ventoy offers Normal, I chose it;

• Follow all other steps to launch F96

• F96 does NOT boot to desktop

These SG2D tests are done to verify it continues to boot the ISO file, using either ISO file boot-loader method.

This could be useful knowledge to those who boot the ISO file method versus the efforts to remove files from an ISO/adjust F96 boot stanzas.

Hope this demonstrates successful paths for a download and boot approach using the ISO files directly.

[Clarity]

I thought that exFAT support was built-in to this modern distro. But, seems its not.

REQUEST
Could exFAT support be added for future version. I think most know why its important especially those of us who have purchased new USB units that come pre-formatted.

Thanks for this distro and everyone participating to its ability. All subsystems tested work without issues. Will be using this on a daily basis replacing my current FossaPup64 which just dropped due to a power outage.

[one]

Hi @Clarity,

none of the forum puppys will boot in ventoy "Normal Mode", this is not specific to f96-ce ...
(The only one i found able to was DebLiveDaedalus @fredx181, which is not a puppy).

You forgot to test save(file/folder) capability - are you able to create/load a save?

Normal Mode is for the big boys (fedora, debian, ubuntu, mxlinux, endeavour, ...)

peace

PS: all those qemu/ventoy related stuff should be handled in one thread

[mikeslr]

what is stable version of soemthing older than F96-CE, for example based on 18.04 ubuntu?
what kind of browser does it have?

Puppys binary compatible with 'Ubuntus' take their names from the 'development' names used by 'Ubuntus'. Thus, Bionicpup is binary compatible with Ubuntu 18.04 which is also known as Bionic Beaver.
Fossapup is 'binary compatible with Ubuntu Focal Fossa.
JammyPup with Ubuntu Jammy Jellyfish.
Ubuntu chooses code/nick-names in alphabetical order; beginning with 'A' again when it runs out of letters. Thus, Bionic is newer than Xenial.

F-96 is sort of an exception. It is actually a new build of Fossapup, employing an improved woof-build-system, making use of the 'bug-fixes' and 'upgrades' Ubuntu has made to Ubuntu 20 and Fossapup since first published; and some other changes. F-96 was used during its development to distinguish it from the 'old' Fossa. There seemed little good reason to change the name when it was finalized.

Debian also employs 'code/nick-names' during development. Like 'Ubuntus', Puppys binary compatible with debian have names associated with those code/nick-names. Stretch>Bullseye>Buster>Bookworm.

With the exceptions of Quickpup64 and S15Pup, all Puppys binary-compatible with Slackware are named 'Slacko'. Slackware doesn't employ code/nicknames. Both Quickpup and S15Pup are based on Slackware-current. Slackware-current involved some major 'updates'. 01micko, despite devoting most of his energies on 'Woof' had been the creator of Slacko 6 and 7 and had been expected to eventually publish a Slacko 8.

Slackware is know for its reliability, but also for being conservative in upgrading and leaving it to Users to 'flesh-out' a basic system with other than basic applications. Slacko Puppys are known for often providing superior graphics and sound; but 'fleshing them out' inherits Slackware's approach. In the absence of code-names, you'll often have to search for the dates when Slackos were first published. Usually the opening post of their threads will indicate, or provide a clue.
Similar naming issues occur with Puppys found in the 'Derivatives' Subsection. Thus, FriendlyFossa and Jackalpup are a newer builds of Fossapup.

Addressing your question directly:
Fossapup64 is newer than Bionicpup64, but older than F-96. You'll find some 'JammyPups' in the 'Puppy Derivative' SubForum which were also published between those two. 'Another Jammypup' is only slightly newer than F-96. It is the only 'Jammypup' which has attracted the efforts of those other than its creator. Bookwormpup is the first 64bit debian-binary-compatible to be assigned to the "Mainline" SubForum. But josejp2424 has published several binary-compatible with debian or its fork, devuan. The primary distinction between devuan and debian is that the former only employs open source applications. You might want to try this one, https://www.forum.puppylinux.com/viewto ... 799#p26799 published in May of 2021 and based on --I think-- the equivalent of debian bullseye.

[stevie pup]

employing an improved woof-build-system, making use of the 'bug-fixes' and 'upgrades'

So if it's so much "improved", how come so many of us have been experiencing problems getting it to boot? Just wondered.

[mikeslr]

employing an improved woof-build-system, making use of the 'bug-fixes' and 'upgrades'

So if it's so much "improved", how come so many of us have been experiencing problems getting it to boot? Just wondered.

I don't know. Maybe because during its development stage it Devs got distracted by concerns about trying to get it to boot in other than the 'usual' methods: an ISO burnt to a USB-Key or manually decompressed with contents copied to a folder.

Or maybe it didn't get your feed-back during the development stage. Personally, I've never had a problem booting it using the 'usual' methods with my two main computers; not even from the earliest builds.

[dimkr]

employing an improved woof-build-system, making use of the 'bug-fixes' and 'upgrades'

So if it's so much "improved", how come so many of us have been experiencing problems getting it to boot? Just wondered.

Problems that don't get reported in time and problems nobody volunteers to investigate and fix in woof-CE will just stay there and "infect" every new Puppy.

If you want to get something done, do it and don't complain.

[rockedge]

So if it's so much "improved", how come so many of us have been experiencing problems getting it to boot? Just wondered.

What exactly won't boot? Are you refering to F96-CE_4?

What type of machine, storage media boot type UEFI or BIOS?

The post is too vague in in detail to begin to diagnosis

besides @dimkr's snide remark, (or should I reword it to an ("aggressive statement of fact" ??) F96-CE_4 is designed AND tested to boot on many different machines and various popular storage mediums.

[Chelsea80]

@ rockedge

If I have missed the lists, then my apologies -

It might be helpful if you post a list of different machines that F96-CE_4 has been tested to boot on -

It might be helpful if you post a list of various popular storage mediums that F96-CE_4 has been tested to boot on -

Again, apologies if this has already been done, if so then just ignore this post -

Best regards -

Chelsea80

[Clarity]

Hi @one. THANKS for sharing this helpful info

... You forgot to test save(file/folder) capability - are you able to create/load a save?
...

Ha! you hit my nail on its head. And I am currently struggling to create a document that is clear and accurate addressing all of the methods the different families of forum distros use for going from pristine boots (or normal boots) to session saves and things to pay attention to. The document will attempt to be well structured, easy to follow, simple approaches and accurate for each of the distro families this forum has.

Today, the information is scattered for each distro family by many users and developers for years. So I feel a "common document for forum distro families and maybe some add'l media' could be useful for many user purposes.

Your Question's answer: Yes. Pristine to desktop, system changes, "sessionsave-option" presented aimed at the Sessions folder on Persistence at shutdown. You may have noticed, that if you have a SAVESPEC file in your BOOTISOS folder at boot-time, your WoofCE PUPs will incorporatte that for its savefile/save-folder processing on both booting and shutdown. A clever file approach done several years ago by @gyrog for WoofCE PUPs.

Are you having problems?

... PS: all those qemu/ventoy related stuff should be handled in one thread

In time, this is coming.

Where we had a reasonable stable period of booting ISO files without issues, I have recently been noticing some anomolies that are showing up in specific alpha-beta forum distros (mainly WoofCE versions for now). When something changes, it is noticed in tests of the specific distro and reported on the distro's page for its developer to know. And, I enclose stanzas allowing recreation of the problem, if the developer is unaware of it occurring. Thus, my current feeling, for now, is to help development (and its users) to know what is found that is working, continues to work, and may need attention or understanding.

That is the reason, why, for now, I post to those developer's thread for their distros.

I agree, with you, that some sort of a common thread could be a useful section for Virtual Machines info for users.

[mikeslr]

So if it's so much "improved", how come so many of us have been experiencing problems getting it to boot? Just wondered.

What exactly won't boot? Are you refering to F96-CE_4?

What type of machine, storage media boot type UEFI or BIOS?

The post is too vague in in detail to begin to diagnosis

besides @dimkr's snide remark, (or should I reword it to an ("aggressive statement of fact" ??) F96-CE_4 is designed AND tested to boot on many different machines and various popular storage mediums.

stevie pup has a thread on which the most details are provide here, https://www.forum.puppylinux.com/viewto ... 260#p88260: 4 different computers (from the OP using 3 different USB-Keys). The specs of none of those are provided. How each key was setup is also not provided. But the thread suggest that his efforts involved Ventoy, SG2 and Rufus. Whether my instructions regarding using rufus were followed is not mentioned. Rufus had the best results. But it took 5 minutes to boot to desktop.

If stevie pup is interested in solving these problems, I'd suggest the following:
(1) Start one thread for each of the 4 computers.
(2) Despite the time it takes, use the rufus built with each of those and after it boots to desktop, run Menu>System>Pupsys-Info and make a copy of each computer's relevant specifications that might effect boot-time. Perhaps you could identify which they might be.

As --despite the delay-- it is possible to boot F-96 using Rufus, I'd suggest after boot-up installing grub2config, https://www.forum.puppylinux.com/viewto ... 703#p29703, restarting-X then using grub2config from the running Puppy to 'burn' a version of F-96 to a different USB-Key.

I don't recall anyone who used grub2config having a boot problem. I appreciate that to a large extent grub2config may be a derivative of gyrog's frugalpup (which is built into F-96). But there may be subtle differences. For that matter, I don't recall stevie pup mentioning trying to use frugalpup to create a 2nd bootable USB-Stick from the rufus generated 1st.

Ventoy and SG2 each have limitations which none of us here have any control over or ability to remedy. The only program which enables deploying Puppys from Windows specifically made for Puppys is LICK, viewtopic.php?p=1587&sid=2a8a1aca40724f ... 9775#p1587. noryb009 --its creator-- has not been active for a couple of years. Although it can still be used, like rufus, frugalpup and grub2config it writes the grub2boot-loader, but uses I believe an older version.
[I don't know of any of us who have noryb009's Windows programming skills. If not, the most we could do would be to publish a fork merely updating the version of grub2 it uses].

AFAIK, there is no isobooter.exe (i.e., a version which runs under Windows). There are other applications/programs which can be used to burn Puppys to a USB-Key (or CD). But using any you end up with an ISO...something device (READ-ONLY) which can only to be used via Puppy tools to deploy another Puppy capable of preserving changes ('persistence').

[wizard]

@mikeslr

I'd suggest after boot-up installing grub2config,

Grub2config is already built in to F96.

wizard

[Clarity]

Hi @mikeslr. You may not have created a Ventoy USB. IT IS FABULOUS in the approach those authors took. They, like me, had witnessed for years the problems users have in creating bootable USBs. So they formulated a foolproof method.

There is no way to get it wrong. It creates a bootable USB EVERY time without issue and in a very straightforward fashion

Run its script or program...OR boot its ISO. Each path shows the user exactly the same screen to create the USB if you want to use its GUI. Otherwise, the terminal approaches to do the same are exacting too.

Merely creates your bootable USB in about 30 seconds. I advise to, then,

1. add a BOOTISOS folder on USB's partition 1

2. place ALL ISO/IMG files in the folder

3. boot the bootable Ventoy USB

I also continue to advise to add the SG2D ISO file to the BOOTISOS folder because some WoofCE and forum distros wont boot via Ventoy, but do boot via SG2D. So, it is a fall back.

Hope this is helpful to see accurately what is being shared. And, is helpful in understanding what we are seeing in recent booting WoofCE PUPs that is being exposed.

[Clarity]

For its tiny size but its benefit, would @ETP's 'Conky Toggle' switcher be of benefit to the ISO?

Evaluate for value.

[Clarity]

Hello @one I have an update on saving sessions after a pristine boot of F96. This applies to EVERYONE booting this distro.

Hi @one. THANKS for sharing this helpful info

... You forgot to test save(file/folder) capability - are you able to create/load a save?
...

...
Your Question's answer: Yes. Pristine to desktop, ...
Are you having problems? ...

@gyrog is the creator of a faciility allowing WoofCE PUPs to discover, automatically, where the sessions exist on the system. BUT, F96 doesn't seem to be picking it up upon boot even though the SAVESPEC is present in the folder where all ISO files are kept. As this can be viewed as a bug, we'll need to appeal to @gyrog, one of the WoofCE developers for clarification on this feature on these recent PUPs.

This is requiring that at the F96's boot menu, you MUST add "psave=..." parm to manually tell the PUP where sessions are housed. On my system, for example, I have a directory "Sessions" on the HDD partition labeled "Persistence".

My PSAVE parm is psave=Persistence:/Sessions/ no other edit changes are required for the PUP to find his sessions OR to KNOW where to save sessions to, if this is a pristine boot.

We'll have to await @gyrog for comment on why his feature is no longer working, as this problem "seems" recent.

Its important to note that this single feature eliminated user boot-time edits in order for PUPs to boot and know where sessions are to be stored or found. This automation was a feature of the WoofCE PUPs for several recent years

[gyrog]

@one
When booting an ISO file, there are 2 files in initrd.gz that need to work to properly process a SAVESPEC file, "init" and "/sbin/isoboot".

The "init" script looks fairly old, but ok, the "isoboot" looks ok, BUT there is a mismatch between the "isoboot" and the "init".
The "isoboot" expects the "init" script to contain a "wait_for_dev" function, but the included version of "init" does not.
This issue would only come into play if there is no "iso_dev=" boot parameter specified.
Although I would expect this to cause the boot ot crash, not cause a SAVESPEC issue.

So, could you please report any lines in "/initrd/tmp/bootinit.log" that start with 'Using'.

It would be interesting to see if using an "initrd.gz" from a different Puppy would aleviate the problem, try one from a recent 64bit Puppy.
But it you are booting an ISO, then you get the "initrd.gz" that's already in the ISO.
(Grub2 doesn't actually boot ISO files, it boots using the Puppy files contained in the ISO; I've tested this by booting a .sfs file that contained no bootloader, just Puppy files.)

[wizard]

@Clarity

For its tiny size but its benefit, would @ETP's 'Conky Toggle' switcher be of benefit to the ISO?

You can start or stop Conky from the gear menu on the far right of the JWM tray.

wizard

[geo_c]

@Clarity

For its tiny size but its benefit, would @ETP's 'Conky Toggle' switcher be of benefit to the ISO?

You can start or stop Conky from the gear menu on the far right of the JWM tray.

wizard

Yeah that's a nice feature in F96.

[stevie pup]

stevie pup has a thread on which the most details are provide here, https://www.forum.puppylinux.com/viewto ... 260#p88260:
If stevie pup is interested in solving these problems,

Thank you for pointing that out Mike, much appreciated. I'm afraid I can't really be bothered to devote any further time to this issue, well certainly not at the moment anyway, and don't need to. Last few weeks I've been trying out BookwormPup, and so far have nothing but praise for it. Fair enough that wouldn't boot from Ventoy either, but from a Rufus USB it was fine. No delays in the boot process, no claims it couldn't find something, no issues at all.

Installed Bookworm to a portable HD, again no problems. One minor hiccup along the way, which was my own doing, and everything's great. So I know what I'll be using going forward. And I still have my installation of Fossa 95.

For what it's worth, the only point I was trying to make was this. In the past I have had no boot problems with either Bionic32, Bionic64, Dpup Stretch, BusterPup or Fossa 95. It's only with the more modern Puppies that these boot issues have arisen. So something has changed, but I'm not clever enough to figure out what.

[Clarity]

Booted pristine. Installed QEMU v8 PET from forum
Result

Screenshot.jpg (75.42 KiB) Viewed 3573 times

I have downloaded this PET twice. Older one is 31MB while recent is 33. Each time same error message.

I know others have reported this PET working.

Any ideas. (I am planning to fallback to an earlier QEMU version)

[Clarity]

Hi @gyrog

...So, could you please report any lines in "/initrd/tmp/bootinit.log" that start with 'Using'. ...

Here's an example of failure:

1. From the boot-loader list, the distro ISO file is selected

2. It starts its boot, then drops with no messages to a GRUB prompt

3. At the prompt, 'debugsave' command creates the report (a set of log files) on a drive the user specifies.

I renamed folder of text+log files to something more meaningful, and present it here as a zip file.

DebugsavE_logs.zip

(32.75 KiB) Downloaded 75 times

To help, any follow-ups you would like to see, let me know.

[one]

[...]

So, could you please report any lines in "/initrd/tmp/bootinit.log" that start with 'Using'.

[...]

Hi @gyrog,

thanks for your response.

First, I describe my ventoy setup: I created a 64 GB stick with Ventoy (Disk Layout in MBR to support my legacy bios system), two partitions.
The first (originally exfat) is formated ext3, the second is the fat16 VTOYEFI at the end of the stick. That's it - I didn't reserve some disk space at the bottom of the stick, so the saves should be placed in a folder called 'Sessions' on the first partition (per Savespec).

In the first partition is a directory BOOTISOS with various isos and the SAVESPEC file. There is also the mentioned directory called 'Sessions' for the the saves.
------------------------------------------------------------------------

I have to boot FP96_CE in GRUB MODE (Normal does not work) where ventoy emulates the ISO file as a CDROM to boot it. (The iso has to contain grub2 configuration file.)
FP96_CE boots ok, but no save (file/folder) is created in 'Sessions'.

Code: Select all

SS_ID='Ventoy'
SS_DIR='/Sessions'
SS_MEDIA='usbflash'

I attach the requested bootinit.log - there is no line with 'Using', so the SAVESPEC is not used to direct the saves to 'Sessions'.

PS: this "problem" only arises in my ventoy-setup - when using my normal frugal install method with grub4dos the SAVESPEC mechanism works absolutely ok. Thanks for that ...

PPS: it seems the whole partition sdb1 is seen as ISO 9660, so no save possible.
peace

[one]

[...]

This is requiring that at the F96's boot menu, you MUST add "psave=..." parm to manually tell the PUP where sessions are housed. On my system, for example, I have a directory "Sessions" on the HDD partition labeled "Persistence".

My PSAVE parm is psave=Persistence:/Sessions/ no other edit changes are required for the PUP to find his sessions OR to KNOW where to save sessions to, if this is a pristine boot.

Hi @Clarity,

I tried your suggestion and added "psave=sdb1:/Sessions/" to the FP96_CE kernel line. At shutdown it offers to make a savefolder to the ext3 formatted partition in the folder 'Sessions' but shows a negative
value, indicating the whole partition is seen as ISO 9660, so ...

peace

[gyrog]

Here's an example of failure:

1. From the boot-loader list, the distro ISO file is selected

2. It starts its boot, then drops with no messages to a GRUB prompt

I suspect that you are experiencing the mismatched 'isobot' file in 'initrd.gz' issue I mentioned.
Could you please replace the 'iniitrd.gz' in the ISO file with one from a n ISO that will boot.