F96-CE_4 Latest Stable Release

[gyrog]

@one,
From the bootinit.log, it seems that the boot is confused from the start.

You are booting from a usb stick, right?
Is Puppy installed on the usb stick?

Or in /dev/ventoy, which is the ISO file?
In this case, the problem is that the 'init" script is not recognising it as either a CD or as an ISO, but as a regular partition.
In this case the SAVESPEC would need to be in that partition i.e. in the ISO.

Also, in the SAVESPEC file, you have

Code: Select all

SS_ID='Ventoy'

is 'Ventoy' a partition label on the ext3 partition?
If not the SAVESPEC isn't going to work anyway.

[Clarity]

Hum??? Something odd. 'SAVESPEC' file in the BOOTISIOS folder on the USB partition labeled Ventoy with the ISO files... contents show

Code: Select all

SS_ID='Persistence'
SS_DIR='/Sessions'
SS_MEDIA='atahd'

REviewing my notes indicates the boot media is accurately structured for PUPs to discover the Session requirements.

Ventoy is the label of booting USB.

That should be correct. ????

Could something in INIT be at odds with location of boot materials?

There are NO changes to any PUP boot stanzas allowing the PUP menu to default and start its boot. It then proceed until it stops at the GRUB prompt. It is where a user can capture debug info. Only option from here is reboot.

Again my notes indicate this is rather recent surfacing of this boot problem.

[one]

@one,
From the bootinit.log, it seems that the boot is confused from the start.

You are booting from a usb stick, right?
Is Puppy installed on the usb stick?

Or in /dev/ventoy, which is the ISO file?
In this case, the problem is that the 'init" script is not recognising it as either a CD or as an ISO, but as a regular partition.
In this case the SAVESPEC would need to be in that partition i.e. in the ISO.

Also, in the SAVESPEC file, you have

Code: Select all

SS_ID='Ventoy'

is 'Ventoy' a partition label on the ext3 partition?
If not the SAVESPEC isn't going to work anyway.

Hi @gyrog,

- yes, I boot from an usb stick.
- no, fp96_CE is not installed - it is ventoy's task to search for isos and present them in a menu, from where I choose the fp96_ce-iso
- the disk layout on the disk is created by the ventoy install script for linux (ventoy2disk.sh)
- now there are two partitions (small sdb2 is labeled 'VTOYEFI' at the bottom of the stick, large sdb1 is labeled 'Ventoy' by myself)

This is the normal ventoy disk layout for MBR!

- the ventoy script formats sdb1 to exfat - I myself changed that to ext3
- I created a 'BOOTISOS' directory in sdb1 to contain different isos, here is the fp96_ce.iso
- I created a 'Sessions' directory in sdb1 to contain different saves
- I created the 'SAVESPEC' file I posted before and placed it in the 'BOOTISOS' directory. I think the syntax is correct!?

FP96_CE4.iso boots at least - but no save is possible ...

I created the ventoy stick only because i wanted to see if ventoy is really a reliable method to boot different isos and at the same time can have save-(folder/files).

[gyrog]

I created the ventoy stick only because i wanted to see if ventoy is really a reliable method to boot different isos and at the same time can have save-(folder/files).

I doubt that this will work without modifictions to the 'init' script.
The problem is that what you would like to happen depends on the 'init' script recognising that it is booting an ISO file.
But it only does that if it finds a boot parameter specifying a particular ISO file. This is simply not happening.

My only suggestion that might improve things, is to specify pmedia=cd as a boot parameter.
According to the 'bootinit.log', it was booted 'pmedia=usbhd'.
This may give you a better working system, but I expect that your SAVESPEC will be ignored.

[Clarity]

My Ventoy USB that launches forum distros. SAVESPEC contents shown earlier.

Bootable USB

bootable USB.jpg (71.12 KiB) Viewed 3321 times

BOOTISOS folder contents

bootable USB BOOTISOS CONTENTS.jpg (43.19 KiB) Viewed 3321 times

RECAP

• Sessions are kept on a sysemdrive partition lableled Persistence.

• Persistence has a folder named "Sessions"

All of this is designed around Puppy Architecture. No system mods or exterior files or requirement changes to PUP's boots are done.

Hope this gives a simple and complete picture..

Externally, it appears something in PUP changed.

BTW: SG2D's bootable USB get the same result. Of noe, prior to recent WoofCE PUPs, SG2D would boot forum distro even if Ventoy direct booting was unseccessful. Now, recent pUPs struggle not to boot.

I say this WITH EMPHASIS: there IS NO REQUEST to fix or resolve Ventoy or SG2D. This problem has surfaced in PUP WoofCE boots. Debian and Ubuntu boot just fine via the 2 boot-loaders TOO.

