F96-CE_3 Stable Release

[MochiMoppel]

@radky Thanks. Unfortunately doesn't work. Since Slacko succeeds without a .rules file I assume that the root of the problem must be somewhere else.

[wizard]

@pp4mnklinux

Can't confirm your shutdown issue.

-installed F96-CE_3 to fat32 USB using Unetbootin
-booted on UEFI computer, setup wifi
-shutdown, made .4fs savefile on USB
-rebooted, put icon on desktop
-Leave, reboot, save/nosave appeared, could select either, chose save
-rebooted, changes were saved, put another icon on desktop
--Leave, shutdown, save/nosave appeared, could select either, chose no-save
-system shutdown

@bigpup had a similar issue here:viewtopic.php?t=8153&start=10
and determined it was hardware specific. Also, you'll find reference for file to edit to change shutdown time.

Thanks
wizard

[pp4mnklinux]

Thanks a lot.

With your help, comments and guide we solved our problem.

These community is what made puppy my default OS.

THANKS

.

______________EDITED------------------

Solved modifying the acpi files.

It takes a lot of time identify the problem, but when done easy solution for my hardware.

------‐---------------------‐

@pp4mnklinux

Can't confirm your shutdown issue.

-installed F96-CE_3 to fat32 USB using Unetbootin
-booted on UEFI computer, setup wifi
-shutdown, made .4fs savefile on USB
-rebooted, put icon on desktop
-Leave, reboot, save/nosave appeared, could select either, chose save
-rebooted, changes were saved, put another icon on desktop
--Leave, shutdown, save/nosave appeared, could select either, chose no-save
-system shutdown

@bigpup had a similar issue here:viewtopic.php?t=8153&start=10
and determined it was hardware specific. Also, you'll find reference for file to edit to change shutdown time.

Thanks
wizard

[newpet]

Fresh install with Unetbootin on my 8gb pendrive, HP 240 G8.
Everything works OOTB, besides wireless. It's a RTL8821CE.
In FossaPup64 9.5, "rtl8821ce-fossa64k5453.pet" does the job.
Any help?
Thanks.

[mikeslr]

Fresh install with Unetbootin on my 8gb pendrive, HP 240 G8.
Everything works OOTB, besides wireless. It's a RTL8821CE.
In FossaPup64 9.5, "rtl8821ce-fossa64k5453.pet" does the job.
Any help?
Thanks.

As your Puppy is FossaPup64 9.5, ozsouth's pet from this post should work, viewtopic.php?p=56346&sid=dcb5b49cc86dd ... 750#p56346 --assuming your Puppy employs the k5.4.53 kernel. Drivers are kernel specific.

For future reference, newpet, I located that post by plugging "RTL8821CE" into the Search Box of h[url]ttps://rockedge.org/psearch/[/url], a google-search engine dedicated to all things Puppy. Finds relevant posts in this and the old Forum.

@moderator, as this thread concerns FossaPup64-9.5 it should be moved to that Section.

[bigpup]

I think you are missreading newpet's post.

They need the RTL8821CE driver for F96-CE_3 for their WIFI device.

The Fossapup64 9.5 one is not going to work.
F96-CE_3 is using a different kernel.
Drivers are kernel specific.

[newpet]

I think you are missreading newpet's post.

They need the RTL8821CE driver for F96-CE_3 for their WIFI device.

The Fossapup64 9.5 one is not going to work.
F96-CE_3 is using a different kernel.
Drivers are kernel specific.

Exactly.

[ozsouth]

@newpet - Only saw this a couple of hours ago. 6.x kernels should not need special driver for this. As rtw88 driver & rtl8821c firmware are present, this should work. Posting ok from laptop with rtl8821ce now. May be an install issue.
List of files that should be on install in picture below. Note initrd.gz & vmlinuz will be in boot partition. If all are there, please run in a terminal:
dmesg | grep irmware
& post output here.

[Keef]

Code: Select all

dmesg | grep irmware

Don't forget the effin' firmware

[ozsouth]

