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

[rufwoof]

/usr/share/doc/fd-help/links.md

"Fatdog64 is build following LFS principles"

->

"Fatdog64 is built following LFS principles"

[step]

Thanks rufwoof. Neat avatar, by the way.

[stemsee]

Booting from a usb thumbdrive (sdb1) I find that sdb1 is mounted on /tmp/extrasfs/mnt/1
It is read only, so I cannot edit grub.Yes, I have an extrasfs loading at boot.

I have a save directory on sda6, which is bind mounted as /mnt/home. sda6 is writeable.

Seems to me some unexpected and unuseful behaviour is afoot. What happened? is it the new kernel I built (5.1.9)?

Or is it a change?

stemsee

[step]

What happens when you don't specify an extrasfs on the bootloader line?

[rufwoof]

Fatdog includes a Control Panel option to create/activate a swap file, but if you'd rather the swap was encrypted then a alternative is to dd a file that will be used for swap, for instance create a 1GB file on a HDD partition/folder outside of fatdog space (persistent) - for example on /mnt/sdb1

cd /mnt/sdb1
dd if=/dev/urandom of=swapfile.crypt bs=1M count=1024

That can take a while to run through however once that has been created then we can re-use that at each reboot.

To setup/use that after each reboot add into /etc/rc.d/rc.local ...

Code: Select all

mkdir -p /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
cd /mnt/sdb1
loop=$(losetup -f)
losetup ${loop} swapfile.crypt
cryptsetup open --type plain --key-file /dev/urandom ${loop} swapfile
mkswap /dev/mapper/swapfile
swapon /dev/mapper/swapfile

and you'll have a encrypted swap file all ready to go at the next reboot.

You can check swap activation using

swapon -s

Or run htop and the swap space should show as being available.

That creates a unique random (throwaway) 'key' that is used to encrypt swap after each reboot, so there's no having to enter passwords.

[stemsee]

Hi step

It's a user error. I missed out the 'ram:' for the extrasfs argument!

Code: Select all

extrasfs=ram:uuid:*

All is well.
stemsee

[stemsee]

Kernel panic when booting fd with kernel 4.19.44
i had compiled 5.1.9 and also got the kernel panic. The same kernel boots BionicDog perfectly.

[rufwoof]

Acer ES 15 laptop's are known for their sluggish hdd - they seem to sleep quickly and have a delayed re-spin. So they're quite common Windows users throwaways (uncomfortably slow), but quite good for Fatdog. You still do however see some lag, typically when the hdd is accessed/used after not having been accessed/used for a little while. Fatdog control panel for instance takes a few seconds to show, as does the right click menu (couple of seconds). Once cached however re-runs are quicker at starting.

As a 'tweak' I opted to uncomment the hdparm in /etc/rc.d/rc.local, and that did seemingly make things better (quicker)

Code: Select all

####
# Laptop harddisk load/unload cycle count
# If your laptop harddisk runs an unusually high load/unload cycle count
# (you can see this by running "smartctl -A /dev/sda"), you need to change
# the power management mode of your harddisk by uncommenting the line below.
# Usually 254 works but every harddisk is unique and you will have to test 
# for yourself. Change "/dev/sda" with the name of your harddisk.
# This command can be repeated as many as needed, one for each harddisk.
####
#hdparm -B 254 /dev/sdb
####