[gyrog]

@Clarity
I'm sure that the problem is an initrd.gz whose ISO booting support is broken.
Could you please rebuild an F96-CE_4 ISO replacing the initrd.gz file with one from an ISO that works.
Then try this test ISO.

This is a known problem in Woof-CE. It was only fixed in Woof-CE this year.
I would suggest an initrd.gz file from an S15Pup.

[rockedge]

F96-CE_4 has a well tested initrd.gz that has proven repeatedly to be able to boot from ISO. Community members have tested F96-CE_4's ability to boot using diverse methods extensively.

@Clarity You have confused me with all the repeated posts referring to Ventoy and Co. whether it will boot or not.

I never use Ventoy on purpose, so if it boots it boots. I use QEMU and VirtualBox and it boots fine from ISO all the time.

You know distro's like Haiku are limited to what machines and devices it will run on. Maybe they do Ventoy, maybe not, but overall Puppy Linux's work on a far broader range of machinery than it does. And the Haiku people will tell you exactly how to set it up, install it and run it and everyone accepts that as fact.

We went down the rabbit hole chasing the Ventoy boot from ISO capabilities with Kennel Linux and it complicated the initrd.gz and boot stanza's considerably and it is not proven that it was worth all the work and added bloat.

[radky]

I'm sure that the problem is an initrd.gz whose ISO booting support is broken...
This is a known problem in Woof-CE. It was only fixed in Woof-CE this year.

@gyrog

The Woof-CE source for the current F96 init is the following commit:

Mar 12 2023
Commit: 4a23874
https://github.com/puppylinux-woof-CE/w ... f43a578ed8

[gyrog]

The Woof-CE source for the current F96 init is the following commit:

Mar 12 2023
Commit: 4a23874

The fix you need was committed on Apr 20.

[gyrog]

I have just successfully booted using 'F96-CE_4.iso' without any modification.

To press all the Puppy buttons, I booted with this grub2 boot entry:

Code: Select all

menuentry "Puppy F96-CE_4.iso (Work)" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root 0db94719-cdf1-44b7-9766-23db62fb85a5
  set isofile="/images/F96-CE_4.iso"
  loopback loop $isofile
  set root=(loop)
  echo "Loading vmlinuz"
  linux (loop)/vmlinuz net.ifnames=0 pmedia=iso iso_dev=Work find_iso=$isofile pfix=fsckp TZ=AEST-10
  echo "Loading initrd.gz"
  initrd (loop)/initrd.gz
}

Note the "iso_dev=" parameter on the "linux" line.
This enabled the 'init' script to "miss" the bug.

This boot entry was produced with:

Code: Select all

./isoBootEntry /mnt/home/images/F96-CE_4.iso

I have attached the 'isoBootEntry' script.
This is a rather raw script, make sure you provide a single parameter, the full path to an ISO file.
The output is back to the termnal, so it can be easily redirected to a file.

I have also attached the 'bootinit.log' file, of a successful boot.

[Clarity]

HI @rockedge

Yes, I remember the effort that went into KL's init processing. And as a result, along with @fatdog , KL's boot via all of my testing in the boot-loaders.

Those dsitros ISO files boot from all boot loader USBs, & QEMU. In addition, the USBs will also boot within QEMU giving the same results seen on bare-metal.

This is NOT, again I repeat, is NOT a request for fixing or addressing anything associated with what the boot-loaders do. It appears those developers do a good job supporting their products with fixes and advaces.

But, when forum distro things were working and they stop working, I am raising the flag to let developers and user of a recent change that may be affecting forum distro booting from their ISO files..

This is the case with several recent development efforts underway in alpha and beta stages.

So, I am trying to give the community rhe reports such that they, themselves can validate what I am showing. Best outcome would be user error (I accept any/all responsibility for any I may misinterpret). And I hope that would be the case.

IN any event, we may be, community-wide, better off if it can be contained and explained. If there is an inadvertent change, that would explain differences from release to release in will come out.

Right now, I am attempting to craft all elements to try, best I can, to narrow down the condition. I have, now 4 intel test PCs and 1 AMD looking for differences that may help explain.

Another day or so, I will have all environmental information to point to any specifics that will insure member use of these ISO boot tools are working for all the distros n the forum community.

I think I am close to explaining it al.

[Clarity]

@rockedge and @radky

Is the best way to test @gyrog's by opening the ISO file in ISOmaster and removing to repackage the ISO there. Or should I wait for a test ISO file?

I ask, as, I have never replaced an INIT; while I want to help as best I can.