@Keef - actually, that's my shorthand (lazy) version of the textbook command: dmesg | grep -i firmware
(the i means ignore case, although I must admit, I've never seen anyone type Firmware in that).

[wiak]

@Keef - actually, that's my shorthand (lazy) version of the textbook command: dmesg | grep -i firmware
(the i means ignore case, although I must admit, I've never seen anyone type Firmware in that).

irmware.. I do the same... but android would no doubt autocorrect to Irmware

[rockedge]

Just recently took an hour of debugging to find out I typed "irmware".

I believe this is the optical illusion that led to the fall of the Roman Empire except it was in Latin.

[newpet]

Hi ozsouth,
thank you for your detailed response.
As one of the heirs of the Roman Empire, I was looking for the best distro in terms of details and usability, and I'm sure I almost achieved the goal
A little update: I noticed that wireless somehow works, but not properly. I mean it only manages very strong signals, in my specific case my own mobile hotspot, not showing anything else than this. Others distros, fossapup64-9.5 included, are able to receive a dozen other signals, with their own strenght.
Fresbee is not able to perform better, and shows same values.
Furthermore, connection seems vague and erratic even with strongest signals.
To be sure, I reinstalled F96-CE_3 one more time, same results.

- all 8 files in your list are on install

then:

- # dmesg | grep firmware

[ 25.194662] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
[ 25.571964] bluetooth hci0: Direct firmware load for rtl_bt/rtl8821c_fw.bin failed with error -2
[ 25.571968] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8821c_fw.bin not found

Thanks.

[ozsouth]

@newpet - I tried to build you an rtl8821ce driver, but this 6.0.12FP kernel seems to not like out-of-tree drivers (failed with wl driver too). I made a driver which loaded in @radky 's replacement kernel, but that kernel's been withdrawn. I cannot build an out-of-tree driver for kernels after 6.0.x, so have tested F96CE-3 with my 6.0.13ao kernel, for which I DO have an out-of-tree rtl8821ce driver. It works.
The 6.0.13ao kernel needed is here: https://archive.org/download/Puppy_Linu ... ao.tar.bz2
Update: The driver for that kernel didn't work for newpet, but the kernel appears to.

To change kernel, once downloaded (best to start with a fresh install of F96CE-3):
In a terminal, expand tar.bz2 file in an empty folder with tar -jxvf, & rename kernel-modules.sfs-6.0.13-64oz-ao
to zdrv_fossapup64_9.6.sfs & rename vmlinuz-6.0.13-64oz-ao to vmlinuz & then substitute for originals.
Then reboot (don't save).

To install rtl8821ce driver, once downloaded, kernel changed & rebooted:
click on it in ROX-Filer, wait about 10 sec, then try to connect. Must save upon exiting F96CE-3 to retain.

[newpet]

@ozsouth - I replaced the kernel with the one you suggested (6.0.13ao). Reboot. Then I installed rtl8821ce-64k6.0.13ao.pet driver, and after about ten seconds, I tried to connect. This time both network managers (default one and frisbee) were populated with lot of signals, with their relevant strenght, and I was able to connect to my hotspot.
Then I saved and shut down.
Unfortunately, the magic didn't survive to the following boot, and things went magically (or tragically) back to the previous situation.
Then I tried to repeat the procedure, uninstalling the driver and reintalling it once again, several times to say the truth, sadly with same results. Let's say the trick works fine but just for the current session. Reboot seems to overwrite the fix.
Maybe it's time for me to give up....

Thanks.

[ozsouth]

@newpet - looks like either something is going wrong with the save, or more likely the blacklisting isn't working.
OK, on your boot partition, you will have grub.cfg or syslinux.cfg. You need to edit that so that the 'linux' or 'kernel' line which will contain things like pfix , pmedia , pdrv etc. At the end of that line, add the following:
(a space) modprobe.blacklist=rtw88_8821ce,rtw88_8821c,rtw88_pci,rtw88_core
Then save that file & reboot. When it starts up, run .pet again, then connect then reboot & save again (savefile or savefolder should be fine). Hopefully upon next start, should be ok.

[bigpup]

@newpet

Are you using a 2.4Ghz or 5Ghz wifi signal?
That can have an affect on connection stability.
Also what channel is being used, can run into interference form other signals, using the same channel.

You are only using one connection setup program to make the connection setup?
Do not try to do a setup using Connman and Frisbee at the same time.
Pick one and only use it.

I am wondering if what you are seeing for connections, after you do a connection setup.

Has something to do with what is being used in F96-CE_3 as the program to control connections.

Using ConnMan Connect Manager
When I first use it, shows me a large number of connection sources in my area.
After I setup a connection, using my connection source.
Do a shutdown and save.
Reboot now using the connection, I set up.

When I access Connman setup.
It now only offers me the strong signal sources, that are provided by me.
I no longer see the other ones.

If I disconnect from my selected connection, no longer using it.
Connman will now show other sources, for selection to use, as a connection.

F96-CE_3 is using some new connection software.
Not sure if it also has an affect on Frisbee

Connman is the new way to go for making a network connection setup.

[newpet]

@ozsouth - I have both grub.cfg and syslinux.cfg on my boot partition. I send them both as attachments, so you can conveniently find the line I need to modify to make it (them) work. It's not that easy, since many lines show things like the ones you mentioned.
Thanks.

@bigpup - Thanks for posting. More than a problem due to the choice of the frequencies, 2.4 or 5 GHz, it seems more likely a problem of driver conflict. Both connection managers, default one and frisbee, show same results in terms of signals received, used alternatively. They both are able to manage my connection though, when driver works of course, and both show nothing when driver problems come back. Therefore it's not a connection-manager related issue. The only visible behaviour difference between the two, is that frisbee is a little baggy and often needs a manual refresh. Also, I did not notice any interaction between the two.
Thanks.

[ozsouth]

@newpet - I think you need to edit the 3rd paragraph of syslinux.cfg to look like this:

label ubnentry0
menu label fossapup64 9.6
kernel /vmlinuz
append initrd=/ucode.cpio pmedia=usbflash pfix=fsck modprobe.blacklist=rtw88_8821ce,rtw88_8821c,rtw88_pci,rtw88_core

& boot that entry.

OR

I have one more trick - before I did kernel compiling I used to force modules into existing kernels.
I have modified my 6.0.13ao zdrv to include rtl8821ce. That way you should only have to swap-in the modified zdrv.

Tested OK on my rtl8821ce laptop, but didn.t work for newpet, so withdrawn

[newpet]

@ozsouth - Thank you for the tips. First trick doesn’t work, nothing changes. Same story with the 2nd 6.0.13ao kernel. So I went back to the first 6.0.13ao you linked me. Well, I made it work, don’t ask me how, because I have no idea It only works if I install the driver, then I uninstall it, and finally install it again. I repeat the sequence a couple of times, to be sure it was not by accident, with reproducible results.
The oddities do not end there. I made a copy of the save-file, with another name. When I boot with the copy, the connection manager is empty again. Sometimes unpredictable things happen in computer science...
Right now it works like a charm. My only fear is that after few reboots, the issue may occur again.
Now I’m looking for a solution for the lack of the battery warning alarm, something like the one on fossapup64 9.5, lets say. In order to avoid the sudden shutdown of the laptop.
I thank you all for your efforts, without which I would not have been able to solve this obscure issue

[newpet]

update:

I checked both save files (original and its copy) for checksum: identical.
In the first one, default connection manager works flawless; in the exact copy, same checksum, it doesn't.
How is it possible?

Cheers

[bigpup]

What size are these save files?

What internal format?
.2fs
.3fs
.4fs

How did you actually make the copy save?
Specific details???
What format is the partition the copy save is stored on?

When you change the save to use.

Best if you do a complete power off shutdown. Wait one minute.

Then do a normal power on boot selecting to use the different save.

This makes sure that RAM is completely starting from a clean condition.

If you are having sudden shutdowns, from the battery in the laptop, running out of power.

If the save was being written to at this exact time, well anything could happen to corrupt the save.

[newpet]

@bigpup

- about 2.0 Gb each
- 4fs
- I made a copy of my save-file first with F96-CE_3, then I did the same with windows, and I compared them each other to be sure they were identical (size and checksum SHA-256). Only their name are different (B instead of A), but this obviously doesn't affect the checksum test.
- fat32
- as you suggested, I did a complete power off and wait something like twenty minutes, then I booted the save-file copy - same results, the OS works fine , but wireless card does'nt. It magically works again once I boot with the original save-file.
======
- useful battery warning alarm is absent in F96-CE_3, as far I can see at least
- I can't find any application in the box "Run Internet apps as spot", so I couldn't tick any
- my tarball browsers like brave, palemoon and current FF versions, working on FP 9.5, do not work on 9.6.

Thanks

[bigpup]

I made a copy of my save-file first with F96-CE_3, then I did the same with windows

The one made using Windows for sure could have errors in it.
The save file is a Linux file system inside a file and Windows does not fully get it correct.

If you made the copy using F96-CE_3 when it was running using the save.
Did you do it by using the program Pupsave Backup?
That program is designed for making a save copy, when the save is actually being used.

[mikeslr]

I'm guessing that you are using a SaveFile rather than a SaveFolder because your Puppy is located on either a Fat32 or ntfs formatted partition. A SaveFolder is the recommended method for preserving changes; a SaveFile has no advantages except that a Linux formatted partition is not required.

You can't copy/duplicate the SaveFile of a running Puppy: that generates errors. To avoid complexity of having to create and later unpack a SaveFile.bk (backup), the recommended way to create another SaveFile is to boot pfix=ram (e.g. add a Stanza to your menu.lst or grub.cfg with the argument pfix=ram* and reboot into it) then make a new SaveFile..

But I just discovered this trick using a SaveFolder. It may also work with SaveFiles.
Untested. I don't have any Puppy using a SaveFile. But the worst that can happen is it won't work.

On bootup when Puppy 'sees' 2 or more Saves it offers you another choice: boot without using any Save. So, you can Right-Click an empty space on your Puppy's partition, select New>file and give it a name such as fossapup64save-garbage.2fs. On reboot you may be given the following choices [not sure of the sequence];

0 fossapup64save.4fs
1 fossapup64save-garbage.2fs
2 No Save

If so, in the above example typing '2' --choosing No Save-- will boot into a pristine fossapup64 (i.e. not using a Save). You can then Right-Click your fossapup64save.4fs, select duplicate and give it a different name, e.g. fossapup64save-April02.4fs. Having booted pfix=ram both duplicate and copy will make an exact copy of the SaveFile. [Duplicate requires that you give it a different name; Copy a different location].

The above works with SaveFolders. I don't see any reason it wouldn't work with SaveFiles except that your manually created fossapup64save-garbage.2fs may not be recognized as a SaveFile so the choice of booting No Save wouldn't be offered.

If you try it; let us know if it works.
-=-=-=-=-=
* You used to be able to boot pfix=ram by typing something --I forget what-- as soon as the boot menu appears. And your boot-manager may have written a Stanza. If using grub4dos, scroll down and select Advanced Menu. Booting pfix=RAM used to be the first choice on grub4dos's Advanced Menu.

[amethyst]

a SaveFile has no advantages except that a Linux formatted partition is not required.

Can a save folder be on a different partition than that of the installed Puppy files or on another disk seperate from the Puppy installation, like a save file can?

[one]

a SaveFile has no advantages except that a Linux formatted partition is not required.

Can a save folder be on a different partition than that of the installed Puppy files or on another disk seperate from the Puppy installation, like a save file can?

Hi @amethyst,

not so long ago - you forgot?

viewtopic.php?p=81327&sid=0b738339e2e9c ... f26#p81327

peace

[rockedge]

@amethyst Long story short, Yes.
In the boot stanza use psave=

You can specify on the kernel command line in the boot stanza where to look for the save folder.

Good info here

Code: Select all

Boot parameters:
================

pmedia=<atahd|ataflash|usbhd|usbflash|cd>
Indicates the type of boot device.
If it's "cd" then the partitions are searched for a save layer file, the only situation that triggers such a search.
If the first 3 characters are "usb", then any searching is restricted to only usb devices.
If the last 5 characters are "flash" the top layer in the stack remains the tmpfs in memory, otherwise any found save layer becomes the top layer in the stack.
This boot parameter should always be provided.

psubdir=</path/to/install/directory>
If the Puppy files are not in the root of a partition, but in a sub-directory, the path of this directory, relative to the partition root, must be specified with this parameter.
e.g. If the sdb2 partition is mounted as /mnt/sdb2 and the Puppy files are in /mnt/sdb2/tahr64, then "psubdir=tahr64" or "psubdir=/tahr64" must be specified.
This parameter can specify subdirectories at more that a single level, e.g. "psubdir=puppy/tahr64" or "psubdir=/puppy/tahr64".
If a leading "/" is not provided, init will add it.
This is the default path for locating any puppy file and any partition.

------------------------------------------------------------
pdrv=<partition> Specifies the puppy...files partition
pupsfs=<partition> Specifies the puppy...sfs partition
zdrv=<partition> Specifies the zdrv...sfs partition
fdrv=<partition> Specifies the fdrv...sfs partition
adrv=<partition> Specifies the adrv...sfs partition
ydrv=<partition> Specifies the ydrv...sfs partition
psave=<partition> Specifies the save layer partition


Where <partition> can be the name e.g sdb2, or a label e.g. Work, or a uuid
e.g. 0db94719-cdf1-44b7-9766-23db62fb85a5
When a label or uuid is used, only the beginning is required, enough to be unique on your system,
e.g "pupsfs=0db94719-cdf1"

[amethyst]

@amethyst Long story short, Yes.

You can specify on the kernel command line in the boot stanza where to look for the save folder.

Good info by following the link in the previous post

Too much effort, seems to be a disadvantage compared to save files especially in the sense of quickly jumping between different machines. Wouldn't the contents of an existing save folder be more prone to corruption too, eg: save file/folder not in use but a save folder on the puppy partition will always be mounted and available to change things inside the folder whilst a save file will at least have to be mounted first to change its contents (although the file may be on the same mounted puppy partition)? I think I will have to vote for the super- duper save file instead (although I use neither).

[rockedge]

@amethyst since save folders came into play I've used them. I never had a corruption occur unless it was something extreme I was trying out.

The Save Folder is uncompressed, that is the advantage in a nutshell. I like that both methods are available and can be applied in different environments and with varying goals.