F96_4-CE 4th Gen Dev Tester with a New Kernel 6.0.9 Made for F96

[dimkr]

Changelog:

If none of these changes are pushed into woof-CE, nobody would be able to release a 9.7 after 9.6. The same thing that happened with 9.5, again.

[rockedge]

I totally agree with @dimkr that all of these changes need to be merged into woof-CE so the next builds of Fossapup64-CE will be FP9.7 and be exactly what we have here in F96_4-radky2 but coming off of the woof-CE assembly line.

I also agree with @bigpup that Conman should be the default network manager but have the other 3 available and ready to go if needed for those cases a more configurable network manager is needed. There is enough room to keep them in the rootfs SFS.

Now to figure out how to exactly add the needed changes and fixes to a woof-CE fork/branch and request a push merge up stream tot woof-CE GitHub master branch.

[wizard]

@mikewalsh

Mike, just a heads up, these Pups are using pulseaudio. I just tried your latest Firefox Portable, the Launch script opens FF, but looks like any attempt to play audio crashes the tab. Opening from /Firefox-portable64/firefox64/firefox does work and audio plays as you would expect.

Thanks
wizard

[Clarity]

@radky this version you have boots easily via QEMU and SG2D to desktop without issues. I added @ETP;s Chrome browser installer and all is fine. This is a key, Thanks for this as it appears so very polished and attractive.

This version discovered on boot the session folder with your prior version's save without problems or intervention of the PUP's boot stanza to direct it.

@wizard's spreadsheet is masterful depiction of a test-bed approach to reviiewing some app behaviors. Thanks @wizard

[mikewalsh]

@mikewalsh

Mike, just a heads up, these Pups are using pulseaudio. I just tried your latest Firefox Portable, the Launch script opens FF, but looks like any attempt to play audio crashes the tab. Opening from /Firefox-portable64/firefox64/firefox does work and audio plays as you would expect.

Thanks
wizard

@wizard :-

Uh-huh. See what ya mean. Had a look in my own Fossapup64 9.6 'test-bed', and bingo! - there's pulseaudio in /usr/bin. I've just re-built Firefox-portable to include a manual selector after you launch, along with some extra sym-link trickery in the "extralibs" directory; you just choose which audio mode you want to run with. Too late to upload it tonight - wayyy past my bedtime - so I'll upload it tomorrow.

Or I could make it automatic; not everybody either knows OR cares about details like that. What'cha think? Oz has given me an example via PM of how he's handled it, so.....we'll see. I always think it's strange, the way Mozilla have built FF to work; the 'clones' auto-detect whatever sound-system you're using and just run, regardless (another reason why I prefer them).

Mike.

[mikewalsh]

@wizard / all :-

Okay; the updated 64-bit Firefox-portable is now uploaded. I didn't bother with the 'manual' selector in the end; the version as uploaded auto-detects whether PulseAudio is present or not.

If PulseAudio exists, it'll fire-up using just libatomic. If it doesn't, then it'll use libatomic AND the 'apulse' items. Runs fine in Fossa 9.5 AND Fossa 9.6; 9.6 uses PulseAudio, 9.5 doesn't. Seems happy in both Puppies.

As uploaded this should even run from an OOTB FAT32-formatted flash drive......I've been careful to make sure there's NO sym-links!!

If anybody wants it, I'll modify the current ESR variant to work the same way. I'll probably get around to modifying the 32-bit versions as well before long.

Mike.

[Jasper]

Hi all

I wanted to get some advice on how to include my WiFi drivers into the new ISO.

I have tried the ISO but not having internet connectivity has forced me not to adopt it so far.

So far, I can identify my hardware and have downloaded the driver from the Intel website.
I have extracted it and included in the fdrv by opening it up and adding the files and then repacking. This did not work.
Also, tried copying over the various *.wl files from 9.5CE and that did not work either. Surprised at this as the original fdrv works fine.

