Page 3 of 23

Posted: Sun 31 Dec 2017, 04:45
by jamesbond
jake29 - your problem seems similar to stemsee.
New hardware, new firmware - most probably UEFI.
Something has changed, requiring grub2 update.

Sage - my apology I've been busy, so progress is slow.

Meanwhile, Happy New Year everyone. See you in 2018.

Posted: Sun 31 Dec 2017, 11:47
by Sage
NIC issue resolved - advised to jb.

Posted: Sun 31 Dec 2017, 14:07
by stemsee
Replaced grubx64.efi (2013 > 2016) and grub2.efi and booted ok.
ha ha!

Having enabled BC-wl wlan0 is in wired pane on wpagui with no way to connect. Used Wifi-Scanner-2 (Ad) script only and voila! problem solved... ;-)

The importance of Vulkan

Posted: Mon 01 Jan 2018, 13:40
by jake29
I would like to present some more perspective for those dismissive about the value of Vulkan Graphics Drivers. Some key features include:

Code: Select all

(1) Reduced driver overhead, reducing CPU workloads.
(2) Reduced load on CPUs through the use of batching, leaving the CPU free to do more computation or rendering than otherwise.
These points suggest how beneficial it is when used with ageing CPUs, in comparison to alternative GPU drivers.

A cutting-edge graphics card is not a requirement for Vulkan API support; many cards (AMD and Nvidia) that came onto the market at the beginning of 2012 are compatible. https://en.wikipedia.org/wiki/Vulkan_(A ... patibility

Also Media Players can benefit from utilizing Vulkan. MPV Player already has some degree of support implemented.

https://www.phoronix.com/scan.php?page=news_item&px=MPV-Vulkan-Next-Better

Posted: Mon 01 Jan 2018, 13:50
by rufwoof
SneekyLinux review : https://youtu.be/PmmEimUovmo

recover from bad superblock, while checking savefile

Posted: Mon 01 Jan 2018, 19:10
by FanDog
Awesome! Couldn't wait for the new release <3 Will be putting it to the test briefly. :)
will be visible when you run gslapt and you can remove it from gslapt. Any other behaviour is a bug. If you find this, can you please report
One possible bug was that, while uninstalling seemed to work, the menu entry was not removed. Although this could be related to the following 'bug' (which I came here to report and saw 720 under the xmas tree \o/ )

There have been a few files giving input/output error (cant delete them, nor even stat them), one of them related to a package I tried to install. Now, even gslapt wont load (it complains it cannot find said package). This is 710, just to be clear. (sorry to post here, but the goal is to request a new feature, not fix this)

It could be hardware error but I suspect it was some interaction with the Fatdog merging process. Either way the problem is, rebooting with savefile=none and doing a fsck says the FS is clean, I was even tempted to try to umount it and manually recover a superblock backup, as per the next link. (which is pretty much the problem Im having) but it was already getting too dangerous for my skillset (running it on all those overlayed, cryptoed, ram mounts?! :shock: ) Now that 720 is out, I'll simply migrate instead :)

https://ubuntuforums.org/archive/index. ... 45536.html

okay, so this whole post was basically a request to add such capability to the savefile utility, AND to thank you all for the work put into this great distro! My favorite (pre-compiled :twisted: ) distro. My2018 couldn't have began better!

Cheers.

Posted: Mon 01 Jan 2018, 21:39
by step
stemsee wrote: Having enabled BC-wl wlan0 is in wired pane on wpagui with no way to connect. Used Wifi-Scanner-2 (Ad) script only and voila! problem solved... ;-)
Great that you can connect using your script! The wireless interface shouldn't show up in the "wired" pane to begin with, so let's dig deeper as to why it happens.

Could you please go back to that system and:
1) Confirm that wlan0 still shows up in the wrong pane (wired)
2) Do _not_ connect through Wifi-Scanner-2
3) Open terminal, run the following commands and post results. Thank you.

Code: Select all

ifconfig wlan0
readlink -f /sys/class/net/wlan0/device/driver/module
find /etc/wpa_gui -print0 | xargs -0 grep '"";
find -H /sys/class/net/wlan0 \! -type d -print0 | xargs -0 grep ""
In the screenshot you posted I can see that wlan0 did actually connect to a DHCP server that allocated an IP address for wlan0. Whether that makes any sense in your environment I can't tell. Was the screenshot taken _before_ or _after_ connecting through your script?

What's the "Ad" in "Wifi-Scanner-2 (Ad)" stand for?
What's "BC-wl" in your post?

Thank you.

Posted: Mon 01 Jan 2018, 23:52
by stemsee
Yes it still shows in wired selector.

The ip is there after connecting with my script.

BC-wl is the fatdog service to load the module.

I could not get the last two commands to work in xterm.

the first two returned the following.

Code: Select all

ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 38:b1:db:d3:cc:33  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7191 errors:0 dropped:195 overruns:0 frame:21273
          TX packets:4892 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7838748 (7.4 MiB)  TX bytes:608994 (594.7 KiB)
          Interrupt:18 