Stayed with that for a day and it all ran well. However the next morning on doing a cold boot it started as normal, but then a re-boot later saw the multi-sessions load (I'm using a usb boot with multi-session saves back to that usb), but not be activated (original default wallpaper and settings loaded instead of my changes). At first I thought the usb might be dying, but then remembering the hdparm change I re-commented out that and its back to normal working again.

So just a word of caution. If you do modify the hdparm it can seemingly cause issues.

There is perhaps a better choice as indicated in the comments in rc.local, I know little however as to how that might be determined other than by just pure guesswork.

[don570]

new version of mtpaint 3.49.18
https://github.com/wjaguar/mtPaint
_______________________________________

[spotted]

Is anyone able to use the newest TOR browser
Without deleting the 'run as root' bit it wants to work but gets the do not run as root message as usual.

# ./start-tor-browser
./start-tor-browser: line 37: [: : integer expression expected
./start-tor-browser: line 54: zenity: command not found
./start-tor-browser: line 62: kdialog: command not found
Warning: Missing charsets in String to FontSet conversion

After deleting the 'do not run as root code' it just does not work, will not budge.
Reverts to the hash.

# ./start-tor-browser
#

Anyone have it sorted?

[step]

spotted, I think I'm using the newest TOR browser, file tbb_version.json reads

Code: Select all

{"version":"8.5","architecture":"linux64","channel":"release","locale":"en-US"}

I wrote a small starter script some time ago, and it's been working up to this version. Save the following code to /usr/bin/s-tor-browser or another name of your liking, and make it executable. Run the script to start tor browser. For added security, it runs the browser as user spot. For convenience, I keep the tor browser folder tor-browser_en-US, in /home/spot/Downloads/.

Code: Select all

log="/tmp/${0##*/}.log"
TBB=tor-browser_en-US
exec 2>"${log}"
cd /home/spot/Downloads/${TBB}/Browser &&
chown -R spot.spot .. &&
rm -f ../torbrowser.log &&
if ! exec run-as-spot ./start-tor-browser -l --detach "$@"; then
  [ -f ../torbrowser.log ] && cat ../torbrowser.log >> "${log}"
  defaultterm -title "ERROR while starting TorBrowser" -e less "${log}" &
  exit 1
fi
echo "see ${log}"

[spotted]

@ step
I had a bash at it.

# ./start-tor-browser
Logging Tor Browser debug information to tor-browser.log

./start-tor-browser: line 4: cd: /home/spot/Downloads/tor-browser_en-US/Browser: No such file or directory

I had to take 'tor-browser_en-US' out of its folder and delete that folder.
Then had to get gtk3 and it is working. Thanks

About this 'I keep the tor browser folder tor-browser_en-US, in /home/spot/Downloads/.'

I have taken Downloads out of the savefile when I created it and notice that .mozilla for Tor is in /root not /home/spot where seamonkey is.
Should I be putting Tor in /home/spot because I have Downloads outside of the savefile.
I am a bit late in answering, got a bit carried away with learning how to remastering the iso to fit the latest Firefox into the iso and take out gimp cups libre samba xsane which I do not use. Now want to know where Firefox goes also. Thanks

[WB7ODYFred]

Hello GCMartin and JamesBond and others.

I would like to boot from a USB Flash drive Fatdog64 802 Release and then on the same ethernet network via a router or switch a second PC laptop or desktop via PXE.

Is there some documentation written up on setting this up with Fatdog64 802 Release??

Beyond PXE forum post
http://murga-linux.com/puppy/viewtopic. ... 3f0d70818a


5-steps - Netboot a Puppy over the LAN with NO Media (PXE)
http://www.murga-linux.com/puppy/viewto ... 7&start=90

what happened to GCMartin. I cant find him on the membership list. I wanted to send him a private email asking this question.
Thanks for any pointers, documents, URL links regarding booting Fatdog64 802 via PXE on a second computer with no media but an ethernet connection.


Wb7odyFred

[rufwoof]

[step]

@spotted

I don't think that the mozilla folder matters for torbrowser. I think torbrowser keeps the user's profile in tor-browser_en-US/Browser/TorBrowser/Data/Browser, so that's where you should be looking for configuration stuff. Similarly, torbrowser downloads to tor-browser_en-US/Browser/Downloads.

So, the question is, where should folder tor-browser_en-US be located? That depends on whether you run torbrowser as user spot or as user root.

If you run torbrowser as user spot the you should keep tor-browser_en-US inside one of spot's folders. Otherwise, running as root, you can keep the folder wherever you prefer.

If you're running torbrowser with the script I provided then you're running torbrowser as user spot. Notice the command run-as-spot in the script file. That command runs torbroser as user spot.

When you run any process as user spot, the process will be granted rights to write to spot's files but not to root's (unless exceptions).

If you alternate running the browser as root and as spot, when you run as root, and a new profile file is written, root will own it. Next time, when you run as spot, spot won't have enough rights to write to that file. This will cause all kinds of issues.

That's why I keep tor-browser_en-US in /home/spot/Downloads. That location has magic properties in Fatdog64. Files in that location end up being owned by spot even when root creates the files. In other words, if root runs torbrowser in that location, the issues I alluded to in the previous paragraph won't occur.

You can take the Downloads folder out of the savefile and still keep tor-browser_en-US in /home/spot/Downloads, hence benefit from the magic. Simply move the Downloads folder from /home/spot to another location, say, /mnt/sda/home/spot/Downloads, then create a symbolic link from /home/spot/Downloads to /mnt/sda/home/spot/Downloads. This is how I did it. Your default downloads folder should be set to /home/spot/Downloads: the symbolic link will take care of rerouting files to /mnt/sda behind the scenes.

[rufwoof]

I would like to boot from a USB Flash drive Fatdog64 802 Release and then on the same ethernet network via a router or switch a second PC laptop or desktop via PXE.

PXE does limit you to having to be hard wired (ethernet). With the prevalence of wireless a alternative is to have a minimal boot usb client, just the small initrd and vmlinux, that wireless net connects during bootup and uses a nbd server to load the base sfs from and save to.

Fatdog comes with nbd already installed so nbd-server is already available, just needs to be configured and started. So on your server box its something like ...

/etc/nbd-server/config ...

Code: Select all

[generic]
	listenaddr = 192.168.1.4
	oldstyle = true
[disk1]
	exportname = /mnt/sdb1
	flush = true
	fua = true
	port=9000

Then start it ... nbd-server

For your client (where XXXXXX is your wireless ssid and yyyyyy is the password, and assuming your nbd servers IP is 192.168.1.4) when using grub4dos, a menu.lst entry something like ....

Code: Select all

title Fatdog
find --set-root /initrd
kernel /vmlinuz net=wpa2:XXXXXX:yyyyyy:wlan0:dhcp basesfs=ram:nbd:192.168.1.4:9000 savefile=ram:nbd:192.168.1.4:9000
initrd /initrd

That all said, I haven't actually got that working under Fatdog myself. For one the initrd net connect seems to work during bootup but isn't active once the desktop is loaded, and for another the nbd server/client as outlined above isn't compatible with Fatdog's versions i.e. doesn't work for me (looks like modprobe nbd ... doesn't load anything).

[rufwoof]

Fatdog has earlyshell and lateshell boot parameters already.

Proposed change : to add a midshell boot parameter in addition to those, where initrd's /sbin/system-init, around line 1450 is extended to include

grep -q midshell /proc/cmdline && echo 'Starting midshell. Type "exit" to continue or reboot -f to reboot' && setsid cttyhack /bin/sh

so it looks like ...

Code: Select all

# earlyshell - after load modules and pkeys so that usb keyboard works
grep -q earlyshell /proc/cmdline && echo 'Starting earlyshell. Type "exit" to continue.' && setsid cttyhack /bin/sh

# waitdev and wait for usb disk
process_waitdev

# configure network - after load modules, before basesfs
process_net

# process keyfile - after load modules, before basesfs
process_keys

# midshell
grep -q midshell /proc/cmdline && echo 'Starting midshell. Type "exit" to continue or reboot -f to reboot' && setsid cttyhack /bin/sh

# configure mdadm and lvm if requested, before basesfs and savefile
process_dofsck
process_mdadm # note: mdadm before lvm
process_lvm

Fatdog help files would also need to be revised to include the midshell boot choice alongside earlyshell and lateshell descriptions

Why: Because that's before fd64.sfs gets loaded, but is potentially after keyboard and wireless or ethernet net connection has been established. i.e. if you boot with the net boot parameter such as ... (assuming grub4dos menu.lst (note I've changed my actual wireless ssid and password in this example to VM999999 and xxxxxxxx respectively))