P.S. iF NEWER F96s are planned, what can be done to have exFAT support for filemanager and Gparted detection.

[gyrog]

I just did a test to confirm my diagnosis:
I removed the "iso_dev=Work" parameter from the "linux" line of the 'grub2.cfg' boot entry, and booted with that.
I got the very first line on the console, but then it simply dropped out to the console terminal mode, without any message.

[radky]

The Woof-CE source for the current F96 init is the following commit:

Mar 12 2023
Commit: 4a23874

The fix you need was committed on Apr 20.

@gyrog @dimkr

If I understand correctly, commit: 1369b50 (20 Apr 2023) is a partial reversion of commit 64427d7 (22 Mar 2023).

Specifically, is commit: 1369b50 (below) the appropriate init update for F96 ?

commit: 1369b50
https://github.com/puppylinux-woof-CE/w ... afcae77c6c

[dimkr]

@radky I don't know which commit F96-CE_4 was built from, and which modifications were made. Not having 1369b50 applied is a good explanation for these boot failures, and it's very easy to check if this is it or something else entirely, by looking at bootinit.log.

[gyrog]

Specifically, is commit: 1369b50 (below) the appropriate init update for F96 ?

Yes.

[gyrog]

Really sorry, but when I suggested to use the 'initrd.gz' from another Puppy, I ommitted 1 important detail.
The 'DISTRO_SPECS' file in the borrowed 'initrd.gz' has to be replaced with the F96-CE_4 'DISTRO_SPECS' file.

Apart from this 1 file, Puppies are fairly agnostic about their 'initrd.gz', as long as it establishes the stack and sets up PUPSTATE appropriately. So newer 'initrd.gz' will usually work.

I have an 'F96-CE_4.sfs' that boots fine, with the 'initrd.gz' borrowed from S15Pup64, if anyone is interested.

[greengeek]

Normally I am a 99.999% 32bit Puppy user but I am being forced to seek better performance when handling Android phones so I am trialling F96-CE_4 and I think it is great.

Currently using the Opera portable from rockedge's site https://rockedge.org/?page_id=1013 which I load into Spot and it is really quick and tidy.

Running on an HP Elitebook 2540P which is my favourite small laptop for travelling as it still has inbuilt optical drive.

Love the grey themed wallpaper and icons. Very professional. Really enjoying this.

[amethyst]

I've eventually downloaded this. When booting it hangs at "booting kernel" for quite a while before eventually getting to desktop. Sound works (unlike the other original FossaPup which is dead). Had to switch internet connection manager since connman is useless for my purposes of setting up a "hidden" wifi connection. Made a save file after the switch and then bootup took quite a while to update the icon cache (first up with new save file), Ran Dougal's to set up wireless (didn't work but this happens with some other puppys too so maybe not an issue, probably get it right with more effort/patience.) Runs slower on my machine than DPupBuster64 which I also spent some time on over the weekend (probably because of Conky, etc. but didn't disable the latter to see if any improvements). It was easy to set up things with DPupBuster64 and everything worked first time. I was also able to use an old, small Tahr64 kernel with DPupBuster64 which I can't with this Puppy. So - I'll continue using Bionic32 as my daily driver as everything is nicely set up and working with lower resource requirements. I only need 64-bit to watch DMR content on the odd occasion and will probably use DPupBuster64 then instead as it runs better on my machine.

[geo_c]

I'm posting this here because F96 is the OS I'm experiencing the issue.

The issue is I have perfectly functioning pulseaudio and volume control on machine A, but when I backup up the savefolder, copy it to machine B (a normal puppy procedure), and boot up, pulseaudio is unable to start.

I've tried using rollback savefolder versions to make sure it wasn't something I installed, but like I said, works perfectly well on machine A. And pulseaudio works fine on machine B if started in RAM pristine, so it's not a driver issue or anything like that.

Trying to open the pulseaudio volume control built into F96, I get the message that root window x11 is misconfigured, or perhaps dirty files were left and autospawn will initiate in 5 seconds, which it doesn't. Trying to start pulseaudio manually (the message suggests start-pulseaudio-x11 but I've used a few diffferent commands, it still fails.

I'm not bashing pulseaudio, because when it's working it's really convenient. But it does seem to be a lot buggier in the puppy root-user environment than say bare alsa. I find alsa and alsamixer to be very consistent.

Trying to run alsamixer of course the mixer can't connect, because it's trying to connect to pulseaudio which isn't running.

Wondering if anyone else has run into the issue of a working F96 audio config on one machine not working anymore when the savefolder is backed up and copied to a new machine.

Seems fixable, but I don't have a clue.

[Geek3579]

I have never had that specific problem, but have had issues at odd times using pulseaudio with Fossapup64, which is close enough maybe.

