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

[don570]

Tip: to place a pFind menu item in right click menu of a partition icon in Rox filer,
just type this in terminal...

Code: Select all

ln -s /usr/local/apps/pFind   /root/.config/rox.sourceforge.net/SendTo/.inode_mount-point/pFind

___________________________________________________________

[jamesbond]

@jake29: I will try to build gnome-keyring for you. It may or may not help. I'll let you know when ready. Hopefully it doesn't pull too many dependencies (if it does, I'd probably give up).

@rufwoof: Nice setup you have there

@don570: regarding the mimeinfo.cache stuff: Thanks for that info. Eventually Fatdog needs to catch up that. When we started all these fancy schmancy stuff didn't exist. We only had /etc/mime.types, /etc/mailcap, and /usr/share/applications/defaults.list. But those freedesktop guys got infected by NIH virus and indecision virus - they keep inventing new locations every few years or so, for where to keep these file-association information. I personally think the way rox handles file association is the best; but of course opinions differ. I personally think that putting all your eggs in one basket like mimeinfo.cache smells much too rotten like the windows registry. But that's just me, and since eevryone has moved into that direction, sooner or later we'll all have to wear the mask too ...

@don570: grub4dosconfig was designed for puppy, not for Fatdog. We include it in Fatdog because people find it useful. I'm not sure if shinobar still maintains it (or if he's still even here in the forum). We include it in Fatdog also because there is no better tool. But as you can see, it's not perfect. That's perhaps another item we need to add to the FAQ ...

@don570: Re: adding the button to SFS loader: I wish I could do that, but since SFS loader is written using the extremely primitive Xdialog, two buttons is the maximum we can get. That's why i have to go with the kludge of "tick here to change directory" stuff. Otherwise I would have added a button to change directory.

@rufwoof: re: the cryptsetup unmount: the "unmount" should only unmount. If we want to totally close the the luks container, then another action should added. The equivalent analogy is a flash drive. When you click the "x" rox icon, the drive is unmounted, but the drive icon remains. To remove it, we have to right-click on the drive and choose "safely remove". That's where "close luks partition" functions should go; instead of combining it together with the unmount function.

But before we go that way, we need to modify "filemnt" to be able to open the luks container in the first place ...

[don570]

@don570: grub4dosconfig was designed for puppy, not for Fatdog.

I forgot to mention that I had set up the bootloader for my windows10 computer by booting with an old CD of Lucid puppy and running grub4dos from it , not fatdog64.
_______________________________________________

[don570]

I was able to compile latest mtpaint 3.49.19
with ./configure
I had upgraded my install with png12 because of gmic plugins
which have dependencies
http://murga-linux.com/puppy/viewtopic. ... 55#1041255
___________________________________________

[don570]

SFS loader is written using the extremely primitive Xdialog, two buttons is the maximum we can get

I didn't realized that SFS loader was written with Xdialog!!!

Perhaps the button could be re-labelled...

or just have one button i.e. to quit program you have to use upper right close box.

[jake29]

@jamesbond - Please don't make too much effort if it's going to mean major bloat for Fatdog64.

I now have a more pressing issue. I bought a Bluetooth mouse (Microsoft mobile mouse 3600) and I can pair, trust and connect - but mouse refuses to work.

I tried in Ubuntu 19.04 for comparison, and the exact same steps result in a working mouse. Perhaps due to this mouse being a BT Low Energy (LE) device is a factor. I am unable to pkgbuild the latest version of Bluez due to changes in source.

FD64-802:

Code: Select all

[bluetooth]# scan on
Discovery started
[CHG] Controller 60:57:18:E0:05:69 Discovering: yes
[NEW] Device C8:1B:F6:35:48:07 BluetoothMouse3600
[CHG] Device C8:1B:F6:35:48:07 RSSI: -47
[bluetooth]# pair C8:1B:F6:35:48:07
Attempting to pair with C8:1B:F6:35:48:07
[CHG] Device C8:1B:F6:35:48:07 Connected: yes
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 ServicesResolved: yes
[CHG] Device C8:1B:F6:35:48:07 Paired: yes
[NEW] Primary Service
	/org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0008
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[NEW] Primary Service
	/org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009
	0000180a-0000-1000-8000-00805f9b34fb
	Device Information
