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

Message

rufwoof · #406 Post by **rufwoof** » Sat 16 Nov 2019, 18:41

Both /etc/wpa_supplicant.conf and /proc/cmdline are readable by 'others', which if they contain wifi ssid and password ... not good (a browser with a flaw even though running as spot could enable remote reading of your wifi ssid and password).

jake29 · #407 Post by **jake29** » Sun 17 Nov 2019, 15:22

Hi all. I was hoping to upgrade the Intel WiFi card currently in my laptop - Intel AC 7265 - not just to improve WiFi connectivity, but to also benefit from Bluetooth 5.0.

Pricing for older models is almost the same as for the latest 2019 card 'AX200' - however I noticed that official support page states that Kernel 5.1+ is required.

https://www.intel.com/content/www/us/en/support/articles/000005511/network-and-io/wireless-networking.html

Can anyone comment on the back-porting of WiFi adapter drivers? Could the driver be made work with the current Kernel 4.19? Is an upgrade to Kernel 5.1 planned any time soon?

EDIT: I followed a back-porting tutorial here and build: intel_ax200_backport-x86_64-802.txz

jamesbond · #408 Post by **jamesbond** » Mon 18 Nov 2019, 11:19

Thanks rufwoof, fixed for future release.
Thanks jake29 for the module.

don570 · #409 Post by **don570** » Tue 19 Nov 2019, 00:21

I have been reading about bluetooth drivers and I found this software
that claims to be universal driver for linux...
https://github.com/torvalds/linux/blob/ ... th/btusb.c
__________________________________

don570 · #410 Post by **don570** » Tue 19 Nov 2019, 00:24

I've been using pclock for a countdown timer but the warning sound isn't loud enough
so I replaced the warning sound with 2barks by modifying pclock script...

Code: Select all

echo '/usr/share/audio/2barks.au' > $WORKDIR/COUNTDOWN_ACTION

____________________________________________

don570 · #411 Post by **don570** » Tue 19 Nov 2019, 00:35

I suggest that instructions for auto-mounting ntfs Windows partition be included in /usr/share/ docs
________________________________________________

jake29 · #412 Post by **jake29** » Tue 19 Nov 2019, 01:39

don570 wrote:I have been reading about bluetooth drivers and I found this software
that claims to be universal driver for linux...
https://github.com/torvalds/linux/blob/ ... th/btusb.c
__________________________________

I would say Bluetooth support is working very well currently in Fatdog64-802, at least in regards to the mouse I have tested. My only problem is that both mouse and my Bluetooth chip are v4.1. I was motivated to buy a bluetooth mouse for the benefit of what I hoped would be improved tracking and distance. Unfortunately, this has not been entirely the case.

I have now ordered a replacement Bluetooth 5.0 mouse and an Intel AX200 WiFi / Bluetooth card which supports v5.0.

belham2 · #413 Post by **belham2** » Wed 20 Nov 2019, 10:05

Hi Fatdog,

Is there a problem with the "Save as multisession" function of Fatdog?

For example:

1) a pristine boot of a frugal folder of Fatdog-802

2) Boots up great (using initrd-nano)

3) Make changes to Fatdog, like setting Time and Format, disabling and enabling services (using Fatdog64 Service Manager), then using "Manage desktop startup programs" to set some things.

4) Then I want to test multi-save session function: I click reboot, go thru the process, creating new passwd and then clicking "Save as multisession"

5) Fatdog creates the appropriate multisave-base.sfs and mutlisave-save.sfs as it shuts down & reboots itself

6) Fatdog re-boots back up, goes to the same pristine desktop, then I....

7) go into Control Panel, System tab, click on "System SFS Loader". Tell SFS Loader where those two SFSes (above) are, in the same sda1 partition as the main Fatdog folder, and then load the two SFSes. It says they load and are loaded (and manually checking, clicking on the SFSes, shows all the changes I had made to the SFS are in these two SFSes that had been previously created)

Ok, great, but not one change (inside the multisave.SFSes) that i had made specfically to Fatdog's settings is loaded, i.e. no clock changes, no services that had been set and started (before the multi-session save was enacted), nothing. Other stuff like browser changes and stuff is loaded, but not other things.

What am I doing wrong?