Code: Select all

title Fatdog midshell with wlan0
root (hd0,0)
kernel /vmlinuz midshell net=wpa2:VM999999:xxxxxxxx:wlan0:dhcp pkeys=uk video=640x400 savefile=none
initrd /initrd

then that boots to (initrd) cli and I can telnet, ssh ...etc. as desired, which includes being able to potentially wget, curl, scp or whatever a alternative fd64.sfs from a local/remote location to replace the fd64.sfs within initrd that otherwise was just about to be loaded - or indeed insert a fd64.sfs where one might not already be available within initrd.

Once copied (got), exiting from that shell then continues to load/use that fd64.sfs

That could be enhanced further, to perhaps include a midshell=...command... action such that if present that command might remotely retrieve a fd64.sfs

midshell=wget some.site/fd64.sfs ... type action, and if present/specified assume a exit shell action after that completes so that the boot process automatically continues booting to gui desktop with that remote fd64.sfs having been loaded/used.

With the likes of 5G speeds more commonly available, it may actually be quicker to boot using a remote wget type fd64.sfs than the time it takes to load (copy) a fd64.sfs off of DVD/usb (assuming booted via dvd or usb).

Its also nice having a cli with network connected additional boot choice (boot with midshell, run reboot -f when done rather than exit to continue to boot to gui desktop).

[rufwoof]

