Puppy Linux Discussion Forum

Brilliant! With your change it starts up as expected. Thank you very much and sorry for the lack of important detail in my initial post.

Re issue with random slow Firefox startup

I am using 10.0.18 as my daily driver
Firefox 102.13.0esr 64 bit
Custom local home page
auto update add-ons turned off
I have noticed that randomly Firefox will be very slow to start up. Sometimes 20-30 seconds
I have tried opening a terminal and looking at top but it shows nothing
This time I did a ps | grep

ps | grep firefox
 5493 spot      0:00 /usr/lib/firefox-esr/firefox-esr.bin
 5529 spot      0:00 [firefox-esr.bin]
 5656 root      0:00 grep --color=auto firefox

and

dmesg | grep firefox
[  240.105720] firefox-esr.bin[5531]: segfault at 7fa1810fef38 ip 00007fa18154c5ba sp 00007fa1810fef40 error 7 likely on CPU 1 (core 1, socket 0)

A search online has not shown any results

Is anyone else having this issue?

I am also seeing this behavior in both F96-CE_4 (102.13.0esr), KLV-Airedale-sr2 and KLV-Spectr-beta2 (115.0.2).

Undoubtedly on behalf of the puppy user community, many thanks to all developers for their continued efforts, hosts, and dimkr for creating and maintaining vanilla dpup.

Just my feedback on what I found, don't expect any fixes, it's just in case someone else has had one of these problems and knows of a solution

- It booted fine (v10, wayland). One of the first things I tried was to run redshift. I saw a post earlier in that the shortcut is there, but not the program itself, so installed the .pet. While it launches, moving the bar on the gamma or brightness doesn't do anything. This is on nouveau that is included in the zdrv. Tried installing the full version of redshift and running it on terminal (mode - wayland). Still nothing.

- I thought maybe the problem is with nouveau not being fully ready for wayland. I was going to change to nvidia anyway. But I only run puppy in mode 5. To compile an nvidia driver in this mode, the way I usually do it is blacklisting nouveau at boot first. However, when doing this, I'm unable to start the desktop environment (forgot what is called now, but the equivalent to xwin). It just quits to a prompt when started.

- I also tried the retro version. Installed the devx.sfs from fossa 9.5 and an updated gcc. However, the devx, as a loaded sfs (through the aufs simulation), does not seem functional and can't compile

- Also noticed that sandbox.sh comes included, but is not functional of course (it is what I would have used to know which files were created by the compiler, to merge with zdrv). Not sure if there is anything equivalent

- Finally, tried using the kernel I used with fossa (5.4.249) and zdrv (renamed accordingly, already included the nvidia driver), but wouldn't work with vanilla (no mouse, vesa only). Presumably because the kernel is aufs so I'm guessing only the main sfs really loaded

bigpuppyfan wrote: ↑Mon Aug 07, 2023 12:36 am

- It booted fine (v10, wayland). One of the first things I tried was to run redshift.

Redshift doesn't support Wayland, and some alternatives work only with certain Wayland compositors.

bigpuppyfan wrote: ↑Mon Aug 07, 2023 12:36 am

- I thought maybe the problem is with nouveau not being fully ready for wayland. I was going to change to nvidia anyway. But I only run puppy in mode 5. To compile an nvidia driver in this mode, the way I usually do it is blacklisting nouveau at boot first. However, when doing this, I'm unable to start the desktop environment (forgot what is called now, but the equivalent to xwin). It just quits to a prompt when started.

Yes, you must have some KMS-capable GPU driver to start the compositor. Install the NVIDIA driver first, then disable nouveau, if you don't want to do this from the terminal.

bigpuppyfan wrote: ↑Mon Aug 07, 2023 12:36 am

- I also tried the retro version. Installed the devx.sfs from fossa 9.5 and an updated gcc. However, the devx, as a loaded sfs (through the aufs simulation), does not seem functional and can't compile

The devx and the kernel from 9.5 won't work, because the structure is different and there's a 3 years gap in terms of package versions. And if you only take zdrv from 9.5, this won't do anything, because the kernel is different and can't use the old drivers.

If you want to build something and use it in the retro flavor, your best bet is to use one of the other flavors (after apt update && apt install gcc libc6-dev, etc') to build, then use the build output with the retro flavor.

Thanks for your kind input dimkr

And if you only take zdrv from 9.5, this won't do anything, because the kernel is different and can't use the old drivers.

I had used the kernel I use with fossa (5.4.249) with the accompanying zdrv

But dwl wouldn't launch. On further inspection, it seems that the stack is not created correctly. At boot, the main sfs, zdrv, fdrv, etc are loaded into ram (under this aufs kernel). But immediately after, the new zram function fails to load (when using this kernel, not the original).

On terminal, I see that while losetup lists the sfs's, none of their content, aside from the main sfs, is visible. eg. /lib/modules is empty. /initrd/ does not have pup_z (or _f, etc). Thus it's not possible to modprobe anything, and dwl of course fails without an appropriate video driver

So I've had a look at init and rc.sysinit to see if there were any changes. The error occurs before zram (as it cannot modprobe it), so I would presume it would be within the init script. I couldn't find anything in particular in the new changes (but I'm not a programmer). Plus, I even tried booting (with the above aufs kernel / zdrv) using the fossa9.5 initrd.gz (only updated DISTRO_SPECS), but the same result: sfs's load into ram, but seemingly not into the stack, so presumably the issue really is not in init either. But am clueless as to where the issue may be.

All the above can be made irrelevant if it were possible to build and use the nvidia driver in PUPMODE 5 with overlay, but am not seeing how, which is why aufs seems to be necessary. In this mode, I build the driver under the sandbox (sandbox.sh script), and merge thereafter the new files in the sandbox with zdrv.

I wouldn't be surprised if that kernel is way too old for a modern Wayland compositor.

And you need to rebuild zdrv: move /lib/modules to /usr/lib/modules.