I would like Fatdog to boot up pristine every time, and then I will manually load whichever previous-session-reated "multisession.SFS" file I choose. But, darn, this is just not working.

Fatdog is only loading some of the changes from the Multisession.SFS files (when loading then after the next prisitine bootup). Pointedly, none of the services changes, toolbar changes, etc, etc are loaded when the base and save-SFSes are loaded. Very frustrating; I got so frustrated had to walk away for awhile as I was getting angry at myself for being too stupid to understand what is going on

. (Also, please know, I tried this repeatedly with Fatdog booting on different USB EXT4-formatted sticks, thinking maybe a stick was bad, but it's not the USB sticks).

Is it possible I have my menu.lst entry all wrong for this to work (pristine Fatdog boots every time, no savefile whatsoever, and loading previous-boots-created multisession.SFSes only)? Here is the menu.lst entry I use when Fatdog64-802 boots up:

Code: Select all

"title Fatdog64-802"
   uuid ########-####-#####-##########
   kernel /Fatdog64-802/vmlinuz rootfstype=ramfs mergeinitrd1=local:/Fatdog64-802/initrd waitdev=3
   initrd /Fatdog64-802/initrd-nano

It boots great, and fast, but like mentioned before, many of the changes that the 'Save as Multisession" SFSes should have saved do not load after I manually choose them at the next pristine boot.

Thank you for any help regarding this.[/code]

rufwoof · #414 Post by **rufwoof** » Wed 20 Nov 2019, 11:10

In multi-session save mode, you set Fatdog to load all of the prior saves automatically at next reboot, there's no need to manually set/load them by-hand, you just add the appropriate 'savefile' kernel boot parameter.

You can't be selective, as they're sequential save sfs's, so missing one out in the middle would mess things up. You can however opt to not load the last N saves. For readability I've shortened down my actual uuid in the following, but that's the kernel boot paramater I use for multi-session. The last two ":" don't have to be included, but I leave them as that way its a reminder of where the 'skip' N saves value is

savefile=direct:multi:uuid:5d::

i.e. if I change that to

savefile=direct:multi:uuid:5d::2

then it wont load the last two saves.

Or you could just manually delete the last (most recent) save sfs

When you have say 10+ saves and want to consolidate them, I boot (so all the saves are loaded into ram), manually delete all of the multisession save files (sfs's) - backing them up first just in case, and then click the desktop 'save' icon ... and its back down to just two save sfs's.

My full menu.lst entry looks like
title FatDog
root (hd0,0)
kernel /fatdog-vmlinuz pkeys=uk waitdev=5 basesfs=ram:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd:/fd64.sfs savefile=direct:multi:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd::
initrd /fatdog-initrd.xz

Note that in my case I originally clicked on the initrd to open it, dragged out the fd64.sfs from that, and then closed the initrd again (by clicking the repack-initrd file) so as to have the main sfs (fd64.sfs) outside of initrd. Note also that I've renamed the vmlinuz and initrd (and I've also opted to xz compress the initrd) ... i.e. not they're not the default/standard names

The appeal of multisession for me is that I install it all to and boot/run from usb stick (bootloader etc.), and all saves are written back to that usb. But where I have Event Manager's Save Session Interval set to zero so it only ever saves on demand, and the usb can be removed between times (i.e. is physically isolated after having booted up the system). Mostly I'm very frugal with saves

i.e. tend to just boot, use, shutdown without saving, and I'm careful as to what saves are added (boot clean, make changes, save ... without doing anything else so that the system remains 'clean'). I keep my bookmarks in a text file, and have tilda drop down terminal installed, where one of its tabs has that bookmarks text file open (and where hovering-over and clicking a link opens up that url in chrome). Chrome is about the only reason I run 'save' i.e. boot, use the control panel to update to the latest version of chrome, save.

Another appeal is that Fatdog only improves with age, each later release builds upon the last release. With Puppy it often seemed one step forward two steps back i.e. some past improvements were suddenly lost.

Yet another appeal of Fatdog for me is that its alsa equaliser works. i.e. running alsamixer presents the usual alsa mixer, but running alsamixer -D equal ... presents a working equaliser. And, at least for me, its alsa supports multiple sound sources being played simultaneously.

rufwoof · #415 Post by **rufwoof** » Wed 20 Nov 2019, 12:14

If you do use a usb for your entire fatdog system, just use the HDD for data, then noteworthy is that Fatdog includes encfs ... i.e. create a top level folder called DATA (or whatever) and store files/folders under that, and use encfs to encrypt that DATA folder (in rox, right click on the folder and its one of the options there). That way if your laptop is lost, your data is at least encrypted. I also do similar for the ~/.ssh files stored on usb - but using a more intensive encryption method, so if my usb is lost/stolen then my ssh keys are strongly encrypted. Whilst I could use the standard ssh encrypt key I prefer a stronger encryption than the 'built-in' encryption.

Booting to ram from usb using multi-session saves, where that usb is removed once the system has booted, combined with being careful/frugal with 'saves', along with data (and ssh keys) being encrypted, and provided you also keep good backups of your data (to physically disconnected media) ... makes Fatdog one of the best systems around IMO.

jake29 · #416 Post by **jake29** » Wed 20 Nov 2019, 23:12

Hi all. I am getting the following error when a streaming app drops it's connection:

Code: Select all

(shadow-preprod:11390): libnotify-WARNING **: 23:02:51.651: Failed to connect to proxy

Does this indicate libnotify plays a role in the crash or is only reporting it?

I have tried to pkgbuild libnotify 0.7.8 just in case, however it now seems to rely on MESON.

SFR · #417 Post by **SFR** » Wed 20 Nov 2019, 23:58

@Jake29: There's v0.7.7 is in the repo, but it requires GTK3.
It might be the culprit indeed, though: https://github.com/meetfranz/franz/issues/592

Greetings!

jake29 · #418 Post by **jake29** » Thu 21 Nov 2019, 00:04

SFR wrote:@Jake29: There's v0.7.7 is in the repo, but it requires GTK3.
It might be the culprit indeed, though: https://github.com/meetfranz/franz/issues/592

Thanks for the reply SFR. I have v0.7.7 installed already, that's why I looked into upgrading. I have had this problem for many months, talking with the app developers has not been productive (mainly because issue does not occur in Ubuntu). Could you assist with building libnotify v0.7.8? I have tried my best on a few occasions now.

SFR · #419 Post by **SFR** » Thu 21 Nov 2019, 00:26

Sure, but it turned out that 0.7.8 requires meson 0.47+ to build, we have 0.46.1.
But ok, the attached contains both meson-0.52.0 and libnotify-0.7.8 recipes.

Anyway, is there an option to disable notifications in that app you're using?
It seems that it helped the OP in the previously linked GitHub issue.

Greetings!

jake29 · #420 Post by **jake29** » Thu 21 Nov 2019, 05:57

SFR wrote:Sure, but it turned out that 0.7.8 requires meson 0.47+ to build, we have 0.46.1.
But ok, the attached contains both meson-0.52.0 and libnotify-0.7.8 recipes.

Anyway, is there an option to disable notifications in that app you're using?
It seems that it helped the OP in the previously linked GitHub issue.

Greetings!

Thanks SFR for this. I was able to build and install the updated libnotify. Unfortunately, there has been no change so far regarding crashing. There are zero in-app options related to notifications. I think I will need to boot into Ubuntu and observe notification behaviors. It could well be the source of the issue.

The app will only crash in windowed-mode; full-screen it is perfectly stable. This could lead to the solution if I can convince the developers to allow suppressing of notifications or include a safe-mode startup command.

belham2 · #421 Post by **belham2** » Thu 21 Nov 2019, 07:04

rufwoof wrote:In multi-session save mode, you set Fatdog to load all of the prior saves automatically at next reboot, there's no need to manually set/load them by-hand, you just add the appropriate 'savefile' kernel boot parameter.

You can't be selective, as they're sequential save sfs's, so missing one out in the middle would mess things up. You can however opt to not load the last N saves. For readability I've shortened down my actual uuid in the following, but that's the kernel boot paramater I use for multi-session. The last two ":" don't have to be included, but I leave them as that way its a reminder of where the 'skip' N saves value is

savefile=direct:multi:uuid:5d::

i.e. if I change that to

savefile=direct:multi:uuid:5d::2

then it wont load the last two saves.

Or you could just manually delete the last (most recent) save sfs

When you have say 10+ saves and want to consolidate them, I boot (so all the saves are loaded into ram), manually delete all of the multisession save files (sfs's) - backing them up first just in case, and then click the desktop 'save' icon ... and its back down to just two save sfs's.

My full menu.lst entry looks like
title FatDog
root (hd0,0)
kernel /fatdog-vmlinuz pkeys=uk waitdev=5 basesfs=ram:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd:/fd64.sfs savefile=direct:multi:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd::
initrd /fatdog-initrd.xz

Note that in my case I originally clicked on the initrd to open it, dragged out the fd64.sfs from that, and then closed the initrd again (by clicking the repack-initrd file) so as to have the main sfs (fd64.sfs) outside of initrd. Note also that I've renamed the vmlinuz and initrd (and I've also opted to xz compress the initrd) ... i.e. not they're not the default/standard names

The appeal of multisession for me is that I install it all to and boot/run from usb stick (bootloader etc.), and all saves are written back to that usb. But where I have Event Manager's Save Session Interval set to zero so it only ever saves on demand, and the usb can be removed between times (i.e. is physically isolated after having booted up the system). Mostly I'm very frugal with saves i.e. tend to just boot, use, shutdown without saving, and I'm careful as to what saves are added (boot clean, make changes, save ... without doing anything else so that the system remains 'clean'). I keep my bookmarks in a text file, and have tilda drop down terminal installed, where one of its tabs has that bookmarks text file open (and where hovering-over and clicking a link opens up that url in chrome). Chrome is about the only reason I run 'save' i.e. boot, use the control panel to update to the latest version of chrome, save.

Another appeal is that Fatdog only improves with age, each later release builds upon the last release. With Puppy it often seemed one step forward two steps back i.e. some past improvements were suddenly lost.

Yet another appeal of Fatdog for me is that its alsa equaliser works. i.e. running alsamixer presents the usual alsa mixer, but running alsamixer -D equal ... presents a working equaliser. And, at least for me, its alsa supports multiple sound sources being played simultaneously.

Thanks, Rufwoof, that clears it up for me. Had totally forgot about I needed to make menu.lst changes if I want Fatdog to look for something I created on a previous pristine boot and I had not created a 'savefile' at the end of that pristine boot (so Fatdog could remember things for next next boot).

Soon as I saw your menu.lst example, I had to shake my head at myself

Thanks again.

rufwoof · #422 Post by **rufwoof** » Thu 21 Nov 2019, 09:39

This is another menu.lst of mine, that boots from hdd (again for readability I've shortened down the uuid for the disk, you can identify the uuid for a disk/partition by using the blkid command)

title Fatdog TIP
root (hd0,0)
kernel /FATDOG-TIP/vmlinuz net=wpa2

1234:wlan0:dhcp pkeys=uk lateshell basesfs=ram:uuid:4d054dbd-ff:/FATDOG-TIP/fd64.sfs savefile=direct:multi:uuid:4d054dbd-ff:/FATDOG-TIP/:
initrd /FATDOG-TIP/initrd

where the files are stored in a /FATDOG-TIP folder

At bootup it connects to wifi (net= ... settings, abcd and 1234 are not my actual ssid/password) and boots to cli (lateshell kernel parameter). When done with cli you can either 'exit' to resume bootup to the full gui desktop, or whatever (shutdown/reboot).

rufwoof · #423 Post by **rufwoof** » Mon 25 Nov 2019, 12:11

jamesbond wrote:@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.

Outside of the standard build - fair enough, but having (static) kexec available in the repository perhaps ??

Assuming a usb boot type setup, having a default Bulldog that caters for booting (to initrd cli), prompting for the usb to be unplugged before continuing, so that the usb is physically isolated, and only then loading up the main system and/or net connecting ... keeps the MBR/bootloader/kernel/initrd (usb) out of harms way (clean). Whilst providing the potential to include checksums/filesize details checking of the main sfs so that the fd64.sfs is pre-validated prior to it being loaded/used. With kexec available, that could be used as a secure 'bootloader' (Bulldog in effect being used as a form of bootloader to boot other Puppy's/whatever). kexec compiled as a static needn't be contained within Bulldog/initrd, in fact its possibly better to keep that binary outside of initrd, storing/running it alongside whatever its being used to boot.

With bbshell/bbhook in the pipeline however, that is pretty much possible as-is. kexec could be 'installed/run' by that 'external' script. However process_network would ideally be better placed in init AFTER bbshell/bbhook

My thinking (thoughts seeded by gjuhasz's Puli http://murga-linux.com/puppy/viewtopic. ... 18#1042618) is that rearranging init, perhaps moving process_net down from its current position in tip/current to being just after bbhook/bbshell, and also adding another bbhook/bbshell after process_net ... would do the trick. Two bbhook's/bbshell's (pre-net and post net) perhaps named bbshell1 and bbshell2 ... or perhaps something like bbprenet, bbpostnet. With the intent that bbprenet can be used to prompt to unplug the usb with that occurring before (early) net connect (net connection being a potential system integrity risk), and bbpostnet being used (assuming a net: kernel boot parameter also having been set) to ssh to a known ssh server in order to potentially flag any man-in-middle attack. Those scripts could also be used to checksum/filesize check fd64.sfs (or whatever) against known values (stored on the usb/copied into ram), as could any other Puppy boot files be validated/checked (that might be being booted using kexec instead of booting fd64.sfs).

Any appeal for a portable Bulldog based secure 'bootloader' usb stick, purely for secure bootup purpose would have the natural tendency to also induce booting the main fd64.sfs IMO (expand appeal/usage of Fatdog). Transforming Bulldog from a predominately little used available option into something that has wider usage appeal (amongst other things - a secure portable bootloader)

Specifically ...

Make kexec static available in the repo
http://murga-linux.com/puppy/viewtopic. ... 75#1040675

Revise init to move process_network down to below bbhook/bbshell (in the current TIP), renaming bbhook/bbshell to bbpreearlynet

Add another bbhook/bbshell (bbpostearlynet) immediately after process_network

Revise the standard kernel .config (build) to include the KEXEC support by default

CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y

I have tried that and moving process_network down to later on in init worked OK for my setup. I don't think that will have any other implications - but leave it for the experts/wiser

jamesbond · #424 Post by **jamesbond** » Tue 26 Nov 2019, 00:00

@rufwoof:

- Make kexec static available in the repo
OK.

- Revise init to move process_network down to below bbhook/bbshell (in the current TIP), renaming bbhook/bbshell to bbpreearlynet
- Add another bbhook/bbshell (bbpostearlynet) immediately after process_network
Counter-proposal:
1. process_net stays where it is (that is, before bbhook/bbshell)
2. bbhook/bbshell remains what they are
3. Add a "wait" prefix to the "net" parameter to pause boot before net is processed. (net=wait:original-net-parameters).

- Revise the standard kernel .config (build) to include the KEXEC support by default
This comes with risks as well. I don't think the benefit (for the general population) is worth the risk, so I will have to say no to this one. Everyone who wants to do this is of course welcome to compile their own kernel, as you do, but standard Fatdog will not come with this enabled.

- Any appeal for a portable Bulldog based secure 'bootloader' usb stick
I did that for FatdogArm six years ago: http://lightofdawn.org/wiki/wiki.cgi/KexecBootMenu but I fail to see the benefit of doing that for the x86_64 platform where we already have excellent bootloaders. Of course I do see the point that a Bulldog-based bootloader the way you propose will be much, much more flexible - as you have the entire power of Linux kernel and userspace available for use, as opposed to the limited scripting abilities of even the best bootloaders - but for now it remains a very obscure use case.

rufwoof · #425 Post by **rufwoof** » Tue 26 Nov 2019, 00:51

I like your "wait" net idea James. Works for me

Code: Select all

process_net() {
	[ "$net" = "ask" ] && read -p "net=" net 2>&1
	[ -z "$net" ] && return;
	OIFS="$IFS"; IFS=":"; set -- $net; IFS="$OIFS"
	
	[ "$1" = "wait" ] && 
		shift && 
		echo 'Starting pre-net shell. Type "exit" to continue.' && 
		setsid cttyhack /bin/sh  
	
	echo -n "Configure network "
	# network type
	case $1 in ......

Alternatives to running a shell as per the above might be to run a script i.e. perhaps containing a prompt to unplug the usb and press enter to resume standard bootup (net connect etc.).

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

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

Security issue

Intel WiFi cards

bluetooth drivers

Re: bluetooth drivers