[NEW] Characteristic
	/org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009/char000a
	00002a29-0000-1000-8000-00805f9b34fb
	Manufacturer Name String
[NEW] Characteristic
	/org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009/char000c
	00002a50-0000-1000-8000-00805f9b34fb
	PnP ID
Pairing successful
[CHG] Device C8:1B:F6:35:48:07 Modalias: usb:v045Ep0916d0110
[BluetoothMouse3600]# trust C8:1B:F6:35:48:07
[CHG] Device C8:1B:F6:35:48:07 Trusted: yes
Changing C8:1B:F6:35:48:07 trust succeeded
[BluetoothMouse3600]# connect C8:1B:F6:35:48:07
Attempting to connect to C8:1B:F6:35:48:07
Connection successful

Ubuntu 19.04 (w/ bluez v5.50):

Code: Select all

user@Venue-11-Pro-7140:~$ bluetoothctl
Agent registered
[NEW] Device C8:1C:F5:36:48:07 BluetoothMouse3600
[bluetooth]# scan on
Discovery started
[CHG] Device C8:1C:F5:36:48:07 RSSI: -49
[bluetooth]# pair C8:1C:F5:36:48:07
Attempting to pair with C8:1C:F5:36:48:07
[CHG] Device C8:1C:F5:36:48:07 Connected: yes
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 ServicesResolved: yes
[CHG] Device C8:1C:F5:36:48:07 Paired: yes
[NEW] Primary Service
	/org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0008
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[NEW] Primary Service
	/org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009
	0000180a-0000-1000-8000-00805f9b34fb
	Device Information
[NEW] Characteristic
	/org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009/char000a
	00002a29-0000-1000-8000-00805f9b34fb
	Manufacturer Name String
[NEW] Characteristic
	/org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009/char000c
	00002a50-0000-1000-8000-00805f9b34fb
	PnP ID
Pairing successful
[CHG] Device C8:1C:F5:36:48:07 Modalias: usb:v045Ep0916d0110
[BluetoothMouse3600]# trust C8:1C:F5:36:48:07
[CHG] Device C8:1C:F5:36:48:07 Trusted: yes
Changing C8:1C:F5:36:48:07 trust succeeded
[BluetoothMouse3600]# connect C8:1C:F5:36:48:07
Attempting to connect to C8:1C:F5:36:48:07
Connection successful

EDIT: Kernel modules comparison.

FD64-802:

Code: Select all

# lsmod | grep '^blue' | column -t
bluetooth  307200  31  btrtl,btintel,btbcm,bnep,btusb,rfcomm
# lsmod | grep '^bt' | column -t
btusb    40960  0  
btrtl    16384  1  btusb
btbcm    16384  1  btusb
btintel  16384  1  btusb

Ubuntu 19.04:

Code: Select all

user@Venue-11-Pro-7140:~$ lsmod | grep '^blue' | column -t 
bluetooth  557056  31  btrtl,btintel,btbcm,bnep,btusb,rfcomm
user@Venue-11-Pro-7140:~$ lsmod | grep '^bt' | column -t 
btusb    49152  0
btrtl    20480  1  btusb
btbcm    16384  1  btusb
btintel  24576  1  btusb

Below image is from Windows 8 (where mouse also functions correctly):

[rufwoof]

Tried upx'ing libs in my cut down Bulldog, and with the initramfs built into the kernel and with the kernel .config set to use xz compression that actually expanded the vmlinuz size. So I opted to un upx everything inside the initramfs (including what the standard Bulldog upx's by default) ... went around the various folders running upx -d * and after recompiling the kernel that reduced the vmlinuz down to 12.4MB. With some further kernel config refinement, 11.6MB. The notes I recorded in the /README within Bulldog ...

This is Bulldog initrd, as of Mar 2019.

