Fatdog64-710 Final [4 Dec 2016]

[eowens2]

My Fatdog64_710_final, running from a HD, has been stable for months,
but today something crazy happened to the desktop.

The boot process seems normal, but instead of the usual olive-green Fatdog64-700.jpg wallpaper, the background is white. Most of the icons are missing except for the drive icons in the left lower portion of the screen.

The tray at the bottom of the screen is present, containing the menu button, screen-selector, control-panel icon, wifi-icon etc. The menu button seems to work OK, selected functions open windows appropriately and initiate the correct activities.

When I boot without a savefile, the normal desktop and icons are restored, so it appears that the file(s) I clobbered are in the savefile. I can open the savefile and access the files as usual, but none of the file or directory names are highlited suggesting 'new' content.

Of course I could create a new savefile, but I hate losing the contents of the current one. Any suggestions regarding restoring my original desktop and icons would be appreciated.

[dr. Dan]

@eowens2

Have you backed up your savefile? That's first! Other than changed wallpaper and missing icons, is there any other symptom? Do you usually have additional icons besides the standard "Home, Web Browser, Trash, Help" ones?

If you search everywhere for "PuppyPin", you should find multiple copies. I think the one in /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin is the standard pinboard configuration file. Does it have the same information as /etc/xdg/rox.sourceforge.net/ROX-filer/PuppyPin?

In HTOP, is there a process named "/usr/local/apps/ROX-Filer-jun7/ROX-Filer -p /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin?

You may well have additional problems, and I may not be able to help with them, but this info might be helpful for diagnosis.

[don570]

I've fortunately never had that problem. My suggestion is booting with a special kernel parameter
http://distro.ibiblio.org/fatdog/web/fa ... tions.html

dofsck

Perform filesystem check on filesystems that will be used by savefile and basesfs, before they are used. It will check both the physical partitions as well as the savefile. Only ext2/3/4 and FAT filesystems will be checked.

[eowens2]

@dr. dan,

Thank you for your prompt, informative and useful reply to my misadventure! I have zero knowledge and experience with screen, display organization and ROX-Filer/PuppyPin, so this was a good learning opportunity for me.

Have you backed up your savefile? That's first! Other than changed wallpaper and missing icons, is there any other symptom? Do you usually have additional icons besides the standard "Home, Web Browser, Trash, Help" ones?

Duh...fortunately I had copies of Downloads and other personal files, but not of system files. This event underscores the usefuness of complete backups. There were no other symptoms and yes, I originally had several icons in addition to the four basic ones.

In HTOP, is there a process named "/usr/local/apps/ROX-Filer-jun7/ROX-Filer -p /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin?

Yes, that process was present in my HTOP..

If you search everywhere for "PuppyPin", you should find multiple copies. I think the one in /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin is the standard pinboard configuration file. Does it have the same information as /etc/xdg/rox.sourceforge.net/ROX-filer/PuppyPin?

Using Pfind, I looked for files containing 'PuppyPin', and as you suggested, I found several, and indeed /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin was different from /etc/xdg/rox.sourceforge.net/ROX-filer/PuppyPin.

Fortunately, I had a copy of Fatdog64_710_final on USB stick, so I examined the intact /etc/............./PuppyPin and /root/............/PuppyPin files, and copied the missing lines to /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin on my hard drive, and presto!, my crazy screen was restored.


Thanks again for your interest and showing me where the relevant files reside.

[dr. Dan]

@eowens2

Good! Due to its basic design, Fatdog64 is hard to actually mess up, and fairly easy to repair. The backup you want to have (for future reference) is your savefile (or savefolder). You don't need to back up system files, as they are protected and not easily altered, and available from install media or the .iso.

Fortunately, I had a copy of Fatdog64_710_final on USB stick, so I examined the intact /etc/............./PuppyPin and /root/............/PuppyPin files, and copied the missing lines to /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin on my hard drive, and presto!, my crazy screen was restored.

Did this recover your additional icons?

I recommend don570's advice about doing a file system check from time to time as well. You may not need it just now, but at your next startup, follow the directions in the help file he mentioned.