Just finished a successful test where initrd was opened and fd64.sfs moved out of that (stored it on hdd) before closing that newly formed (minus fd64.sfs) initrd. Booting that initrd (reduced down to around 77MB so BIOS copies that a lot quicker from usb to ram) with the midshell kernel boot parameter, and using initrd's cli to mount the hdd and copy in fd64.sfs from hdd to initrd's / folder, followed by 'exit' to resume booting ... had the system all boot and run fine.

Note that at that initrd cli stage of booting devices are random. For instance my usb and hdd can respectively be /dev/sda1 and /dev/sdb1 ... or they might be /dev/sdb1 and /dev/sda1. So local storage of a fd64.sfs requires hunting for the appropriate actual device. However for remote retrieval (wget, curl, ssh, whatever) of a fd64.sfs that's not a issue i.e. is a fixed URL or IP location.

EDIT: Observations.

I had to convert my Openssh based ssh keys to dropbear format for use within initrd as initrd is using dropbear for ssh (in fatdog I installed dropbear, and ran dropbearconvert openssh dropbear id_rsa db_id_rsa). You also have to specify the key location with dropbear so scp -i /root/.ssh/db_id_rsa user@some.host:fd64.sfs fd64 ... type format.

scp from out of initrd was incredibly slow. Gave up after 15 mins and only half of fd64.sfs downloaded. wget in contrast was much quicker. For instance

Code: Select all

wget --no-check-certificate https://distro.ibiblio.org/fatdog/iso/Fatdog64-802.iso

took 1m 30s to download the full fatdog iso from ibiblio. Even then though, not as quick as I'd hoped for. But ibiblio is generally slower for me (UK) anyway than the likes of https://ftp.nluug.nl/ibiblio/distributi ... 64-802.iso (that I haven't tested yet)

[spotted]

@ step
The Downloads folder was put in the next door ext4 partition when I made the savefile, the owner is spot and group is spot so that is spot-on.
Is 'container' as in easy OS, the right word. Is Home, Spot, Downloads, one big container that a cracker cannot get out of once he is able to get in?
When getting Firefox using the control panel updates, no matter where you put Firefox, Firefox is hard wired to put .mozilla in /root. Could a cracker tunnel from Downloads to /root going through Firefoxes linkage to .mozilla in /root?
I have put Firefox into Downloads also, do I have to make a script to make Firefox run as Spot to make it secure?
I have to use Firefox, when I transfer my age pension to my self I use a XXXX company and their web site does not work with Seamonkey.

[step]

Is 'container' as in easy OS, the right word.

I don't know about easy OS, sorry. This is the Fatdog64 thread. I use container in its regular meaning, "something that holds something else", and specifically the container folder or directory, which holds other files and folders.

Is Home, Spot, Downloads, one big container that a cracker cannot get out of once he is able to get in?

Generally not. /home/spot/Downloads is just a regular directory in your file system. The magic that Fatdog64 performs applies only to the files that are located in that folder. There is no other magic. Try yourself. Create an empty file in /root so that root owns it. Then move that file to the /root/Downloads folder, which is the same folder as /home/spot/Downloads by means of symbolic linking. Now look at who owns that file when it's in the Downloads folder. Right, spot owns it now. That's the magic. There is no reverse magic. If you move the file out of Downloads and back into root/ spot will continue to own the file.

When getting Firefox using the control panel updates, no matter where you put Firefox, Firefox is hard wired to put .mozilla in /root.

It isn't about where you put firefox. It's about how you run firefox. If you run it as root configuration files will be in root's folders. If you run it as spot they will be in spot's folder.

Could a cracker tunnel from Downloads to /root going through Firefoxes linkage to .mozilla in /root?

If firefox runs as spot, the most damage a cracker could do is what spot can do to the system. Spot can write into spot's folders, /root/Downloads and /tmp. Spot (and the cracker) can't write to other default locations in the file system. That's why I run the browser and other Internet programs, including wine, as user spot.
If you add disks to your system , you should know who owns the folders and what write permissions are set for who. Generally speaking, if root owns all files and folders and you didn't change default write permissions, you should be covered against tunnels through firefox running as spot.
If you run firefox as user root you are wide open. Your choice.

I have put Firefox into Downloads also, do I have to make a script to make Firefox run as Spot to make it secure?

If you added firefox from the control panel applet, you should leave things are they are, not move stuff around, with the exception of the Downloads folder, which we've already covered at length.
Then again the key question is how do you run firefox. You you use the system menu entry it should run as spot. Confirm that using Control Panel > Utilities > Task Manager when firefox is running.

I have to use Firefox, when I transfer my age pension to my self I use a XXXX company and their web site does not work with Seamonkey.

Very well. Make sure you run Firefox as spot.