Contains:
- busybox 1.27.0.git.2017.03 with guess-fstype patch (aboriginal 1.2.4)
- busybox init 1.27.0.git.2017.03 (musl 1.1.21), compiled separately for memory reasons
- dropbear 2018.76 (musl 1.1.21) # up to date as of Mar 2019
- losetup-klibc (losetup from klibc 2.0.6) # up to date as of Mar 2019
- ntfs-3g/ntfsfix 2017.3.23 (aboriginal 1.2.4 --disable-mtab) # up to date as of Mar 2019
*- wpa_supplicant (uclibc, br 2012.02) # needs update
*- iwconfig (uclibc, br 2012.02) # needs update
- sdparm 1.07 (can't remember I used musl or uclibc or klibc)
- LVM 2.2.02.177 (dmsetup/lvm) without udev - (musl 1.1.21 + util-linux 2.31.1) # 2018 version
- cryptsetup 2.1.0 (musl 1.1.21 + LVM 2.2.0.177 + util-linux 2.31.1) # jake's build # up to date as of Mar 2019
- e2fsck 1.43.9 (musl-libc) # 2018 version
- dosfsck 4.1 (musl 1.1.21) # up to date as of Mar 2019
- mount.cifs - from cifs-utils 16.8 (musl 1.121) # up to date as of Mar 2019
- mdadm 4.1 (musl 1.1.21) # up to date as of Mar 2019
- katz-git abb56e4c07 (musl, musl-gcc) # up to date as of Mar 2019
- evtest 91f924bc9a (musl 1.1.21) - 2019 # up to date as of Mar 2019
- strace 4.26 (musl 1.1.21) # up to date as of Mar 2019
- posixovl-deztructor-2015 (musl 1.1.15 with fuse 2.9.4) # up to date as of Mar 2019

- full fledged init, supports coldplug and hotplug
- barebones rc.sysinit & rc.cleanup

these binaries are upx-ed (3.0.8 ):
- ntfs-3g, ntfsfix, wpa_supplicant and friends, iw_config, dmsetup, lvm, strace,
sdparm, dropbear, cryptsetup, e2fsck, dosfsck, mount.cifs, mdadm, katz, evtest
posixovl
==> binaries that are only rarely used or only executed once.

Will require:
- squashfs.ko in /lib/modules/$KVER (none if it's already built-in)
- kernel_modules.sfs (optional)

Compiled standard 4.14 kernel with localyesconfig i.e. machine specific modules.
Kernel's standard firmware support seems adequate enough for text cli and wifi
net connect on this laptop.

Added KEXEC kernel (.config) elements
Added kexec binary (and man etc.) musl build with upx'd kexec bin
Added (upx --ultra-brute) screen - that requires pseudo terminal
Added simple-mtpfs with ultra-brute upx'd /usr/bin/simple-mtpfs
Added ccrypt (musl and upx'd) for ssh key protection purposes.
Added openssh
Added mc

Removed strace, lvm, ntfs-3g ntsfix, microcode for genuine intel
(as my laptop is radeon).
Removed mdadm (raid - which I dont use).
Removed /sbin/e2fsck and dosfsck
Removed vmcore-dmesg and kdump from the kexec build
Removed /usr/lib/kexec-tools folder and kexec_test file within that
Removed some things from kernel .config i.e. btrfs
Removed /usr/share/mc ...hints, skins, help files for non UK
Removed /usr/share/terminfo files for xterm and rxvt
Removed dropbear

After upx'ing all libs, found that the vmlinuz was LARGER
(with initrd within that) despite upx ultra-brute seemingly
compressing files quite tightly. Opted to remove all upx'ing
across all files, so went around all folders running upx -d *
Larger initramfs_data.cpio, but when built into the kernel which
is then xz compressed that compresses more tightly.

[jake29]

To follow-up from my previous post regarding Bluetooth mouse issue. The following may be a potential cause. The 'hid' and 'hid-generic' Kernel modules are missing in the current kernel. I've also read that kernel option UHID (Device Drivers -> HID Support -> User-space I/O driver support for HID subsystem) needs to be enabled.

FD64-802:

Code: Select all

# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y

Ubuntu 19.04:

Code: Select all

# HID support
#
CONFIG_HID=m
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=m

EDIT: I got the mouse working by loading the uhid module (modprobe uhid) and then doing pair/trust/connect. I also had to set 'UserspaceHID=true' in /etc/bluetooth/input.conf and restart the bluetooth service to stop an endless cycle of disconnecting/reconnecting.

[belham2]

Hi Fatdog gang,

Just wondering if anyone has ever come across this issue before.

I can't figure out if it as a hardware issue on my end (seems unlikely since Fatdog has done this (described below) on 4 different machines, AMD & Intel), but the issue involves wireless and a router's Hidden SSID.

Here's what happened: I decided to use a Hidden SSID on my router for our wifi network in our home.

All my other pups and DDogs and larger Linux OSes I run have no problem seeing this "Hidden SSID" as long as I enter the correct SSID in their profile setups.

But in Fatdog, after I go in and remove all old wifi & lan profiles from previous setups, then reboot to bring everything up fresh, Fatdog immediately sees my wifi network, showing (when using Scan in the network-control applet) the XOXOXOXOXOXOOXO for a Hidden SSID network, I then click on it, and Fatdog brings up the popup where I build a profile of this. I think great, no problem here.

I then, for the profile, enter the correct SSID, the WPA2-PSK, CCMP, password, etc---all the stuff I have normally been doing for years now with Fatdog and non-Hidden SSID networks. I hit save, go to "Activate" the network, and---HERE IT IS----Fatdog refuses to connect.

I scratch my head.

I then use another machine in the house, go back into the DD-WRT router, uncheck the "Hidden" feature of the SSID, go back to Fatdog, delete all profiles again. I do the same procedures as above, and sure enough, Fatdog 802 sees the exact same 'unhidden ssid' network and, suddenly, with no problems, connects super-fast.

I scratch my head even more.

So then I try this on other computers and one other laptop with Fatdog USB sticks I have, and Fatdog proceeds to do the same thing on all of them with a 'Hidden SSID' wifi network and refusing to connect to it despite easily seeing the 'hidden ssid' wifi network.

I now realize it is probably not a hardware problem on my end. Un-hide the SSID, and Fatdog connects. Hide the exact same SSID, make the necessary modifications in the wifi profile, and Fatdog refuses to connect. On all the computers/laptops Fatdog did this.

Thinking that maybe there's a problem in Fatdog 802 itself, I go back and test 801, 800 and even the 700s.

Same issue, Fatdog, despite connecting to the exact wifi network if the SSID is NOT hidden, will not---at least for me---connect to any wifi network if the SSID is "Hidden". This was true for any wifi router. I say any because of this reason: it seems to have nothing to do with the DD-WRT router I run otherwise all machines in the house would exhibit the same behavior, and to be sure, I even plugged my ISP's provided wifi/router combo back in, Fatdog connects easily with it provided the SSID is NOT hidden. But the moment I choose to enable the "Hidden SSID" in the router, again, Fatdog (none of them from 700s up to 802) will connect via wifi even ot this router. Yet all my other computer systems and laptops do.


Has anyone else experienced this? Or do I just have a special Gremlin/Demon running around my house and screwing with me when I use Fatdog?

[step]

I suspect wpa-supplicant's default configuration is causing your issue.
Try editing /etc/wpa_supplicant.conf and adding this line

scan_ssid=1

after line

ssid="the-hidden-ssid" (replace the-hidden-ssid with yours)

and restart the connection (right click the newtork tool tray icon).

Can it connect to the-hidden-ssid now?

[jamesbond]

@don570:
- thanks, I've updated mtpain to 3.49.19 on the repo too.
- re: sfs loader, let me think about it. Changing text is easy, changing behaviours needs some thinking (and alot of tests)

@jake29:
- I think you solved something that was even a mystery for me - I could never get an M$ mouse to work. Eventually I learnt my lesson NOT to buy M$ products at all. So thanks for figuring this one out. This may be another item for the FAQ.
If you want to load uhid at every boot, you can edit /etc/modules and put a line containing "uhid" (without the quotes) there.

- I built gnome-keyring and push it to the repo. I have not tested it myself though, so I cannot say for sure if it will work. You're welcome to test it if you wish.

@belham2: I never use hidden-ssid because I don't see the point (it offers absolutely no security); so I haven't tested it myself. Does step's suggestion work?

@rufwoof: I presume in order to bring openssh and mc to the initramfs, you need to bring libc and ncurses as well (at the very least), right?

[belham2]

@step - nothing has worked (even your suggestion). Thank you for attempting to help.

@jamesbond - understand about a "hidden-ssid". Was not doing it for security purposes. Was doing it for self-interest and education (read: kids) purpose/exercise.


Anyway, thank you both for responding.

This weekend's exercise will soon be over (I put Bionicpup64 on their laptops & all is now good). We'll shortly be off the 'hidden-ssid" teaching moment and on to something else.

[rufwoof]

@rufwoof: I presume in order to bring openssh and mc to the initramfs, you need to bring libc and ncurses as well (at the very least), right?

Yes James. I just copied over the ssh. sftp, scp ... etc files as is from the main fatdog, along with the libs (as indicated by ldd). With localyesconfig (i.e. machine specific modules built into the kernel) along with initramfs_data.cpio (initrd) also built into the kernel, and with all of those libs/bins ... it weighs in at a 11.7MB bzImage (vmlinuz) filesize for me. Pretty good for

automatic wifi net connect at bootup
screen (terminal multiplexing)
mc (file manager and text editor)
ccrypt (encryption)
kexec (directly booting main systems)
openssh (sshfs client or server, ssh client or server, sftp, scp ..etc.).

Quite a extensive set of libs in total, surprising that it all compacts down to such a small 11.7MB vmlinuz filesize.



Found that it was best to NOT use upx on the various bins, have the initramfs_data.cpio built into the kernel and set kernel compression to xz. I've also tweaked (removed) quite a bit out of the kernel build, things like btrfs support etc. I also removed out some/many of the binaries that fatdog adds in, such as dropbear ..etc. For kexec and ccrypt I compiled those using static/stripped musl.

The heavily reduced init (cut down Fatdog init) I'm using (again very specific i.e. for UK keyboard etc) ...

Code: Select all

#!/bin/ash

### bail out unless we're PID 1
[ $$ -eq 1 ] || exit 1

### configuration parameters
DEFAULT_DEVICE_DELAY=0	# seconds - default delay time for devices (so that they are recognised by kernel)
WIFI_ENABLE_TIMEOUT=${WIFI_ENABLE_TIMEOUT:-100}	# unit of 1/10 seconds, max time to wait for wifi connection
KERNEL_POLL_MSECS=${KERNEL_POLL_MSECS:-5000}	# default kernel polling value if unset
BOOT_KEYMAPS=/lib/boot/keymaps

### utilities - decz
# decz - decrements counter, and return true when it is zero
# $1 - name of variable to be decremented
decz() {
	local curval
	eval "curval=\$$1"
	curval=$((curval-1))
	[ $curval -le 0 ] && return 0
	eval "$1=$curval"
	return 1
}

### cmdline processing - waitdev
# wait for devices: sleep a specified number of seconds
process_waitdev() {
	waitdev=${waitdev:-$DEFAULT_DEVICE_DELAY}
	if [ "$waitdev" ]; then
		OIFS="$IFS"; IFS=: ; set -- $waitdev; IFS="$OIFS"
		if [ "$1" ] && [ "$1" -gt 0 ]; then
			echo "Waiting $1 seconds for devices to be ready..."
			sleep "$1"
		fi		
	fi
}

### cmdline processing - net
process_net() {
	[ "$net" = "ask" ] && read -p "net=" net 2>&1
	[ -z "$net" ] && return;
	OIFS="$IFS"; IFS=":"; set -- $net; IFS="$OIFS"
	
	echo -n "Configure network "
	# network type
	case $1 in 
		wired)
			# wired:dev:dhcp
			# wired:dev:ip:ip-address:netmask:gateway:dns
			echo -n "on $2 using "
			ifconfig $2 up			
			;;
		wpa|wpa2)
			# wpa2:ssid:pass:dev:dhcp
			# wpa2:ssid:pass:dev:ip:ip-address:netmask:gateway:dns (gateway and dns is optional)
			echo -n "on $2 ($1) using "
			ifconfig $4 up
			wpa_supplicant -B -C/var/run/wpa_supplicant -Dwext -i$4
			wpa_cli ap_scan 1 > /dev/null
			wpa_cli add_net 0 > /dev/null
			wpa_cli set_net 0 ssid "$2" > /dev/null
			wpa_cli set_net 0 psk "$3" > /dev/null
			wpa_cli select_net 0 > /dev/null
			while [ "$(wpa_cli status | sed -ne '/wpa_state/ {s/wpa_state=//;p}')" != "COMPLETED" ];
			do 
				sleep 0.1; decz WIFI_ENABLE_TIMEOUT && return
			done;
			iwconfig $4 power off # disable power management
			shift 2
			;;
		adhoc)
			# adhoc:ssid:dev:ip
			# adhoc:ssid:channel:dev:ip:ip-address:netmask:gateway:dns
			ifconfig $4 down
			iwconfig $4 mode ad-hoc
			ifconfig $4 up
			iwconfig $4 essid "$2"
			iwconfig $4 channel $3
			iwconfig $4 power off # disable power management
			shift 2
			;;
		*)  echo "- wrong types, ignored."
			;;
	esac
	
	# connection type
	case $3 in
		""|dhcp)
			echo "dhcp"
			udhcpc -i $2 > /dev/null
			;;
		ip)
			echo "static ip $4/$5 gw $6 dns $7"
			ifconfig $2 $4 netmask $5
			[ "$6" ] && route add default gw $6
			[ "$7" ] && echo nameserver $7 > /etc/resolv.conf
			;;
		*)
			echo "unknown method $3, ignored."
			;;
	esac
	ifconfig lo up	# in any case bring loopback up also	
}

