LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020

[Marv]

Old hardware land checking in... 17.02.21 and 17.02.22 isos generated, md5sum checked, and used to update 17.02.1 frugal installs on both core 2 duo laptop and Pentium M laptop. Both the 4.9.9 kernel and the 'alternative' 4.4.45 kernel boot cleanly and run on both. The Pentium M continues to require the 4.4.45 kernel, both so suspend doesn't lock up and for video FPS (the 4.4.45 FPS is 3X the 4.9.x FPS). The core 2 duo is perfectly happy with either, no perceptable video difference, but seems slightly cooler/less busy with 4.4.45. That's subjective. Lxtask shows no real difference. I'm batting 0.500 on 17.02.1 at the farm. The core duo laptop is in use with no squawks from its user. The Bay Trail box there is back to X-slacko 4.2. Kevin just couldn't give up just how SlimBoat (yes, Boat) renders Craigslist and some of the Ag sites. He's completely colorblind so little differences in setup do matter and there's no banking/email etc. on that machine. Path of least resistance was just to make the X-slacko he'd been using default again. For now anyway. At home here, 17.02.22 set up as my daily user.

Edit: I think i just about have Slimjet 13.0.3.0 (as a SFS, thank you Mike Walsh) set up so the tabs and display will sub for the ancient SlimBoat on the Bay Trail box. Running it on 17.02.22T now. When I'm feeling bold I'll swap it and see. Or hear

[peebee]

This should fix it.
Apparently new version of grep can not handle pipe symbols ("|") in files.
SNS and pupscan also uses "grep -f" but these files do not give any problems. Keep an eye though.

grep-3.0 for slackware-current is announced

so I've done a 17.02.22aT build with @mav's ppm fix just to check it's ok.

there is a delta from 22T to 22aT at:
https://my.pcloud.com/publink/show?code ... PrPLaAF6gk
for those really interested in grep

ppm, sns, pupscan all checkout AOK

[belham2]

Hi Peebee and all,

I have rotten luck with the included "Light" browser when on video websites and/or other sites that have a lot going on. I installed Firefox-ESR latest, and as usual everything went back to normal in terms of stability and play-ability. My question is how does one completely remove all trace of the Light browser?

I am used to removing browsers in other pups, but Light is not located in the normal places like other browsers (like /usr/bin and/or /usr/lib or even /usr/share/applications). So far, I've found Light in /root/.light, /root/.local and /root/.cache but I can't find if it is embedded anywhere else. Is it??

I thought maybe I'd use the included "remove-builtin-packages" script (located in Menu-Setup), but there is no package that this script can find that is called 'Light' and/or Mozilla-Light. Does the browser go by another name in this script? If possible, I'd prefer to use the script to remove this blasted browser....but if not, how many places is this browser embedded in LxPupSc???

Thanks for any hints & tips to get Light & all its remnants completely removed.



P.S. Also, I too am running 17.02.22T (with the older kernel & alternative xorg) and all is good here. Thank you much, Peebee!

[peebee]

Hi Peebee and all,

I have rotten luck with the included "Light" browser when on video websites and/or other sites that have a lot going on. I installed Firefox-ESR latest, and as usual everything went back to normal in terms of stability and play-ability. My question is how does one completely remove all trace of the Light browser?

I am used to removing browsers in other pups, but Light is not located in the normal places like other browsers (like /usr/bin and/or /usr/lib or even /usr/share/applications). So far, I've found Light in /root/.light, /root/.local and /root/.cache but I can't find if it is embedded anywhere else. Is it??

I thought maybe I'd use the included "remove-builtin-packages" script (located in Menu-Setup), but there is no package that this script can find that is called 'Light' and/or Mozilla-Light. Does the browser go by another name in this script? If possible, I'd prefer to use the script to remove this blasted browser....but if not, how many places is this browser embedded in LxPupSc???

Thanks for any hints & tips to get Light & all its remnants completely removed.



P.S. Also, I too am running 17.02.22T (with the older kernel & alternative xorg) and all is good here. Thank you much, Peebee!

Hope this is the recommended frugal install....if not you're in problems....

If so just delete the adrv and replace it with the sfs of your browser of choice - then use Setup -> Default Applications Chooser to set that browser to be your default....easy peasy!!

Light is only a "starter for 10" web browser - it is intended that people install a more heavyweight browser for serious use which definitely includes video!

[belham2]

Hope this is the recommended frugal install....if not you're in problems....

If so just delete the adrv and replace it with the sfs of your browser of choice - then use Setup -> Default Applications Chooser to set that browser to be your default....easy peasy!!

Light is only a "starter for 10" web browser - it is intended that people install a more heavyweight browser for serious use which definitely includes video!

Yep, always do the 'frugal' install. Thanks, Peebee, that sure was/is easy----poof goes the adrv!

[peebee]

LxPupSc-17.02.23T interim delta

BUILD_FROM_WOOF='testing;edcbae2;2017-02-26 08:24:04 +0200'

so includes @mavrothals fix for sfs loads under pupmode 5 & 13

Kernel 4.9.12