Thanks for the reply!

[eowens2]

dr. dan,

Quote:
Fortunately, I had a copy of Fatdog64_710_final on a USB stick, so I examined the intact /etc/............./PuppyPin and /root/............/PuppyPin files, and copied the missing lines to /root/.config/rox.sourceforge.net/ROX-filer/PuppyPin on my hard drive, and presto!, my crazy screen was restored.

Did this recover your additional icons?

Actually, the desktop icon collection on the USB-stick-version of Fatdog64 was exactly the same as the HD version which went awry, so yes, the additional icons were recovered.

eowens2

[jake29]

Hello all. I've managed to create an issue with Opera Browser and I believe it started when I installed libnss32 3.21 via Gslapt.

Previous error messages where saying libnss 3.26 or newer was required. At present I am getting the following when launching Opera:

Code: Select all

# opera
[1024/113059.141067:ERROR:object_proxy.cc(573)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1024/113059.141313:ERROR:object_proxy.cc(573)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1024/113059.141553:ERROR:object_proxy.cc(573)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
opera: symbol lookup error: /usr/lib64/seamonkey/libnss3.so: undefined symbol: PR_GetEnvSecure

Any help with this greatly appreciated.

EDIT: As Google_Chrome-62.0.3202.62-amd64-slacko.sfs was working for me, and I noticed it included libnss - I dumped everything in the included lib folder into /lib64 and now Opera is launching again.

[don570]

It looks like you installed a 32bit version of libnss in your install,
then fixed it when you dragged 64 bit versions (amd64) in your system

___________________________________________________

[proebler]

What is the way to address the wpa2/KRACK vulnerability in Fatdog64-710 Final [4 Dec 2016] ?

The package manager shows wpa-supplicant 2.5-x86_64-1.

I have used the Gslapt package manager to remove wpa-supplicant 2.5-x86_64-1 and replaced it with the patched package
wpa_supplicant-2.6-x86_64-1_slack14.1.txz , downloaded from from the Slackware repository
https://mirrors.slackware.com/slackware ... /packages/ .

While I got the [unchanged] wpa_gui eventually to work with wpa_supplicant-2.6-x86_64-1, the end result is unsatisfactory.
The icon for the wpa_gui was no longer available in the [bottom]panel.
I had to invoke the wpa_gui from /usr/sbin , so I placed a link to /usr/sbin/wp_gui on the desktop.
Once invoked, the icon then appears in the panel, the invocation needs to be repeated after every reboot.
While this sort of works, it is only a clumsy hack.
Also, there are no more notifications popping up from the wpa-gui icon in the panel when the WiFi connection is initiated and when connection is established. [auto-connection works]

I suspect that the wpa-gui-qt5 ver.2.5-x86_64-1 of Fatdog64-710 Final [4 Dec 2016] is not [fully] compatible with wpa_supplicant-2.6-x86_64-1 , but I don't have the knowledge to fix it.

It would be nice to have the wpa2/KRACK vulnerability in Fatdog64-710 Final [4 Dec 2016] fixed in a proper way, since it seems to be quite a serious security issue

regards
proebler

[step]

@proebler
Patched packages wpa-supplicant-2.6-x86_64-1.txz and hostapd-2.6-x86_64-1.txz should be available momentarily on ibiblio's CONTRIB package folder. Install from gslapt: make sure to add the contrib folder to gslapt's sources or you won't find the new packages. Normally you would find these packages in the OFFICIAL folder/source, but I can't upload there.

[jd7654]

Patched packages wpa-supplicant-2.6-x86_64-1.txz and hostapd-2.6-x86_64-1.txz should be available momentarily on ibiblio's CONTRIB package folder.

Thanks, will look to apply that later when available. Currently just using dropped in binaries from Slackware package (3 files from /usr/sbin) and that works fine with wpa_gui and all functionality. Is that a recompile for Fatdog or a repackage of the Slack package?

[step]

It a recompile for Fatdog64 from sources with the AUR patch set as of 2017-10-18 applied from https://git.archlinux.org/svntogit/pack ... supplicant

[belham2]

It a recompile for Fatdog64 from sources with the AUR patch set as of 2017-10-18 applied from https://git.archlinux.org/svntogit/pack ... supplicant

@step...thank you for this. I checked, updated Gslapt but don't see your packages yet. Could you post when they're up on ibiblio and/or anybody here post when they see 'em there? This one old laptop has Fatdog on it & it gets used heavily in the house by all. Thanks again, step.




P.S. @jd 7654

Thanks, will look to apply that later when available. Currently just using dropped in binaries from Slackware package (3 files from /usr/sbin) and that works fine with wpa_gui and all functionality. Is that a recompile for Fatdog or a repackage of the Slack package?

Hi jd! Can I ask what specifically you grabbed from Slackware & which binaries you dropped in /usr/sbin? I thought we had to swap out the entire wpa_supplicant program?? Anyhow, figure I'll do your way until Step gets stuff on Ibiblio. Thank you.

[jd7654]

Hi jd! Can I ask what specifically you grabbed from Slackware & which binaries you dropped in /usr/sbin? I thought we had to swap out the entire wpa_supplicant program?? Anyhow, figure I'll do your way until Step gets stuff on Ibiblio. Thank you.

I just grabbed same one in proebler's link above when they came out last week. Instead of install the txz package, I just extracted out the 3 files from /usr/sbin and manually copied over as a quick fix. Installing a full non-native package can cause problems sometimes.

Code: Select all

# ls -l /usr/sbin/wp* | grep Oct
-rwxr-xr-x 1 root root  106136 Oct 16 18:43 /usr/sbin/wpa_cli
-rwxr-xr-x 1 root root   52720 Oct 16 18:43 /usr/sbin/wpa_passphrase
-rwxr-xr-x 1 root root 1816560 Oct 16 18:43 /usr/sbin/wpa_supplicant
# 

[step]

@belham2
the delay is due to ibiblio's internal file system cycle. After ibiblio will update its directory the packages will be visible in Gslapt (after clicking the Update button), and they will propagate to mirrors. It can take several hours before all this happens, but no more than 24 hours.

[belham2]

@jd, thanks a bunch!

@belham2
the delay is due to ibiblio's internal file system cycle. After ibiblio will update its directory the packages will be visible in Gslapt (after clicking the Update button), and they will propagate to mirrors. It can take several hours before all this happens, but no more than 24 hours.

Thanks too, Step! Will look later today/tonight.


Hey, can I ask either of you (or anyone) a question that has always baffled me about Fatdog64-710 and FatdogUpdater vs Gslapt? Look at the two pics below. Now, bear in mind Gslapt is completely updated (just a minute ago), and showing no updates to install. Yet opening FatdogUpdater (FU), and it says there are 25 updates. Huh??

If I ever try to install any of these updates showing from FU, I get a message popup that either says "MD5 checksum mismatch" or "HTTP response code error" and nothing installs. Usually with either of those messages, I automatically know the update is possibly already installed (not always though). So I re-open Gslapt and check, and sure enough some of them are (example in the pic wiht pfind and pfilesearch). I HATE having to wade thru FU trying to find the one that is NOT installed.

What is the problem with FatdogUpdater? Am I the only one that sees this?? My past practice lately has been to completely ignore FU anymore and only use Gslapt. Problem is, Gslapt won't show me each individual update like FU will----f Gslapt does, apologies as I haven't figured out in Gslapt preferences how to make it show each individual update out of a whole mess of them, and let me install only the ones I want. With Gslapt, it is either all and/or none when clicking that "Mark all Updates".

So, I wonder, what the heck is going on with FU? It operates like this in 2 different installs of my Fatdog64-710 (on diff machines)

[proebler]

@step
thanks, I will test your newly compiled wpa_supplicant and hostapd when they become available on ibiblio.

I have been able to fix the function of the wpa_gui.
In /etc/xdg/Startup/
I have modified WpaGui as follows:

Code: Select all

#!/bin/dash
. $BOOTSTATE_PATH
[ "$CONFIGURED_NET" ] && exit # leave if network already configured at boot
sleep 5 # if WpaGui still doesn't show in icon tray, more delays needed
exec wpa_gui -t

modified to

Code: Select all

#!/bin/dash
##. $BOOTSTATE_PATH
##[ "$CONFIGURED_NET" ] && exit # leave if network already configured at boot
##sleep 5 # if WpaGui still doesn't show in icon tray, more delays needed
exec /usr/sbin/wpa_gui -t

This now brings the wpa_gui back into the panel tray at boot up and the popp-up notifications work again.
Learned, that -t places it into the tray.
happy now
proebler

[jd7654]

the delay is due to ibiblio's internal file system cycle. After ibiblio will update its directory the packages will be visible in Gslapt (after clicking the Update button), and they will propagate to mirrors. It can take several hours before all this happens, but no more than 24 hours.

Installed and working OK. That's just for regular wpa function, as I can't really test the Krack security patch nature of it without proper tools.

Just noticed this one is quite a bit smaller than other ones. I've been patching everything I have for Krack last week: Arch, Fedora, Debian, Puppy, etc. The v2.4 and v2.6 are around 1.7-1.8mb typically. Some sizes below for wpa_supplicant 2.6 on this system:

Code: Select all

# ls -l /usr/sbin/wpa_supplicant
-rwxr-xr-x 1 root root 1273200 Oct 22 20:07 (Fatdog)
# ls -l /usr/sbin/wpa_supplicant
-rwxr-xr-x 1 root root 1816560 Oct 16 18:43 (Slacko/Slackware)
# ls -l /usr/sbin/wpa_supplicant
-rwxr-xr-x 1 root root 2060056 Oct 15 23:27 (Arch) 

[step]

@proebler
Looking at the code that you commented out I guess that CONFIGURED_NET is set therefore the script exits early. To confirm this you could add
echo "CONFIGURED_NET($CONFIGURED_NET)" >/tmp/CONFIGURED_NET.txt
before the line that starts wpa-gui -t, then reboot, then examine /tmp/CONFIGURED_NET.txt

Fatdog64's standard initrd script sets CONFIGURED_NET when the boot manager kernel line includes dev:ip or dev:dhcp, which instruct initrd to pre-configure the network device. This happens during boot, way before WpaGui runs. When the latter sees that ONFIGURED_NET is set it assumes that wpa-gui isn't needed and exits early.

This is how it _should_ work. Do you boot from a net device? Can you please confirm you do/don't with the "echo ..." method I outlined above?

If you aren't booting from a net device I could think that either wpa-gui -t crashes with the uncommented lines in place, or that it doesn't crash but lxqt-panel fails showing the wpa-gui tray icon. You can confirm either case by running htop and checking whether wpa-gui is running.

@belham2
One possible cause could be that FU compares the local package state with ibiblio's official repo only, while gslapt compares against the union of all sources. Moreover FU compares the package date only, while gslapt is more sophisticated and considers other attributes.

@jd7654
The version 2.6 size for Fatdog64 is well in line with the version 2.4 size for Fatdog64.

[dr. Dan]

@belham2
In gslapt, click View>Upgradable,
or
click Mark All Upgrades, then click View>Marked
You can then mark or un-mark items as you see fit. Does that accomplish what you wish? I gave up on the FatdogUpdater some while back, since it is not integrated with gslapt. If it works better in the future, it will be very handy.

@step
Thanks for the wpa-supplicant update!

For the developers, since many or most of the packages for 700 will work for 710, would it be appropriate to include the 700 repositories in the 710 source list by default? Would it be good also to include Smokey01's repository? Are there any others out there which would be nice to know about? Alternately, could packages be copied (with permission) from these repositories, or the sites cited in the contrib thread, into the current contributed repository?
If I hadn't gone looking for more, I wouldn't have found a number of useful programs. A new user could easily think that Fatdog64 is not as "fat" as it in reality is, as a couple of recent reviews have wrongly claimed. Furthermore, packages which are not in the repositories, such as some listed in the contrib thread, don't integrate with gslapt, and so cannot be removed from the system or updated so efficiently. Perhaps this could be considered for a future release...

Thanks!