Fatdog64-802/801/800 Final [21 May 2019]

[rufwoof]

So I'm booting fatdog usb stick frugal installed (grub4dos) with the initrd having no fd64.sfs inside it (around a 75MB sized initrd), with multi-session saves, back to usb. Event manager save interval is set to zero, so I can unplug the usb once booted, only need to reattach it if I want to run a save action, or boot again.

Code: Select all

kernel /vmlinuz midshell net=wpa2:xxssidxx:xxpasswordxx:wlan0:dhcp pkeys=uk savefile=direct:multi:uuid:2d5fb1e2-5276-4950-bc8c-0b3c1ec9cfa6:: video=640x400

At my midshell point, i.e. just before initrd loads fd64.sfs, in the initrd cli I have been copying in a fd64.sfs to / in the ramdisk so it uses that when initrd's execution is resumed to load the gui desktop. I have a fd64.sfs on my hdd (sda1), stored in the root folder to facilitate such copying. But I thought I'd try just sym linking that instead, so I mounted sda1, sym linked the hdd fd64.sfs to /fd64.sfs inside the ramdisk, and then resumed initrd boot ... and it worked. htop shows significantly less memory being used, normally after first booting/loading the gui desktop htop is up at around over 1GB used but now its down at 692MB type level. A 300MB saving which ballpark compares to the size of the 340MB fd64.sfs size.



My (muti-session) save file is quite large, contains google chrome etc. and is around 190MB that iirc expands to around 400MB, which is all loaded into ram.

I hadn't expected that sym linking of fd64.sfs from within initrd/ramdisk to a hdd based fd64.sfs to work, I thought that the ramdisks sym link to sda1 fd64.sfs would be lost/broken, or inaccessible after the switch root, but seemingly not. I even fully loaded 3GB+ of ram usage so that swap was being used, and the system continued to work fine. I had also expected that sda1 would have to remain mounted, but no, I can mount and unmount it from within the main gui desktop.

Don't know what's going on, but that's pretty amazing in my book. Currently, with chrome loaded and posting this ...

Code: Select all

# free -m
              total        used        free      shared  buff/cache   available
Mem:           3406         422        2066         579         917        2022
Swap:         16383           0       16383
# 

To double check, I umounted sda1 (my HDD) and using a terminal cd'd to /mnt/sda1 ... and it was empty. Remounting again and /mnt/sda1 showed the files/folders. I guess fd64.sfs has just been cached, rather than allocated to fixed ram ???

EDIT: Noticed in /dev/initrd.err

==== end of initrd ====
/usr/bin/auchk: Checking /aufs/pup_save for aufs
/usr/bin/auchk: [Pass 1] Illegal whiteout
/usr/bin/auchk: [Pass 2] Remained pseudo-links
/usr/bin/auchk: [Pass 3] Remained temp files
rmdir: failed to remove '/mnt/+*': No such file or directory

So it could be a feature (undocumented bug) that /mnt/sda1 in initrd isn't released. Also see from the linux documentation that initrd :

Note: /dev/initrd is read-only and it can only be used once. As soon
as the last process has closed it, all data is freed and /dev/initrd
can't be opened anymore.

So in /mnt/sda1 being mounted in initrd, after switch-root the initrd isn't freed because of the open mount process. ???

[rufwoof]

Might I propose adding Terminus bold 32 console font to the next release of Fatdog. At 3KB that's a relatively minor increase whilst adding a better IMO font for the likes of displaying BBS's. Better than the current big font - that is OK, but isn't as good at displaying ansi graphics.

Add to /lib/boot/consolefonts within initrd and /usr/share/consolefonts within the main fd64.sfs ... and use setfont <filename> to activate it.

If that's renamed to bbs.psf.gz then that would fit well alongside the big and bbig choices i.e. ctrl-alt-F2 and login, and then run 'setfont bbs' before telnet'ing to a BBS i..e TERM=linux telnet blackflag.acid.org

[dr. Dan]

New (to me) laptop, and it's up and running with 802. It has a 1920x1080 screen, so I've been making adjustments for readability.