### enable kernel polling
enable_kernel_polling() {
	if ! grep -q block.events_dfl_poll_msecs /proc/cmdline; then # if not explicitly set
		echo $KERNEL_POLL_MSECS > /sys/module/block/parameters/events_dfl_poll_msecs
	fi
}

### cmdline processing - load keymaps and console fonts
process_pkeys() {
	[ -z "$pkeys" ] && [ -e /etc/keymap ] && read pkeys < /etc/keymap
	if [ "$pkeys" ]; then
		# defaults - empty fontmap, iso-8859-1 codepage
		rm -f /etc/fontmap
		echo ISO-8859-1 > /etc/codepage

		keymap=$(ls $BOOT_KEYMAPS/${pkeys}* | sed -ne '1 {s|^.*/||; s|.gz$||; p}')
		if [ "$keymap" ]; then
			echo Console keymap set to $keymap
			echo "$keymap" > /etc/keymap
			zcat "$BOOT_KEYMAPS/${keymap}.gz" | loadkmap
		fi
		echo 850 > /etc/codepage
	fi
}

######################   main   ##########################

# mount core filesystems
/bin/mount -t proc proc /proc # mount /proc first so /proc/self/exe works from now
mount -t sysfs sysfs /sys
if ! mount -t devtmpfs devtmpfs /dev 2> /null; then		# /dev/null may not exist yet
	# if no devtmpfs, use tmpfs and use mdev instead
	mount -t tmpfs tmpfs /dev -o mode=755 # mode 755 is what devtmpfs uses
	mdev -s