/sys/module/wl
Ad - advertisement!

Posted: Tue 02 Jan 2018, 19:26
by stemsee
The wlan0 interface is now in the wifi pane! I think that when it is discovered in X it goes to wired pane, but during boot with a savefile it gets put into the wireless pane! For a while there was somewhere code flashing in the wpa_gui pane then it settled down and I was able to connect.

Posted: Tue 02 Jan 2018, 22:52
by stemsee
I found also that geany 1.31 has a bug which prevents executing in xterm the script which is being edited. I compiled and installed geany 1.32 from source and the problem has gone.

Chrome / Opera Sandbox issues

Posted: Fri 05 Jan 2018, 00:03
by jake29
I'm assuming this is related to the moving of Spot. Can anyone suggest how to deal with apps - in my case latest versions of Chrome and Opera - that now refuse to run as Root.

Code: Select all

# opera
[0105/000046.293869:ERROR:zygote_host_impl_linux.cc(88)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Fortunately with latest stable build of Opera (50.0.2762.45) - it will launch with --no-sandbox. Chrome refuses to.

What is the correct way to install these apps now?

Posted: Fri 05 Jan 2018, 14:25
by step
stemsee wrote: I could not get the last two commands to work in xterm.
I figured you couldn't. Would you please post the error messages from those two commands? Thank you, also for posting the other stuff.

Re: Chrome / Opera Sandbox issues

Posted: Fri 05 Jan 2018, 14:51
by step
@jake29, I run opera as an sfs, pretty much as we discussed in a previous thread. However, I run it as spot, from a command line run: run-as-spot opera &
Of course, this will start a fresh profile under spot's home. You can try to port root's profile to spot's home this way: (as root)

Code: Select all

cp -a ~/.cache/opera ~spot/.cache/
cp -a ~/.config/opera ~spot/.config/
chown -R spot:spot ~spot/.cache/opera ~spot/.config/opera
run-as-spot opera &
Then change the downloads folder path in opera settings to /home/spot/Downloads.
Spot needs to own all opera cache and profile files in spot's home at all times. It doesn't need to own symbolic links.
Pre-downloaded files in spot's Downloads folder should already be under spot's ownership.
There is a slight inconvenience in running the browser as spot because the browser can't access folders under /root (including ~/Downloads). However, it should be more secure.

Posted: Fri 05 Jan 2018, 14:58
by stemsee
Zarfy works much better than before in fd-720. It actually auto detects hdmi and activates it. When first plugged in it extends the display to 2nd display resolution (4k tv). If then restartX I get mirrored displays both at primary display res (1080). For me this is great, as i don't actually need to start up zarfy as previously

I also discovered that the init scripts and boot process has changed significantly (system-init) > (busybox-init (binary)). . . making it difficult to boot the main.sfs with any other initrd/init script. Also there are significant changes in the use of permissions or ACLs on root directories, it seems. Previous 710 would break with the latest upgrades using gslapt.

720 is working great now, and I wonder if all the technical changes are listed somewhere?

installing to a partition

Posted: Sat 06 Jan 2018, 01:28
by dr. Dan
How small can a Fatdog64 installation partition be and still function? Either with save folder there or elsewhere?
What is ideal as a minimum?
Thanks,
Dan

Posted: Sat 06 Jan 2018, 07:25
by snayak
Dear All,

I am using Pidgin 2.11 on fatdog720.
I am unable to logging into pidgin using my gmail account.
It throws invalid ssl certificate error. https://developer.pidgin.im/ticket/17118

Did you get success using your gmail id?

Sincerely,
Srinivas Nayak

Posted: Sat 06 Jan 2018, 11:21
by snayak
I found pidgin 2.10.11 in fatdog 720 repo. It worked!

Posted: Sat 06 Jan 2018, 11:51
by SFR
@Snayak: they say it's fixed in v2.12.0. Can you confirm?
http://distro.ibiblio.org/fatdog/packag ... 6_64-1.txz

Greetings!

Posted: Sat 06 Jan 2018, 20:05
by stemsee
There is a script which is backing up the /etc/resolv.conf file using pid number in the name, see pic .... resulting in a build up of resolv.conf-'pid number' files in /etc see pic

I haven't found the culprit yet!

Posted: Sat 06 Jan 2018, 21:01
by step
stemsee wrote:build up of resolv.conf-'pid number' files in /etc see pic
The picture shows very close PIDs, so you're looking for a rapid fire sequence of the same script or command. In an unmodified Fatdog64-720 system - first-time booted with an empty savefile/savefolder - /etc/resolv.conf is updated by dhcpcd, which is (re)started each time a connection is brought down and up again. You can watch this happening by running htop and selecting "restart connection" from the wpa_gui tray icon right-click menu. You could also try to set a watch on resolv.conf with command inotifywait -m /etc/resolv.conf or make use of lsof to see which process is changing your file.