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

[Marv]

Update and some additional info on my frugal install above:

Ran for a day with the 4.3.2 kernel. No problems at all (I don't use the top panel). CPU use in line with what I expect. Newest chromium SFS, ancient Opera, Firefox, geany, evince, pmusic, glxgears etc.

Switched kernels back using change_kernels keeping my save file. Kept the wpa2 connection no problems at all. CPU use as above. Removed my profile and reconnected with Frisbee OK.

Hid the save file and rebooted multiple times with no savefile. Puzzlement and then some reproducibility.

IF I select the firewall (tick the box in the firstrun dialog box), then try and connect with Frisbee It comes up up in the fubarred state I saw earlier. IF I do not tick that box, Frisbee connects correctly and I can ping and post using Firefox. Did it a couple of times and same result. Doesn't matter whether I use the default firewall options or poke a hole for CUPS.

Starting the firewall after the connection is established works. I just did it.

Make any sense to you?

[gcmartin]

Hello Marv, et al.
There should be a note in FirstRUN for wireless users to start the firewall after wireless is running. FirstRUN does not have a WOOFCE owner.

There are several ways developers might consider implementation:

1. Mouseover the firewall entry.
2. Remove firewall entry and defer it to the subsequent utility that follows FirstRUN.
3. And others, I'm sure.

Hope this is helpful, somehow.

[Marv]

Having leapt over that lil trap for the unwary, continuing to use 16.01.1. Jiggered the menu to substitute Save for Run which I never use, set up lxpanel, added external browserdata symlinks, added lx_right_clicks (could it be added by default?) and Desktop icons. Installed opensans fonts for chromium use. Not much else. I can live with lxpanel. Doing taxes, listening to streaming audio... Snappy'n'happy on this core 2 duo.

[01micko]

Latest woof has an updated firewall_ng to get around your issue Marv.

It's one file so you can search woof-CE and grab it now if you want.

[Marv]

Latest woof has an updated firewall_ng to get around your issue Marv.

It's one file so you can search woof-CE and grab it now if you want.

Thanks, I'll grab it.

Update: Grabbed it, made it executable, unsquashed the main LxPupSc SFS and replaced the older firewall_ng with it. Resquashed and did a pristine frugal boot with that SFS, ticking the firewall box in the firstRUN box. Normal connection using Frisbee and the tray firewall control icon is red waiting for setup. Set it up from there and posting from that pristine now.

[peebee]

LxPupSc-16.01.03-pae.iso {devx} {kernel sources}
md5 = 5d0295a363818ab776dd0474d13f462e

{slackocurrent-16.01.2} is made from Slackware-current as of 17-jan-2016 (evince rebuild as a consequence)

BUILD_FROM_WOOF='testing;a5d36ab;2016-01-17 08:35:59 +0200'
so includes the recent changes to default apps chooser and other changes like firewall_ng

Update to LxPanel-0.8.1

[gcmartin]

Thanks @Peebee

If I use ISOmaster to add the DEVX SFS file (or any SFS for that matter) to the the root of the ISO, will your PUP's boot system pick it up automatically upon booting so that I don't have to run sfs-load? Or am I required, after boot, to instruct the system accordingly?

Thanks in advance for any answer.

For the SlackoCurrent you offer on your download webpage, I am showing

Code: Select all

3426043debb705ab4b7fbd2712492972  slackocurrent-16.01.2.iso
d26aa04c8cc143c4f0f15f424dc67602  devx_slackocurrent_16.01.2.sfs

[peebee]

Thanks @Peebee

If I use ISOmaster to add the DEVX SFS file (or any SFS for that matter) to the the root of the ISO, will your PUP's boot system pick it up automatically upon booting so that I don't have to run sfs-load? Or am I required, after boot, to instruct the system accordingly?

Thanks in advance for any answer.

For the SlackoCurrent you offer on your download webpage, I am showing

Code: Select all

3426043debb705ab4b7fbd2712492972  slackocurrent-16.01.2.iso

md5 is correct for slackocurrent iso

not sure about the sfs question as I've never tried it - this is a woof-ce build so will behave like any other similar build - I believe that sfs renamed as adrv or ydrv should be supported - see /etc/DISTRO_SPECS for full names - but not any arbitrary sfs. Suggest you experiment with a frugal install.

I've just tested with chromium sfs renamed to both adrv.... and ydrv.... and both worked correctly.

[Marv]

Downloaded, md5 checked. Tested pristine frugal install as per 4 posts up and the updated firewall_ng is doing it's job. Normal connection and communication. Now back to update my save file and carry on.

Update: Printing to HP4500 still requires the patch rcrsn51 sent me via PM to avoid "Filter failed" error. I'll duck under my desk and attach it here Scanning, both from USB connected Epson CX5400 and networked HP4500 both working perfectly set up per his first post here. All in preparation for deep-sixing the last surviving (internal LAN only) windows XP box and replacing it with the 10 Watt always-on Baytrail desktop.

A quirk. I ignored it til now but it shows up on both the core 2 duo laptop and the Bay-Trail desktop. Frugal Grub4Dos install of 16.01.2 in both cases, done both updating a save file and creating a bare minimum savefile. Not seen on first boot. The first yaf-splash boxes (see the screenie) do not close until I mouse over them. Then they are erased and all is normal. If yaf-splash is run in a terminal once lxde is running it behaves normally. If 1-lxde-startup.sh is rerun later the splashes clear normally. On a wmrestart they clear normally. Always on a reboot they don't clear. Pretty different machines wrt timing and one running a Frisbee wireless connection and the other a wired ethernet dhcpcd only connection so timing quite different there too. I've played with sleeps, moving then about in the boot order, disabling the intel_pstate governor on the Bay-Trail.. to no avail. Can you reproduce this or am I a oner?

Edit: Another screenie added. The yaf-splashes do not complete until they are moused over. Then they disappear from the task manager and the screen. This is default behavior for gtkdialog-splash. If somehow the timeout fails, Exit on mouseover still functions. Question is why does the timeout fail in certain cases? Clock being set after splash sent? ?? Reverting to actual yaf-splash (v1.02), this behavior does not occur. They time out correctly. The notifications from Frisbee/dhcpcd still fail as they must call gtkdialog-splash directly.

[Marv]

Ya, bad form but that post was getting long.

The failure of splashes to close isn't a timer problem but rather a failure of line 324 in /usr/lib/gtkdialog/box_splash in this particular instance. It exits the timing loop without killing even though task manager and some diagnostic echoes I put in show the PID is still alive and correct.
The line read:

Code: Select all

[ "`busybox ps | grep "^${dlgPID} "`" == "" ] && exit #already killed.

I changed it to:

Code: Select all

[ "`pidof yaf-splash | grep "$dlgPID"`" = "" ] && exit  #already killed.  Marvmod

All splashes I throw at it now close ok. Checked on Bay-Trail, core 2 duo, and Pentium Ms. Done mostly for my curiosity.

[gcmartin]

Thanks for sharing the SFS processing, @PeeBee. Muchly appreciated

5 years ago, @TaZoC (who I'm sure you know his health took him from us) introduced SFS boot-time processing in his distro, LightHouse64. Not sure exactly how he did so, but in it, I was able to add SFSs to the root of the DVD folder, and his distro would find and incorporate it into the booted system. No other developer has found how this is done. @Dry Falls has taken over to keep @TaZoC's brilliance alive in his Just-Lighthouse series.

I keep thinking others may have seen @TaZoC's work; and added this ability to their distro.

This is NOT a request for you to review that. But, I do THANK YOU for your guidance.

[mavrothal]

The failure of splashes to close isn't a timer problem but rather a failure of line 324 in /usr/lib/gtkdialog/box_splash in this particular instance. It exits the timing loop without killing even though task manager and some diagnostic echoes I put in show the PID is still alive and correct.
The line read:

Code: Select all

[ "`busybox ps | grep "^${dlgPID} "`" == "" ] && exit #already killed.

I changed it to:

Code: Select all

[ "`pidof yaf-splash | grep "$dlgPID"`" = "" ] && exit  #already killed.  Marvmod

Yep. That's a bug that happens when the ps output has processes with more digits in their ID. ie the dialog is PID=1234 but there is also a process with PID=12345.
The proposed solution can not distinguish between the two and although not a major problem, something like this may be more accurate.

BTW 10-20% of the times 16.01.02 fails to shutdown cleanly. Anyone else sees this?

[peebee]

Yep. That's a bug .....something like this may be more accurate.

BTW 10-20% of the times 16.01.02 fails to shutdown cleanly. Anyone else sees this?

Hi Mav & Marv

Sorry late to the party 'cos updates don't get notified by the forum so only just seen Marv's original report...

Mav - thanks for the bug fix - I'll use a new woof-ce download in the next build.

I haven't seen the shutdown problem - can you elaborate on "fails to shutdown cleanly"? what is the problem?

If there wasn't a problem in 16.01.01 then its probably been introduced by the latest woof-ce as I don't think the other .02 changes from slackware would have impacted - but I may be wrong!

If you have time and enthusiasm to do so, perhaps you could see if the slackocurrent-16.01.2 iso has the problem? Meanwhile I'll try shutting down a few times....see below

10-20% problems are not easy to fix!!

Thanks
peebee

[peebee]

Hi Mav

Just did (yawn!) 10 reboots of slackocurrent (k4.1.11) followed by 10 reboots of LxPupSc (k4.3.3) on my desktop pc (nvidia graphics) and all were ok....

If I can keep awake I'll try similar on my laptop later....

Code: Select all

System:    Host: puppypc3960 Kernel: 4.3.3-EmSee-32-pae i686 (32 bit)
           Desktop: LXDE (Openbox 3.6.1) Distro: Slacko-C Puppy 16.01.2
Machine:   Mobo: ASRock model: N68C-S UCC
           Bios: American Megatrends v: P1.60 date: 09/19/2011
CPU:       Dual core AMD Athlon II X2 260 (-MCP-) cache: 2048 KB 
           clock speeds: max: 3200 MHz 1: 1900 MHz 2: 3200 MHz
Graphics:  Card: Failed to Detect Video Card!
           Display Server: X.org 1.18.0 drivers: nouveau (unloaded: vesa)
           tty size: 80x24 Advanced Data: N/A for root
Audio:     Card-1 HDA NVidia driver: HDA-Intel
           Card-2 pcsp driver: PC-Speaker
           Sound: Advanced Linux Sound Architecture v: k4.3.3-EmSee-32-pae
Network:   Card: Failed to Detect Network Card!
Drives:    HDD Total Size: 442.4GB (21.1% used)
           ID-1: /dev/sda model: ST3320620AS size: 320.1GB
           ID-2: /dev/sdb model: ExcelStor_Techno size: 82.3GB
           ID-3: /dev/sdc model: ST340014AS size: 40.0GB
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 164 Uptime: 6 min Memory: 105.1/3786.7MB
           Client: Shell (bash) inxi: 2.2.28

[Marv]

Yep. That's a bug that happens when the ps output has processes with more digits in their ID. ie the dialog is PID=1234 but there is also a process with PID=12345.
The proposed solution can not distinguish between the two and although not a major problem, something like this may be more accurate.

BTW 10-20% of the times 16.01.02 fails to shutdown cleanly. Anyone else sees this?

Tested the better fix and it is working fine. Thanks. No stuck flashes on reboot now. I also see an occasional failed shutdown but not often enough to be able to chase it. My feeling is it occurs after longer times up with some lid suspends in the mix. I'll keep an eye on it now.

[Marv]

@mavrothal or peebee,
I have been working with LxPupSc on my Bay-Trail box and think I can get shutdown to fail often enough to work on it but don't really know how best to procede. Any suggestions? Failure is to black screen, able to type but xwin, poweroff etc. not run on enter key. Control alt backspace has no effect. Hard power off with desktop power button is the only way out. The savefile isn't seriously dinged...I check it on boot anyway.

[peebee]

@mavrothal or peebee,
I have been working with LxPupSc on my Bay-Trail box and think I can get shutdown to fail often enough to work on it but don't really know how best to procede. Any suggestions? Failure is to black screen, able to type but xwin, poweroff etc. not run on enter key. Control alt backspace has no effect. Hard power off with desktop power button is the only way out. The savefile isn't seriously dinged...I check it on boot anyway.

Hi Marv

see below

Many thanks for your help
Cheers
peebee

[mavrothal]

The problem is present in 01.01 too.
Is happening mostly when you shutdown and not when you reboot.
I think the problem is that somehow /usr/bin/wmpoweroff is a real file instead of a link to wmexit (as it is in woof).
Delete /usr/bin/wmpoweroff, symlink it to /usr/bin/wmexit and see if this still happening (looks OK here)

[peebee]

The problem is present in 01.01 too.
Is happening mostly when you shutdown and not when you reboot.
I think the problem is that somehow /usr/bin/wmpoweroff is a real file instead of a link to wmexit (as it is in woof).
Delete /usr/bin/wmpoweroff, symlink it to /usr/bin/wmexit and see if this still happening (looks OK here)

Hi Mav

You have probably found it - many thanks - LxPup does have a patched wmpoweroff with an addition to kill lxsession.

I remember seeing the woof discussions and changes concerned with putting all the session control code into a common script, but hadn't made the corresponding changes to my LxPup builds.

I'll get rid of the patched wmpoweroff and make a new build.

Cheers & thanks again
peebee

[peebee]

Delta: LxPupSc-16.01.02-pae.iso___LxPupSc-16.01.03-pae.iso.delta

New iso: LxPupSc-16.01.03-pae.iso

md5 of iso: 4bec3bc4d565154ca3772b046cecf590