fi
[ -f /null ] && rm /null	# Clear up the null file created above
[ ! -e /dev/shm ] && mkdir -p /dev/shm
[ ! -e /dev/pts ] && mkdir -p /dev/pts
[ "$TZ" ] && hwclock -t # set kernel timezone

# debugging and error logging
# comment out next two lines for greater info during bootup
! grep -q showerr /proc/cmdline && exec 2> /dev/initrd.err
grep -q debuginitrd /proc/cmdline && set -x

# enable polling 
enable_kernel_polling

# process pkeys (hard build kernel (uk laptop specific) so I created /etc/keymap
# with content of "uk" - so we don't have to specify pkeys=uk kernel boot parameter
process_pkeys

# waitdev and wait for usb disk
process_waitdev

# configure network - after load modules, before basesfs
process_net

export HOME=/root
mount -t devpts non /dev/pts -o ptmxmode=0666,newinstance # pseudo terminal for screen
while :; do
	setsid cttyhack /bin/sh
done 

I've tested running both sshfs and ssh server with that and both work OK. sshfs and ssh client also work fine, as does scp copying. My ssh keys are hard stored within the initrd. I have also previously used overlayfs mounting and that worked fine, but I've since dropped overlayfs support out of the kernel config. As a mostly kernel and busybox + some others (mc, openssh ..etc.) it works (very) well IMO. But of course with the limitation of running with busybox level commands, not the full/usual command(s) functionality.