On the Intel page it informs me that I should look/use the latest build at:
https://git.kernel.org/pub/scm/linux/ke ... .git/tree/
When I got here, it seemed more than I could move forward.

As with a number of other members reporting APulse libraries drive the audio and some browsers do not function correctly. The same happens to me using Palemoon 31.4.1.

I have tried to use the original 95 fdrv to maintain my network support but then the audio fails. Does this mean that I will be forced to use a portable version as a browser?

Any help/advice/suggestions would be appreciated

Or should I just wait for the finished ISO

[ozsouth]

@Jasper - wifi drivers are kernel-specific. If you change a kernel, you'll need new drivers. To determine exactly what firmware you need, please run the following terminal command & post the output:
dmesg | grep irmware

If the 7265 (or 7265D) firmware is needed, you can simply copy them into /lib/firmware. Be aware there are many version of this firmware,
hence the command above will show exactly what is needed.

Also, F96 uses pulseaudio, so you do not need apulse.

[Jasper]

Code: Select all

root# dmesg | grep irmware
[    0.055577] DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000008d800000-0x000000008fffffff], contact BIOS vendor for fixes
[    0.055578] DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x000000008d800000-0x000000008fffffff]
[    0.123224] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[   28.954214] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
[   28.954227] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
[   30.223520] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27)
[   30.317871] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   30.751590] iwlwifi 0000:02:00.0: loaded firmware version 29.198743027.0 7265D-29.ucode op_mode iwlmvm
[   30.955507] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq failed with error -2
[   30.955510] Bluetooth: hci0: failed to open Intel firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq (-2)
[   30.955543] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.8.bseq failed with error -2

[ozsouth]

Firmware intel 7265D-29 linked & downloaded - is in F96's fdrv. Post redundant.

[Jasper]

@ozsouth

It's not the sound driver that I require, it's my WiFi device.

Apologises for the confusion. My explanation may have not been clear enough.

LOL grabbed the file regardless.

Thank you

[ozsouth]

@Jasper - that linked file IS a wifi firmware one. If you use F96's fdrv (so your audio will work), then add the linked file to /lib/firmware, your wifi should work too.

[Jasper]

@ozsouth

I am a klutz and have seen that the file you supplied is the file that I need

Will try it out and let you know if I get myself up and running!!

Thank you again

[Jasper]

@ozsouth

I extracted the fdrv and then added the *.7265 to the firmware library.
It informed me that there was an older version already contained within and this new file would overwrite the existing one.
Repacked the directory and then copied it over to the USB flash drive that I had already installed the 96-4-CE.

Upon booting up it did give me an few lines of code complaining of an Intel Bluetooth error message.

However, got to the desktop and setup my local settings.

I could not connect again as it appeared that only a wired connection was available to me.

On a positive note the Bluetooth manager worked well and I connected a speaker. Something I have had difficulty doing in 95.

[radky]

@Jasper

The version of FP96 that you are testing is the original RC4 release, not my modified update which incorporates many fixes plus a different test kernel and more comprehensive firmware package (fdrv). Soon, rockedge will make his final decision concerning the infrastructure and customization of FP96, and this will include his choice of kernel and firmware constituents.

[rockedge]

@radky and @Jasper Definitely I want to use F96_4-radky2 as the further and improved development base system of F96_4-CE.

Once the kernel is decided, which will be the better all-rounder for the release version especially that the firmware covers as many devices as possible, without being to big in size, the new base we will work from now is going to be F96_4-radky2 and it will be called F97_1-CE eventually.

The final name I am considering is FP97-CE or something similar, but this can be determined after some discussion of the overall design. Important is what makes radky2 so much improved over Fossapup64-9.6-CE has to be translated into woof-CE so newly generated Fossa's will be very similar to F96_4-radky2.

I vote on keeping the current desktop design in F96_4-radky2 as we move forward. I am having excellent performance and overall function and I really like F96 soon to be F97