I restart pulse audio with "run-as-spot pulseaudio -D" but I'm not sure if it runs as spot in F96, so just try "pulseaudio -D" which starts the daemon
You could also try "pulseaudio –start", which I use with pulseaudio in debian dogs.

[geo_c]

I restart pulse audio with "run-as-spot pulseaudio -D" but I'm not sure if it runs as spot in F96, so just try "pulseaudio -D" which starts the daemon
You could also try "pulseaudio –start", which I use with pulseaudio in debian dogs.

I've tried all of that, except adding the -D option. In F96 run-as-spot didn't work, I'll have to do it again to reference the error.

[rockedge]

try sudo -u spot pulseaudio -D

[geo_c]

try sudo -u spot pulseaudio -D

Just to reiterate my issue. This savefolder is working perfectly on Machine A, and I backed-up/copied the savefolder and booted on machine B. Pavucontrol gave the following message on machine B and continues to do so, even though I finally had success starting pulseaudio with pulseaudio -D:

EDIT: Seeing below that starting pulseaudio as root doesn't allow access by applications to pulseaudio, could it be that in the backup/copy process, somehow my spot user or folder or folders associated with spot had their permissions changed?

This shows the pulseaudio start commands I tried in the terminal. (not shown is sudo -u spot pulseaudio -D which returns "permission denied" from the spot directory.

EDIT: here's what I get using the sudo -u spot command:

And this shows that after using pulseaudio -D pulseaudio is in fact running as root. But as stated, pavucontrol still displays the above message.

[geo_c]

EDIT: Seeing below that starting pulseaudio as root doesn't allow access by applications to pulseaudio, could it be that in the backup/copy process, somehow my spot user or folder or folders associated with spot had their permissions changed?

Maybe instead of copying my savefolder using a file manager (Xfe), instead I should use terminal: cp -arv

[geo_c]

Maybe instead of copying my savefolder using a file manager (Xfe), instead I should use terminal: cp -arv

WOW, that did it!

[PULSEAUDIO ISSUE SOLVED]

so using the cp -arv command to copy my backup save from one machine to another solved the issue of pulseaudio not working on the target machine.

I remember @fredx181 suggested this to me when I was copying upper_changes to different installs of KLV-airedale, and I used that method ever since.

Never had the issue with pupsaves though until now. I wonder if there are settings in the file managers, specifically Xfe that can be tweaked to avoid this. It's either permissions or links I imagine.

[rockedge]

@geo_c I have seen this happen also when constructing the KLV-Airedale root_fs that occasionally during a copy to set up the uncompressed root_fs that the /home/spot and /home/weedog will be copied with root ownership, which breaks things. I ensure before SFS creation that these have the correct spot and weedog user ownership.

A simple thing but can cause a lot of grief but easy to fix.

[bigpup]

Much newer version of Deadbeef available here:
viewtopic.php?t=9021

Seems to install and run OK in F96-CE_4

A lot of changes and bug fixes that are not in the Deadbeef that comes installed in F96-CE

[Subito Piano]

Trying F96 out via USB install. Bluetooth just WORKS! (OK, I fiddled a bit, but nothing one couldn't figure out.) So does PupMTP mount - kudos!

I couldn't choose a place to save bluetooth files, I mean, if I could choose a location, they weren't there. I searched and found them in ~/spot/.cache/obexd. Okay, no big deal, I put a link in my home directory and renamed it "Bluetooth Files" so I can access transfers easily. That said, it would be nice to not have to have bluetooth running as spot, so I can put transferred files in the correct spot...er, the correct FOLDER when first received. I recall seeing instructions for making apps run as spot every time; searching today I can find how run apps as user "spot" via commandline, but cannot find how to make an app run as a regular user when it's set up to run as spot. How to do?

[Subito Piano]

"UPGRADING"

I've been using FossaPUp for some time, now planing to switch over to F96-CE (version 4). I know kernel upgrades are possible and fairly simple, but is it possible to "upgrade" from FossaPup to F96-CE, since F96 is based on FossaPup?

I tried this out by installing F96 in a new directory "F96-CE," making backups as a precaution, then copying my fossapup64save file from my previous FossaPup directory into the new F96-CE folder. I received a warning that basically stated "Do you want to upgrade? It's not recommended" and chose yes. It booted into a pristine load of F96, just as if I'd loaded F96 with the pfix=RAM option.

Upgrading theoretically would save a lot of time and headaches -- yeah, I say theoretically knowing it might cause even worse headaches.

Frugal installs, BTW, each in its own directory in /mnt/home

Words of wisdom appreciated. Thanks!