I boot that using grub4dos installed to a usb stick and a menu.lst entry of

Code: Select all

title standard kernel/localyesconfig, cut down fatdog initrd
root (hd0,0)
kernel /bzImage net=wpa2:VMabcd1234-2G:abcd1234:wlan0:dhcp

Once booted, to boot my main fatdog desktop I use a script ...

Code: Select all

#!/bin/ash

CMD="pkeys=uk waitdev=5 "
CMD="$CMD basesfs=ram:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd:/fd64.sfs "
CMD="$CMD savefile=direct:multi:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd::"
clear
echo Loading Fatdog kernel
kexec -l fatdog-vmlinuz \
      --initrd=fatdog-initrd.xz \
      --command-line="$CMD" >/dev/null 2>&1

clear
echo "Booting Fatdog (multi-session save)"
kexec -e

As far as Fatdog as-is goes, I think a useful extension would be to include kexec as part of the standard build. SFR kindly (thanks SFR) helped me with building that ...
http://murga-linux.com/puppy/viewtopic. ... 75#1040675
That along with other pipelined changes will enable the standard Fatdog's Bulldog to serve as a form of more generic/portable kexec based bootloader (albeit with a much larger initrd size due to having much more in the way of modules/supported hardware).

I built kexec using source from
https://mirrors.edge.kernel.org/pub/lin ... nel/kexec/
./boostrap
./configure
export CC="musl-gcc -I/usr/musl/kernel/include -Dloff_t=off_t"
./configure && make -j