[wizard]

@radky
@rockedge

Here is the updated issue list.

f96-4.xls

(21.5 KiB) Downloaded 60 times

Thanks
wizard

[rockedge]

@wizard starting now F96_4-radky2 will be the base model to work from. Next versions will be expanding, fine tuning and fixing the last most obvious bugs.

The next F96_5-CE will be the followup to radky2.

[Jasper]

Woo Hoo!!!

Finally, I can see what all the fuss is about

@radky build works brilliantly.

It feels incredibly slick and professional.

There is a little bit of tearing visible in video playback via the browser and mpv. For some reason no audio playback in Mplayer. Fine using mpv.

Looking forward to the finished product.

BTW I have only ever used f2Stickpup as the application to install any Puppy ISO on a USB flash drive. Always works perfectly for me. I suppose it's because I am only using a single OS.

[wizard]

@radky
@rockedge

Here is the updated issue list.

f96-4.xls

(21.5 KiB) Downloaded 58 times

Thanks
wizard

[Clarity]

Anyone know how to add the 'tldr' app to this distro?

Help request.

[Jasper]

This sounds a good and useful idea.

The script only needs to be added to

/usr/bin

https://github.com/pepa65/tldr-bash-client

[rockedge]

Anyone know how to add the 'tldr' app to this distro?

As Jasper wrote, download the script and place it in /root/my-applications/bin, /usr/local/bin or /usr/bin

Screenshot.jpg (86.72 KiB) Viewed 1508 times

[Clarity]

THANKS!!!

Is this a candidate for a PUP utility delivering useful HELP beyond what we have via MAN command? This could eliminate many/most browser searches for command examples by users. Seems 'too' be easy to use.

[fr-ke]

Changing the icon grid step in the Roxfiler settings causes the drive icons to be on top of each other

[Clarity]

On GIT, tldr says

When the following lines are added to ~/.bashrc or run in the current session, then tldr will autocomplete, which means possible tldr page names will be suggested when tapping the Tab key twice on an incomplete tldr page name:

Code: Select all

cachedir=~/.local/share/tldr/pages # Or whatever else the location of the tldr cache is
complete -W "$(q=($cachedir/*/*); sed 's@\.md @ @g' <<<${q[@]##*/})" tldr

How can this be implemented in tldr script to obtain auto-complete? Should the tldr command be made into a PET for all PUPs?

P.S. Tried tldr youtube-dl for an example use...fascinating.

[fr-ke]

Just a thought:

I wonder if it's possible to reserve the top read only layer for personal settings. I don't know the origin of the different layers.
However, some of us seem to prefer not to use a savefile and still make the personal settings permanent.
This is easy to do with nicOS Utility Suite.
In many cases a remaster would not be necessary. Puppy's core elements remained untouched.

Best regards

[rockedge]

@fr-ke Using the NicOS Utilities it should be easy to generate the save file/folder into an bdr_XXXX.sfs which would then be the persistence data.

I think @amethyst uses this feature along with the nicOS Utility Suite to eliminate the save file/folder and has experience using this method. I believe the ydrv_XXXX.sfs is the drive he uses since only the more recent Puppy's load the bdrv_XXXX.sfs at system boot and the ydrv is loaded by older versions.

I would recommend a rewrite of the initrd.gz to be able to load an entire alphabet of adrv - zdrv SFS's. One of FirstRib and KLV's strong features is the extra SFS files only need a 2 digit prefix to the file name to load them at system start. So 00filename through 99filename can be used.

@taersh Has I believe done some work in this area and produced an initrd that can load an alphabet of drv SFS files. The oldforum should have extensive information on his work. By the way where has taersh gone? Have not seen him on the forum in quite awhile.

[mikeslr]

@fr-ke Using the NicOS Utilities it should be easy to generate the save file/folder into an bdr_XXXX.sfs which would then be the persistence data.

