Fatdog64-710 Final [4 Dec 2016]

[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!

[belham2]

@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!

@dr. Dan: Darn it, while do i always forget to click "view" and instead expect the updates to popup individually, grrrr @ myself Thanks dr. Dan.


@all--regarding step's "wpa-supplicant" update----is anyone seeing this "after" updating? After applying Step's update, I've nearly completely lost my wifi in the 'frugal' install of Fatdog64-710 laptop everyone uses in the house. This is the message that appears in terminal:

Code: Select all

SIOCSIFFLAGS: Operation not possible due to RFKILL

...and it loops repeatedly on this as wifi goes beserk....sometimes the wifi re-connects, then sec/mins later, it disconnects again......popping this message up over and over.

Yes, it's an older Intel laptop

I opened a terminal and typed in:

Code: Select all

 rfkill unblock wifi

then..

Code: Select all

rfkill unblock all

then..

Code: Select all

rfkill list

..to make sure both hard and soft block were set to "no", but it didn't matter, the problem kept repeating itself and it's like the laptop suddenly dropped acid and/or is psychotic.

So, I had to rollback to the full backup I keep of the 'frugal' Fatdog64-710, to how it was before I updated with Step's 'wpa-supplicant', and now, things are fine again and the laptop's wifi is strong & stable as a rock.


If I can't figure out why and/or how to fix this in the next few days, then I'm going to be forced to remove Fatdog64 completely, as I've 'wpa-supplicant' patched every other OS in the house for the family. It is just Fatdog64-710 and that damn Intel laptop. Will post if I can get it figured out today and/or tomorrow.

[dr. Dan]

@belham2:

Does it cause the same problem if you reboot without savefile, then install just the wpa-supplicant update?

[step]

I was going to ask the same question...

[step]

I recently decided to attempt to make a package, so I went to add the fd64-devx_710.sfs from the control panel SFS manager, but it wasn't listed. ... A quick re-check of the SFS manager shows it not listed still. Just an FYI.

Thanks to dr Dan, Jake29 and others who have reported this kind of issue. The Fatdog64 team has re-written the script for the next version of Fatdog64. The new script is deemed release quality. Unpack the attached tar file in your root folder (/). You can start the SFS manager from the Fatdog64 control panel or from the command line.

[belham2]

I was going to ask the same question...

Hi Step and Dr. dan,

Yes, even removing the savefile, then booting a pristine Fatdog64-710 and installing step's wpa-supplicant fix, the issue kept occurring. Booted (on another USB stick) a pristine Fatdog64-710, and not installing step's fix, there was no problems as the wifi connected and was stable as a rock.

So, I was forced to remove Fatdog64 from the laptops here as a choice for the family/kids, and go to Slacko 700 & Phil's & Barry's latest Xenial-based releases where I had already put in the wpa_supplicant fixes for them, with no problems.

Thanks for your help, hopefully I can find some time in the next month or so to figure out why, and 4 different laptops with different set ups and wireless chips, that step's wpa_supplicant fix caused this behavior.

Saving grace is at least for myself, on a "lan" network, I keep Fatdog64-710 up and running in a 'frugal' install-----because I like it.