... along with kernel .config changes to activate otherwise deactivated
# CONFIG_KEXEC is not set
# CONFIG_KEXEC_FILE is not set

Yet another extension might be to incorporate a TUI menu Bulldog system. That worked OK when I tried it within the above cut down Bulldog http://murga-linux.com/puppy/viewtopic. ... 40#1041340

EDIT: Noticed that I had two copies of libcrypto.so.1.1 .. removing one of them reduced vmlinuz down to 11.6MB

[jake29]

@jake29:
- I think you solved something that was even a mystery for me - I could never get an M$ mouse to work. Eventually I learnt my lesson NOT to buy M$ products at all. So thanks for figuring this one out. This may be another item for the FAQ.
If you want to load uhid at every boot, you can edit /etc/modules and put a line containing "uhid" (without the quotes) there.

- I built gnome-keyring and push it to the repo. I have not tested it myself though, so I cannot say for sure if it will work. You're welcome to test it if you wish.

Thanks, I was actually going to suggest an FAQ entry for anyone else foolish enough to buy such a device. Ironically, this bluetooth mouse is more stable in Fatdog64 than it was in my testing with Windows. I already have uhid loading at boot, however one remaining issue exists. Putting Fatdog64 into standby and resuming all works fine, but a reboot results in a duplicate entry for the bluetooth mouse - listed under bluetoothctl devices. This causes a random periodic cycle of disconnecting and reconnecting, and is resolved buy removing the older entry - bluetootctl remove <mac> and restarting the bluetooth service.

It is not a big issue as I rarely need to reboot. I will research into it - unsure if it is a bluez bug and maybe already fixed in newer builds. Worst case scenario, it could possibly be resolved with a script running at boot. One last thing, there does not appear to be a Bluetooth settings GUI in Fatdog-802 - could that be implemented at some point in the future?

Thanks for making gnome-keyring, I will test it out and report back.

[rcrsn51]

@jake: Are you claiming that your problem is specific to MS bluetooth mice and other brands work OK?

[jake29]

@jake: Are you claiming that your problem is specific to MS bluetooth mice and other brands work OK?

From my research into the problem, it's not something exclusive to Microsoft bluetooth mice - it would have happened with any brand. But certainly the Microsoft bluetooth mobile mouse 3600 is often featured in issue reports, however I think that's just due it being one of the more popular bluetooth mice.

[jamesbond]

@jake29: "Putting Fatdog64 into standby and resuming all works fine, but a reboot results in a duplicate entry for the bluetooth mouse - listed under bluetoothctl devices"

Really! Most people (me included) have issues the other way around ==> suspend=problems, reboot=ok. I guess you're the lucky one

Seriously, if a new version fixes the problem then let me know, I'll upgrade bluez.

"One last thing, there does not appear to be a Bluetooth settings GUI in Fatdog-802 - could that be implemented at some point in the future?"

The issue is that nice applet we have in 700 series only works with bluez 4.x. It no longer works in 5.x. We can of course patch it to support bluez 5.x; or we can totally write a new applet using gtkdialog or something (the original applet was patched half-way through already anyway).