I think @amethyst uses this feature along with the nicOS Utility Suite to eliminate the save file/folder and has experience using this method. I believe the ydrv_XXXX.sfs is the drive he uses since only the more recent Puppy's load the bdrv_XXXX.sfs at system boot and the ydrv is loaded by older versions.

I would recommend a rewrite of the initrd.gz to be able to load an entire alphabet of adrv - zdrv SFS's. One of FirstRib and KLV's strong features is the extra SFS files only need a 2 digit prefix to the file name to load them at system start. So 00filename through 99filename can be used.

@taersh Has I believe done some work in this area and produced an initrd that can load an alphabet of drv SFS files. The oldforum should have extensive information on his work. By the way where has taersh gone? Have not seen him on the forum in quite awhile.

NicOS Utilities's Save2SFS (currently) can only create or modify an adrv.sfs or a ydrv.sfs. A re-write would be necessary to add other 'alphabet'drvs to its arsenal. A user, of course, for example, create an adrv.sfs then rename it to a bdrv.sfs or any other 'alphabet'sfs which the initrd recognizes.
The Save2SFS module takes whatever happens to be in RAM --maybe some folders such as /temp are intentionally excluded-- and writes it to either an adrv.sfs or a ydrv.sfs.

@ rockedge, I haven't worked with overlays, only IIRC, that they use numbers to establish priority. But can Save2SFS be used at all? recognizing that, for example, an adrv.sfs created with Save2SFS could be renamed by the user 09mediasuite.sfs?
If not, IMHO rushing to deprecate aufs would seriously weaken Puppy's arsenal.

Taersh worked on increasing the number of 'alphabet'drvs a while back. More recently, amethyst has modified the initrds of racy and precise to create racy-extra and precise-extra, https://www.forum.puppylinux.com/viewforum.php?f=119. Mistfire's Quickpup (a slacko remaster) makes use of b,g,x and sometime n drvs in addition to those commonly employed under 'debian/ubuntu' Puppies. And gyrog has worked on developing an initrd which could handle 25 'alphabet' drvs., https://www.forum.puppylinux.com/viewto ... 801#p29801

Encouraged by their successes I tried to add a 'g-for glibc' drive to tahrpup64. During that exploration I examined the initrds of newer 'debian/ubuntu' Puppys. What I discovered was that the structures of 'slackos' and 'old Puppys' is 'a different animal' than that of 'debian/ubuntus'. See screen shot, https://www.forum.puppylinux.com/viewto ... 715#p70715. Later examination of Jammy64 and Fossapup64 indicates that structural difference continued.
Perhaps that difference doesn't effect the actual change in coding required. See amethyst's post following this which was published while I was searching for something.
My own efforts were deferred (maybe abandoned). As far as I could tell, all that should have been necessary was to duplicate for a gdrv how initrd handles adrv.sfs and ydrv.sfs, perhaps only by editing DistroSpecs with minor revisions to initrd. Perhaps I over-complicated it and coding --not being my 'strong-suite'-- may have resulted in errors. As I recall --perhaps like amethyst's experience with pdrv and xdrv-- the gdrv I created was not put to use on boot-up.

At any rate, while I agree that adding additional 'alphabet' drvs to Fossapup64 would be advantageous, I also think the exploration of how to do that should be undertaken by someone having greater experience and a greater ability to concentrate than I have.

[amethyst]

@rockedge
I use the same init with all my Puppys. Additional drives for all letters of the alphabet (well almost all) envoked. The pdrv and xdrv are the only additional drives that do not work with this init. pdrv has been replaced with a ppdrv. Works on all my 32-bit Puppys and the one 64-bit Puppy I have (so don't know if it works with other 64-bit Puppys as well), only the DISTRO_SPECS needs to be edited for the different Puppy names. Attached is the DISTRO_SPECS of one of my Puppys as an example (remove fake extension).