(have done preliminary builds of 4.10 but some issues to iron out and aufs-4.10 isn't released yet)

[Marv]

Downloaded, iso generated and md5sum checked ok. Frugal Grub4Dos install on all intel core 2 duo laptop checked. Pristine install ok, SNS WPA2 connection ok, sound ok, glxgears FPS good at 1630, baseline CPU and memory use pretty much unchanged from 21T and 22T. 4.4.45 and 3.14.79 kernels swapped in, both run just fine, glxgears FPS for both essentially the same as above. CPU idle and base memory use a bit lower on them but on this machine not appreciably. Updated fresh savefiles created in 21T and 22T with no problems. My savefiles from earlier versions (ran ok in 21T and 22T) hung at the "performing a 'switch root' to the layered FS" until I used the 22T fresh savefile as a template to clean out the bins sbins, and rc.d in the earlier ones. Cruft. With that done, updates and boots are perfect there also.

On the core 2 duo with Drives on desktop option installed, I need a skosh more time to get the system wallpaper in place so the drive icon backgrounds pick it up on a fresh startup or reboot. I remove the & at the end of line 5 in /root/Startup/1-lxde-startup.sh (rather than using a sleep) and that does the trick.

I'm using SlimJet-13.0.3.0-i386 on SFS in lieu of Light and other than the standard chrome/chromium/derivs gripe about the fixed toolbar and menu fonts quite like it.

[mavrothal]

My savefiles from earlier versions (ran ok in 21T and 22T) hung at the "performing a 'switch root' to the layered FS" until I used the 22T fresh savefile as a template to clean out the bins sbins, and rc.d in the earlier ones. Cruft. With that done, updates and boots are perfect there also.

Happened to me too, but after a hard reboot everything worked fine and the update was already done.
Triggered the update again changing the version in DISTRO_SPECS and everything breezed through.
So I thought was just a freak freeze.
Apparently not.
Let's see if it is going to happen with the next version too before start digging.

[peebee]

I didn't see the upgrade issue as I had already upgraded (without issue) to a "private" 23T build made with the previous woof-CE.....

Kernel-4.10.1 seems to have cured the issues with 4.10.0 and has built successfully with the kernel kit in the above woof-CE (using aufs-4.x-rcN)

If anybody wants to test, it can be found at: http://smokey01.com/peebee/slackocurrent/kernel/

[mistfire]

@peebee does the 4.10.1 kernel is a vanilla linux with puppy patched? I tested it on my x-slacko slim and it works fine. Does the kernel modules of the kernel that you compiled is complete or there are missing kernel modules on it?

[mistfire]

@peebee I noticed that the vmlinuz filesize was increased by 2Mb. Is there any way to make it smaller without recompiling the kernel?

[peebee]

@peebee does the 4.10.1 kernel is a vanilla linux with puppy patched? I tested it on my x-slacko slim and it works fine. Does the kernel modules of the kernel that you compiled is complete or there are missing kernel modules on it?

Hi mistfire

It is a woof-CE kernel-kit build so is patched for aufs and puppy.

I build without any extra firmware in the zdrv so my kernels need to have the fdrv installed as well....the fdrv is in any 17.02 iso and just needs renaming appropriately. Cannot guarantee 100% completeness of modules....it has what my config files specify should be included - if something is missing I can consider adding.

vmlinuz has not grown in this build - still 5.2MB which it has been since 4.7.6 at least (the oldest I have to check).

Cheers
peebee

[Marv]

My savefiles from earlier versions (ran ok in 21T and 22T) hung at the "performing a 'switch root' to the layered FS" until I used the 22T fresh savefile as a template to clean out the bins sbins, and rc.d in the earlier ones. Cruft. With that done, updates and boots are perfect there also.

Happened to me too, but after a hard reboot everything worked fine and the update was already done.
Triggered the update again changing the version in DISTRO_SPECS and everything breezed through.
So I thought was just a freak freeze.
Apparently not.
Let's see if it is going to happen with the next version too before start digging.

I did a bit of looking at savefile contents on creation, after reboot no update, and after update and I think rc.update could be more selective about putting system scripts in the savefile when they haven't been modified or permissions changed. I have a modded update script running and will use it for a few updates. Where best to persue that?

[mistfire]

vmlinuz has not grown in this build - still 5.2MB which it has been since 4.7.6 at least (the oldest I have to check).

I compared that file size against linux 3.x kernel which was currently used by slacko.

[mistfire]

@Peebee I have a question does linux firmware files are linux version independent and backward compatible? I mean the firmware file from the older linux version will it work on the newer kernel?

[peebee]

.... I have a modded update script running and will use it for a few updates. Where best to persue that?

Hi Marv
It should be submitted to woof-CE as a change request once tested. I'm sure @mav can do that for you if you don't want to venture there yourself....or I can if he can't - pm us the changed file....

FYI - I made a 17.02.1T savefolder and then upgraded to 17.02.23T and didn't have any issues....upgrade and reboot proceded as expected...

@mistfire - yes, yes and yes - firmware is independent of kernel version.

[Marv]

Swapped this in, run as pristine, then using a 'fresh' 22T-23T updated savefile, then my ancient but cleaned full savefile. All good. FPS numbers 1630, CPU idle and base memory numbers the same or maybe a bit lower than 4.9.x, video resolution, sound all normal on the all intel core 2 duo laptop. I'll run with it now on that laptop and check it on the older Pentium M and the newer Bay Trail later.

I'll follow my modded rc.update through a few more updates before I do anything with it but so far it seems more 'rational'.

[mistfire]

@Peebee thank you very much. I also try swapped and modify DISTRO_SPECS of the latest initrd from lxpup for my X-Slacko Slim. It works on boot, however it fail t to detect savefiles but on lxpupsc loading savefile is working. Any ideas to fix that problem on initrd?

[mistfire]

I figured out why my pupsave failed to load from the lxpup's initrd

If the PMEDIA is not specified or not set to "cd", the LOOK_SAVE variable does not set to "yes" and every probed mounted partition does not search for savefile

[peebee]

I figured out why my pupsave failed to load from the lxpup's initrd

If the PMEDIA is not specified or not set to "cd", the LOOK_SAVE variable does not set to "yes" and every probed mounted partition does not search for savefile

See:
How to use the file specification boot parameters as supported in the new init:

http://www.murga-linux.com/puppy/viewtopic.php?t=109650

and

https://github.com/puppylinux-woof-CE/w ... gs/0initrd