I'm seeing an issue with the new control Panel. As the screen capture shows, it doesn't resize smoothly. The Htop screenshots show an issue in the processes running the tabs after resizing. It doesn't happen all at once. I changed the initial dimensions in the script, so I don't have to resize it in the first place. (The high-dpi setting in the script didn't kick in for me.)

Also, I've attached a screenshot of the popup window when a program isn't shutting down correctly. It's been like this for me about from the beginning (4 years ago), but I haven't gotten around to asking about it. Where do I find the file to edit the get readable text?

I hope I've kept the files small.

Thanks all, it continues to be a pleasure.

Dan

[step]

Dan, re the popup window look, are you using the default Fatdog theme or switched to something else? Does the popup always look like that or does it look right sometimes? What happens if you boot without a savefile, can you test the popup window? Here some steps to open the popup at will:
1. open a terminal window
2. type yad --text-info and press ENTER
3. when yad is displayed switch to the terminal and press Ctrl+Z, this will stop the yad process
4. now close the yad window, either from its X corner or the app bar; yad will not close
5. after a few seconds you'll see the popup dialog.
To eventually close yad go back to the terminal and type fg then press ENTER.

Code: Select all

# yad --text-info
^Z
[1]+  Stopped(SIGTSTP)        yad --text-info
# fg
yad --text-info
Terminated
# 

As regards your control panel issue, I can take a deeper look. Contact me privately next week, please. Thank you.

[step]

Dan, some quick thoughts. What's the value of key Xft.dpi in file /root/.Xdefaults?
What happens if you edit /usr/sbin/fatdog-control-panel.sh and insert this line before line 103, so that the new line becomes 103

Code: Select all

	"--fixed" \

Be careful when you paste from the forum; make sure that there are no extra spaces after the end of the line (after the backslash character in this case).

[SFR]

@Dr. Dan: I can reproduce the pop-up window issue.
It's a "feature" of 23oz Openbox theme.
The relevant colors are defined in /usr/share/themes/23oz/openbox-3/themerc, lines 231 & 239:

Code: Select all

osd.button.unpressed.bg.color:			#303030
...
osd.button.focused.bg.color:			#303030

I guess we should change it to something brighter...

@Step: I can also repro the CP issue, where yad processes are maxing out the CPU and one or more tabs become blank.
It takes some rapid resizing, though, and it seems to be much easier to reproduce in VBox with limited CPU resources, than on real HW.

Greetings!

[dr. Dan]

@SFR: I've had the control panel issues on both the new higher dpi unit, and the previous ~1200x800 which was my first 800 series install. I don't typically resize windows like in the screen capture, but I had similar results with both, after just resizing once, and both with i5 processors and sufficient (8Gb, 4Gb) RAM. I've yet to try a VM of anything, but perhaps soon.

Thanks for isolating the 23oz issue. I do use it, somewhat modified, so I'll make changes and offer suggestions.

@step: I'm still on 721 on this computer, so I'll test later and let you know.

Thanks to you both.

Dan

[rufwoof]

initrd version of dropbear doesn't seem to support encryption of your private ssh key.

I opted to install ccrypt http://ccrypt.sourceforge.net/ as a wrapper to accessing my ~/.ssh db_id_rsa key (that I converted from openssh using drobbearconvert openssh dropbear id_rsa db_id_rsa)

Code: Select all

cd /root/.ssh
ccrypt -c db_id_rsa.cpt >/root/.ssh/db_id_rsa
echo "#!/bin/sh" >/tmp/cleanup
echo "sleep 20" >>/tmp/cleanup
echo "rm /root/.ssh/db_id_rsa" >>/tmp/cleanup
echo "rm /tmp/cleanup" >>/tmp/cleanuup
chmod +x /tmp/cleanup
/tmp/cleanup &
chmod 0600 /root/.ssh/db_id_rsa
ssh -i /root/.ssh/db_id_rsa <userid>@ny1.hashbang.sh

I've set it to leave the ssh key open for 20 seconds to allow for ssh connection (once connected the key is no longer required).

Would be nice/useful if there were a encryption tool such as ccrypt available within initrd by default, as in the absence of anything else (such as dropbear encryption of keys), its good practice to not leave your private keys 'open'.

PS the pre-built ccrypt binary worked for me, just dropped it into initrd's /usr/bin folder and done.

[rufwoof]

Fatdog initrd minus fd64.sfs, which instead is stored on a remote ssh server.

Dropped sshfs (along with ssh, scp) into initrd.

Booted with net kernel boot parameter to early net connect (I'm using wireless), exited to shell before fd64.sfs is processed in init and sshfs mounted the remote ssh server to local /hb folder

sym linked /hb/fd64.sfs to /fd64.sfs i.e. remote (via sshfs) ssh servers copy of fd64.sfs sym linked to the root folder of the initrd ... so somewhat like it having already existed in the initrd.

Resumed initrd boot (to load fd64.sfs/fatdog gui desktop) ... and it loads/runs fine. Quite slow initially to get going, as its pulling stuff over ssh (in my case from the US to the UK as my ssh server is located in the US whilst I'm in the UK). But not uncomfortably slow - not much different to booting a full blow fatdog DVD). Once up and running, i.e. more things cached, then no general operational speed differences.

It would seem that switch-root doesn't free processes that are running, so the sshfs mount made within initrd persists after the switch-root. Its just inaccessible from the command line.

Booted from usb that way and its around a 80MB initrd.gz filesize (largely due to kernel modules sfs within initrd). And once booted the boot usb can be unplugged so its all running in ram, with a remote sshfs mount (fd64.sfs).

I have quite a large savefile (multi-session saves that are stored on usb) as I have google chrome included in that (around 140MB of compressed save file space), without that loaded uses around 250MB of ram, with my saves loaded into ram however that rises to around 750MB



Having ssh/sshfs as in openssh rather than the default dropbear ssh within initrd is nice as its more functional. Along with mc and tmux also dropped into initrd and initrd expands to 92MB - but reduces to 80MB if you gzip it. Around a 8MB expansion (initrd without fd64.sfs is around 72MB).

I guess one negative is that once booted to desktop, you can't easily resume the sshfs remote mounted fd64.sfs if the ssh link drops. So this is more a observation than a proposed actual boot choice. It would be simpler/better to just scp the remote fd64.sfs into ram and use that to boot from.

[jake29]

I've searched this forum, but cannot find an answer. Is it possible to get 'vainfo' functional in Fatdog64 or is there an alternative I can use?

EDIT: I note that 'vainfo' is included in libva-utils. I need this utility to troubleshoot an app that is causing me trouble. Developer has requested 'vainfo.'

EDIT2: I've now done a temporary install of full Ubuntu 19.04 and my problem app is working without issue. I have established libva plays a key role in the functionality of the app, can anyone comment on libva-utils and why it is so far considered optional in Fatdog64?

EDIT3: I finally noticed that libva and libva-intel-driver are both outdated, and I have now compiled newer versions (along with libva-utils). Hopefully this will resolve my issue.

[rufwoof]

Fatdog 8.2 kernel-modules.sfs is 65MB. Compiling the kernel with no fd64.sfs inside initrd and kernel-modules.sfs extracted within (unsquashfs'd into) initrd (and kernel-modules.sfs removed from the initrd) ... and that initrd inserted into the kernel (vmlinuz) resulted in a 59MB vmlinuz filesize. i.e. boots with no need to include a initrd entry in menu.lst (just specify the vmlinuz as the initrd is contained within that).

Booting with just a vmlinuz (and external fd64.sfs) is nice in some respects - more secure as initrd is 'hidden' within vmlinuz, the smaller size (6MB saving) is also welcome. But does make accessing/changing things that more difficult (kernel recompilation needed after changing initrd). Built once however (slow first compilation) and subsequent kernel recompiles do run through relatively quickly (few minutes).

The method I used to insert initrd into vmlinuz was to copy initrd to usr/initramfs_data.cpio (/mnt/sdb1/fatdog-kernel/src/linux-4.19.44/usr/initramfs_data.cpio in my case) prior to running make (in /mnt/sdb1/fatdog-kernel/src).

Currently to swap a kernel typically you replace the kernel-modules.sfs and vmlinuz to the new/alternative version. Given that initrd content excluding kernel-modules and fd64.sfs is relatively small having both initrd and kernel-modules combined into a single vmlinuz is a nice alternatively, more so in that the initrd files/scripts could be better matched with the kernel-modules (kernel version) that was being selected.

[rufwoof]

/etc/rc.d/rc-cleanup ... is

$BB swapoff -a

strictly necessary? If swap has been heavily used then swapoff -a can take ages. I would have thought that instead a simple 'sync' might suffice?

[jake29]

Hi all. I do not like to make a request like this, however I am having difficulty doing a pkgbuild of LLVM. I need v7.0.0 or newer to compile some other stuff. The laptop (and only machine I have) is locking up for hours during compiling.

Currently only v5.0.2 is available in Gslapt, which is quite dated - latest version is 8.0.1.

[Flash]

I downloaded the Fatdog64-802 .iso and burned it to a DVD using Burniso2cd. The DVD booted to a desktop without my intervention, but neither the mouse nor the keyboard worked. (Both are USB.)

When I chose the multisession boot option, it wouldn't boot at all.

[jamesbond]

Sorry guys long time no post, I have been very busy lately.

Just a few comments.

rufwoof - love to see your interesting experiments. Yes, the possibilities are endless and that's what we had in mind when we started Fatdog - something that works out of the box but can be extended in many various ways.

A note about Fatdog's initrd. Fatdog is actually two operating system in one. Fatdog's initrd is actually its own independent CLI-only busybox-based mini operating system called "Bulldog Linux", with the proper Fatdog tacked on top of it. It is not an accident that the busybox in Fatdog's initrd is a complete busybox with almost all applets included; it is by design. In the proper Fatdog environment its only purpose is to setup Fatdog's layered filesystem and as a recovery console; but you can choose not to do that and run Bulldog by itself as a CLI operating system (run with basesfs=none and you'll see what I mean).

About loading fd64.sfs from NBD: it works but the busybox in 800 requires a patch to make this properly (thanks to bitrot). I've an updated ISO which does this - it's the 800tip, contact one of the Fatdog team to get the location.

<Might I propose adding Terminus bold 32 console> ==> link?

<ccrypt> ==> It's 815KB. If it can be made smaller then I'll bring it in. Otherwise I'm sure there are similar others which is in the order of 50K or less (perhaps bcrypt?). Otherwise cryptsetup is already included in initrd, you can have a "secure vault" containing your keys, then open/mount it, start ssh, and close the vault again.

As for LLVM update: LLVM is tightly integrated with the Mesa radeon driver. Updating it requires extensive re-testing to make sure that 3D with radeon/amdgpu still works properly. If you don't use 3D using radeon/amdgpu then it should be okay.

Flash I'll have to defer your problems to others for the moment.

I will disappear again, see you next year maybe
SFR and step, thank you for holding the fort.

[jake29]

Thanks for the reply James. The reason for my request was indeed related to compiling a newer version of Mesa.

I'm trying to resolve a crashing problem with a specific app and I'm comparing installed packages between Fatdog64-802 and Ubuntu 19.04 (where the app is stable). The app is the streaming client for a cloud platform, and it looks to be a video-related problem.

I have managed to update to the same version of libva and libva-intel-driver, but my problem persists.

Some remaining obvious differences are a newer version of Mesa, and the presence of 'intel-media-va-driver' (https://github.com/intel/media-driver).

A long-term question I've had regarding compiling - is there a way I can pause or break the progress made and resume later or after a reboot?

Thanks.

[rufwoof]

<Might I propose adding Terminus bold 32 console> ==> link?

https://sourceforge.net/projects/termin ... z/download Out of that complete set, dropping the ter-i28b.psf.gz into /lib/boot/consolefonts and it sits alongside big and bbig font that already exist. A 28 font size is nice for relatively common resolutions i.e. 768 (as in 1366x768) and a 28 bit height yields 768 / 28 = 27 lines, which is good for displaying 80x25 type content (BBS's etc), with a couple of extra lines for titles/panel (tmux). In Taiwan, millions still use BBS, often with 150,000 on at any one time. I guess it better facilitates posting things more anonymously.

<ccrypt> ==> It's 815KB. If it can be made smaller then I'll bring it in. Otherwise I'm sure there are similar others which is in the order of 50K or less (perhaps bcrypt?).

ccyrpt http://ccrypt.sourceforge.net/download/ ... .11.tar.gz (from http://ccrypt.sourceforge.net/#downloading)

When downloaded, extracted and

./configure
make CC=musl-gcc CFLAGS=-static

i.e. musl ... yields a 124K filesize.

Reading deeper and not only is ccrypt rather heavy, but also it doesn't salt i.e. gpg by comparison in effect concatenates a entered password with a random sequence to make otherwise simple/short passwords longer/more difficult to dictionary/brute-force attack. So another choice looks to be more appropriate.

A note about Fatdog's initrd. Fatdog is actually two operating system in one. Fatdog's initrd is actually its own independent CLI-only busybox-based mini operating system called "Bulldog Linux", with the proper Fatdog tacked on top of it. It is not an accident that the busybox in Fatdog's initrd is a complete busybox with almost all applets included; it is by design. In the proper Fatdog environment its only purpose is to setup Fatdog's layered filesystem and as a recovery console; but you can choose not to do that and run Bulldog by itself as a CLI operating system (run with basesfs=none and you'll see what I mean).

I do like "Bulldog Linux", with dropbear added on top and if you recompile the kernel with localyesconfig so that modules are built into the kernel (and also drop initrd into the kernel) - and that builds with only the modules your hardware uses - and I'm seeing 14MB type vmlinux (the only needed file to boot) filesize. And that's with wireless connecting also. (Ready to ssh into servers)

[SFR]

Hi all. I do not like to make a request like this, however I am having difficulty doing a pkgbuild of LLVM. I need v7.0.0 or newer to compile some other stuff. The laptop (and only machine I have) is locking up for hours during compiling.

Currently only v5.0.2 is available in Gslapt, which is quite dated - latest version is 8.0.1.

Yeah, building LLVM (or any substantial C++ app, for that matter) requires a lot of RAM, so if you have e.g. only ~4G, you need some swap as well.
Btw, in addition to normal file/partition-based swap, I'd also recommend using ZRAM swap (with a higher priority), which is faster and doesn't lock the system that much.

Code: Select all

# # Load the required kernel module:
# modprobe zram
#
# # Reserve the first free zram device:
# zramctl -f
/dev/zram0
# 
# # Create 2G zram device with zstandard compression (almost as fast as lz4 and almost as good as gzip):
# zramctl -s 2G -a zstd /dev/zram0
# 
# # Create swap in zram and activate it:
# mkswap /dev/zram0
# swapon /dev/zram0 -p 10
# 
# zramctl 
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            2G   4K   58B    4K       4 [SWAP]
#
# swapon
NAME              TYPE       SIZE USED PRIO
/dev/zram0        partition 2048M   0B   10
# 

To disable it:

Code: Select all

# swapoff /dev/zram0
# zramctl -r /dev/zram0

Note that the 2G figure refers to data before compression, so with zstd ratio being even ~5:1 (from my own experience), the actual amount of used RAM will be ~400M.

Also, you can modify the recipe, by adding '-j1' to make, which prolongs the compilation, but requires less RAM.

Anwyay, I just built it, so here you go: https://drive.google.com/open?id=1mfRvi ... PKfIdASMBx
MD5: 765eca3a5d569aa4f4170ec5f3005078 llvm-8.0.1-x86_64-1.txz

I downloaded the Fatdog64-802 .iso and burned it to a DVD using Burniso2cd. The DVD booted to a desktop without my intervention, but neither the mouse nor the keyboard worked. (Both are USB.)

When I chose the multisession boot option, it wouldn't boot at all.

Hard to tell, may be missing drivers and/or firmware.
But, on the other hand, the keyboard works for you in boot menu, correct?
Sometimes the same happens to me with a touchpad on another laptop, but it's really rare - perhaps it was a temporary glitch also in your case..?

<ccrypt> ==> It's 815KB. If it can be made smaller then I'll bring it in. Otherwise I'm sure there are similar others which is in the order of 50K or less (perhaps bcrypt?). Otherwise cryptsetup is already included in initrd, you can have a "secure vault" containing your keys, then open/mount it, start ssh, and close the vault again.

./configure
make CC=musl-gcc CFLAGS=-static

i.e. musl ... yields a 124K filesize.

Reading deeper and not only is ccrypt rather heavy, but also it doesn't salt i.e. gpg by comparison in effect concatenates a entered password with a random sequence to make otherwise simple/short passwords longer/more difficult to dictionary/brute-force attack. So another choice looks to be more appropriate.

Built against musl and UPX'ed it's 52K.
I also built bcrypt statically, but even UPX'ed it's 255K.
JB's idea to use some small LUKS container instead is kinda neat, actually, since cryptsetup is already there.

Greetings!

[rufwoof]

JB's idea to use some small LUKS container instead is kinda neat, actually, since cryptsetup is already there.

My upx'd ccrypt (musl) was around 57MB using --ultra-brute compression. Generally I use that ccrypt to lock down my dropbear private ssh key, so its encrypted and only briefly open for the duration of establishing a ssh connection.

Code: Select all

#!/bin/sh
cd /mnt/.ssh
/mnt/ccrypt -c db_id_rsa.cpt >db_id_rsa 
echo "#!/bin/sh" >/tmp/cleanup 
echo "sleep 20" >>/tmp/cleanup 
echo "rm /mnt/.ssh/db_id_rsa" >>/tmp/cleanup 
echo "rm /tmp/cleanup" >>/tmp/cleanuup 
chmod +x /tmp/cleanup 
/tmp/cleanup & 
chmod 0600 /mnt/.ssh/db_id_rsa 
cd /
ssh -i /mnt/.ssh/db_id_rsa user@ssh.server.host

Using a LUKS container and that requires a image file to serve as the holding container - which whilst you could set that image file to be just large enough to hold the ssh key(s), more generally you'd set that larger, perhaps 10K (possibly more). So the saving over installing/using ccrypt could be relatively small - 40K perhaps (or less), but with ccrypt installed that does open up encrypting other files relatively easily, perhaps your calendar/diary/journal ...etc. I also tried bcrypt and similarly saw larger binary size and upon reflection of my earlier comment about not being salted - for general use its probably ok as-is, enough to avoid open access to your ssh keys, diary ...etc.

Inclined to stick with my earlier suggestion of ccrypt being included, the upx suggestion knocking that down to sub 60K size is pretty good IMO. Absent that, and encryption options in Bulldog are pretty limited as-is (excepting the cryptsetup option).

Another method I use is my own pcrypt which when musl/upx'd is around 19K. That however works on a one-time-pad basis (that if truly random data is used is proven uncrackable), which in effect doubles up on the filesize of the file being encrypted and where you store the two halves physically separated. If I store my main private ssh key in pcrypt form, with one half on another ssh server that I access using a userid/password in order to scp that down and then decrypt the private ssh keyfile, then that does make it much more improbable that anyone finding the usb (with encrypted dropbear ssh private key) would be able to crack that private key. When using Bulldog that way however it makes sense to also have the full OpenSSH that supports sshfs, i.e. sshfs mount a ssh server that has the other half of all pcrypt keys for pcrypt encoded files being stored locally. But IIRC that does bloat Bulldog by around 2.5MB (sfs filesize 7.8MB fully extracted). Personally for me that's a small price.

[jake29]

Many thanks SFR, for the download and the compiling tips.

EDIT: I would appreciate anyone's thoughts on the below information and which dependencies are likely to play a role in the issue and require updating in Fatdog64-802. I personally suspect the issue is not video related, but hardware detection - the crash is triggered by cursor click.

Stable and latest Beta client for Linux frequently dropping / disconnecting video stream with error L:100. This problem is only occurring when free movement cursor is enabled. The client is 100% stable in 'cursor-locked' mode. Issue did not exist using the original (older) Shadow client in Fatdog64.

Additional context
Graphical corruption of cursor will sometimes occur seconds before the Client disconnects. The issue can be consistently reproduced by moving (travelling by clicking) around in Google Maps 'street view' mode.

Here is my 'problem' app: https://aur.archlinux.org/packages/shadow-beta

Dependencies:

Code: Select all

desktop-file-utils (desktop-file-utils-git)
freetype2 (freetype2-git, freetype2-v35, freetype2-infinality-remix, freetype2-old-hinting, freetype2-ttmetrics, freetype2-infinality, freetype2-ultimate5, freetype2-cleartype)
gcc7-libs
gconf (gconf-gtk2)
hicolor-icon-theme (hicolor-icon-theme-git)
json-c
libappindicator (libappindicator-gtk2)
libappindicator-gtk2 (libappindicator-gtk2-ubuntu)
libbsd (libbsd-git)
libcurl-compat
libcurl-gnutls
libdrm (libdrm-grate-git, libdrm-git, libdrm-amdgpu)
libnotify (libnotify-gtk2, libnotify-id-git, libnotify-id)
libsndio-61-compat
libuv (libuv-git)
libva (libva-git, intel-media-stack-bin, libva-headless)
libxss
libxtst
nss (nss-hg)
opus (opus-git)
qt5-base (qt5-base-git, qt5-base-headless)
qt5-svg (qt5-svg-git)
sdl (sdl-openglhq, sdl-nokbgrab, sdl-openglhq-nokbgrab, sdl-hg)
sdl2 (sdl2-ime-support, sdl2-rbp-bin, sdl2-nox, sdl2-hg, sdl2-hidpi-hg)
ttf-dejavu (ttf-dejavu-emojiless, ttf-dejavu-ib)

Installed in Ubuntu 19.04: (Where app is 100% stable)

Code: Select all

desktop-file-utils v0.23-4
libxft2 v2.3.2-2
gcc-8 v8.3.0-6
hicolor-icon-theme v0.17-2
json-c v012.1
libappindicator3-1 v12.10.1
libbsd0 v0.9.1-2
libcurl3-gnutls v7.64.0-2
libcurl4 v7.64.0-2
libdrm-common, libdrm-intel1, libdrm-radeon1, libdrm2 - all are v2.4.97-1
libnotify-bin, libnotify4 - both are v0.7.7
intel-media-va-driver v18.4.1
libva-drm2, libva-wayland2, libva-x11-2, libva2 - all are v2.4.0-1
libxss v1:1.2.3-1
libxtst6 v2:1.2.3-1
libnss-mdns v0.14.1-1
libnss3 v2:3.42-1
libopus v1.3-1
libqt5core5a, libqt5dbus5, libqt5designer5, libqt5gui5, libqt5help5, libqt5network5, libqt5printsupport5, libqt5sql5, libqt5svg5, libqt5test5, libqt5widgets5, libqt5xml5, python3-pyqt5 - all are v5.12.2
fonts-freefont-tff v20120503-9

EDIT2: ldd results.
Fatdog64-802: https://pastebin.com/raw/v0F1C00M
Ubuntu 19.04: https://pastebin.com/raw/rRuh4KWP

Missing in Fatdog64-802:

Code: Select all

libdatrie
liblz4
libselinux
libsystemd
libthai
libwayland-cursor
libwayland-egl
libwayland-client
com_err

libmount (installed but unused by app)
libxkbcommon (installed but unused by app)
libgssapi_krb5 (installed but unused by app)
libblkid (installed but unused by app)
libbsd (installed but unused by app)
liblzma (installed but unused by app)
libgcrypt (installed but unused by app)
libkrb5 (installed but unused by app)
libk5crypto (installed but unused by app)
krb5support (installed but unused by app)
libgpg-error (installed but unused by app)
libkeyutils (installed but unused by app)

Not used in Ubuntu: (Utilized in Fatdog64-802)

Code: Select all

libgthread
libssp

EDIT3: Fortunately my persistence has paid off. I learnt from support on discord, that 'the cursor is handled by a custom crafted SDL lib embedded with shadow client.' It turns out the env variable 'LD_PRELOAD' is correctly managed in Ubuntu by the client to use their own SDL lib, however the implementation does not work correctly in Fatdog64. By adding the env variable manually, I was able to force client to use the custom SDL lib and the difference is obvious. Client is now 100% stable in all modes where cursor is locked / client is in full-screen.