We didn't have time for this in 800, so the plan was to have it in 801. And then in 802. And then 810 ... I guess among the rest of the Fatdog team, I'm the only one who use bluetooth; and even then, today I only use rarely (mainly because on my cheap laptop, it interferes with wifi). Thus it gets postponed indefinitely, but I hope to get around my sloth eventually (hopefully before the technology gets replaced by another wireless technology ...)

---

EDIT: I spent one hour trying to build the updated version of the applet we use in 700. Two things:
a) it needs gtk3 (which is not too bad) and another Harry Poetter library (which is a wonder why an applet needs that?), and then
b) it totally DROPS the applet and only provides "bluetooth-sendto" function
Making the entire package totally worthless (I already have a GUI script that can perform "sendto" once the device is connected).

In other words - they killed the standalone applet altogether (they merge the code with Gnome Control Centre or something) back in version 3.8 or something, in 2013

Oh well, time to put it back to the backburner for now.

[rufwoof]

Just a observation

Built 1.31.1 busybox (Fatdog currently using 1.27.0.git) as downloaded from busybox.net, using the default build (except setting make menuconfig to use static build).

make distclean defconfig
sed -i "s/.*CONFIG_STATIC.*/CONFIG_STATIC=y/" .config
make busybox

For Fatdog ...
# file ./busybox
./busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
#

For 1.31.1 ...
# file ./busybox
./busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, stripped
#

bin sizes ... 2,729,960 bytes (for 1.31.1) versus fatdog's 861,696 bytes

With initrd inside the kernel however the difference in kernel sizes ...

11.82MB versus 11.58MB

... that's with kernel .config set to use xz compression.

And that's with the default 1.31.1 build having more applets.

Seems to be working well, has both bc and dc and everything I've tested so far under kernel 4.14.153 appears to be working OK.

When first booted free -m indicates around half the memory being used for the 1.31.1. of the order 21MB versus 42MB when using Fatdog's busybox. That may however just be 1.31.1 having more cached (I only noticed that 21MB figure and recalled Fatdog's indicating 42MB, didn't really take any mental note of cache).

[jake29]

@jamesbond - I can appreciate that a Bluetooth applet is hardly something essential. It would seem the general advice is to avoid bluetooth for mouse or keyboard as it is so open to being unreliable for a number of factors (not even including broadcom vs intel). Having said that, I have now gone for over 3 hours without a disconnection - restarting the bluetooth service seems so far to be key.

I will monitor how things go and maybe report back in a week or so.

I'm considering upgrading to an Intel Wi-Fi 6 AX200 laptop card which features BT 5.0 - currently using an Intel AC 7265 with BT 4.2. I've ordered some aptX BT earbuds and BT 5.0 has 4x the range.

EDIT: Bluez 5.52 has fixed the 'duplicate device entry after reboot' issue for me.

[jamesbond]

EDIT: Bluez 5.52 has fixed the 'duplicate device entry after reboot' issue for me.

Thanks Jake. I'm updating bluez to 5.52.

I'm considering upgrading to an Intel Wi-Fi 6 AX200 laptop card which features BT 5.0 - currently using an Intel AC 7265 with BT 4.2. I've ordered some aptX BT earbuds and BT 5.0 has 4x the range.

The current build of bluez-alsa doesn't support aptx, because we don't have the underlying aptx library in it. In theory it would still work but it would fallback to using other codec.

I just updated bluez-alsa build to v 2.0.0 but I would withhold further update as it has a sudden growth spurts after being relatively dormant for months; so I will wait until it stabilises a bit.

@rufwoof: kexec as a standard build.

Thanks for the suggestion. I will keep this in mind, but at the time being I'm reluctant to do so.

@rufwoof: busybox bin sizes.

Thanks for the interesting size comparison. The huge static size comes because you're building a static binary with glibc. You will get a much smaller figure if you use uclibc or musl libc - but they present another set of problems (certain applets won't build etc).

In the usual Fatdog case, we don't compress the initrd at all, so the size difference does show up. The reason why we don't compress it is because we carry the initrd during uptime of the system (unlike standard Puppy, which removes its initrd once the main basesfs has been booted up); hence the entire uncompressed initrd will stay in memory. Thus, we have to make sure that the uncompressed initrd must remain the smallest size as possible - because it is an extra baggage.