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

[devitalio]

What does your menu.lst look like?

I've started from USB first entry (I bielieve it was saying just "Start Fatdog") so I assume boot opts are default ones.

Does this save button appears upon some condition? like ram save interval set to 0?

[SFR]

Guys in the FAQ, under section 4 (How to install Fatdog64 to BIOS machine.) under subsection Session saving control it says that I can save the session anytime by "You can save by clicking the big red "Save" button on the desktop", but I cant find out this big red button. Confused Any ideas? Or should the doc be updated?

At the end of the section you've mentioned:

Unlike Puppy Linux, Fatdog64 does not try to automatically enable the RAM layer feature for flash drives. You need to specifically enable RAM layer (please refer to Boot Options.

But I understand that if you're new to Puppy in general, it's not necessarily something obvious.

In short: by default RAM layer is not enabled, therefore all changes in the session go straight to your savefile/savefolder (if you have one, see below).
If you want to enable it, you need to specify a boot param and in the simplest scenario it would be: savefile=ram:local, unless you've created your savefile/folder in a non-default location.
More info about this parameter here in the FAQ, under "Advanced Parameters".

I've started from USB first entry (I bielieve it was saying just "Start Fatdog") so I assume boot opts are default ones.

Does this save button appears upon some condition? like ram save interval set to 0?

When you start Fatdog for the first time, without a savefile/folder, you're asked to create one at shutdown.
Then, after reboot (and adding the aforementioned 'savefile=ram:local' boot option), you'll see the Save icon on the desktop.

Also, see this for more info on how the layered filesystem is implemented in Fatdog.

Greetings!

[rufwoof]

Purely for reference :

I did a True Full Install and added chrome to that (which also installs gtk3), and installed the devx. 4.9GB total size. Creating a lz4 compressed squashfs of that (1.9GB) ... and to restore that 'clean' (locale etc configured) version takes around 4 minutes on the relatively slow HDD kit I'm using.

i.e. to remove the existing content of the partition I used
mkdir empt_dir; rsync -a --delete empty_dir/ /mnt/sda4
that took 38.3 seconds to wipe the 4.9GB
and 3m 16s to to lz4 unsquashfs (restore the clean version) 1.9GB -> 4.9GB extraction time (unsquashfs -f -d /mnt/sda4 sda4.sfs). I didn't use the high compression lz4 choice when creating the squashfs so that would be quicker to extract as it compresses more tightly, but doesn't involve any more overhead when decompressing.

Layered Full Install looks interesting as that seemingly still supports loading sfs's and caters for not saving changes made during a session. Very much like Debian's live-boot that uses a partition for saving changes and where that partition can contain a fully installed version (so option to boot as a full install and have all changes recorded, or boot 'frugally' (live-boot) and optionally have changes saved (or not) - and that supports loading/layering sfs's.

EDIT: tried a Xhc high compressed lz4 file which as 1.6GB, but extraction was only marginally quicker (3m10s). Also should have mentioned I was running under dual core (lz4 uses all available cores), so on a quad or higher core extraction times might be considerably quicker. As would be the case if a higher speed drive/partition (SSD) was being extracted to.

A benefit of full installed/non layered is that there is no initrd involved, so one less security weakness (relatively easy to open initrd and inject a crackers code that could for instance create a sub-system layer that initiated a connection to a crackers site). Personally I checksum each of mbr, grldr, vmlinuz, initrd, main sfs and save folder sfs as part of bootup to better secure against such cracks - but most Puppy's/derivatives by default don't run such checks.

[mavrothal]

* Better MBP support out of the box

Indeed!

Only needed to add the facetimehd kernel module forthe webcam and adjust the pmcputemp path a bit to get the correct input.

[jamesbond]

Only needed to add the facetimehd kernel module forthe webcam

I'd kirk if he's willing to include this in his next kernel build.

and adjust the pmcputemp path a bit to get the correct input.

If need be, this can be a script. pmcputemp is good in the way that we can dynamically change the input path from its config file that it will pick it up without restarting. On my laptop here I have a script called "find-cputemp-sensor" which gets executed whenever Xorg starts (it is located in /root/Startup). If you can figure out how to do this, we can include this script by default (in disabled state) and have it enabled by rc.platform if the platform is MBP.

[mavrothal]

Only needed to add the facetimehd kernel module forthe webcam

I'd kirk if he's willing to include this in his next kernel build.

Not sure if it worth it as it also needs the firmware and this can be macbook model-specific

and adjust the pmcputemp path a bit to get the correct input.

If need be, this can be a script. pmcputemp is good in the way that we can dynamically change the input path from its config file that it will pick it up without restarting. On my laptop here I have a script called "find-cputemp-sensor" which gets executed whenever Xorg starts (it is located in /root/Startup). If you can figure out how to do this, we can include this script by default (in disabled state) and have it enabled by rc.platform if the platform is MBP.

All I did is to add "/coretemp.0" in the find ...../platform path as the first input there is the correct one.
You can sed this in at rc.platform I guess.

[jamesbond]

Not sure if it worth it as it also needs the firmware and this can be macbook model-specific

Oh ... you need firmware. In that case I agree it's probably not worth it.

All I did is to add "/coretemp.0" in the find ...../platform path as the first input there is the correct one.
You can sed this in at rc.platform I guess.

So it looks like this?

Code: Select all

for m in ${mod} /coretemp.0 coretemp k10temp k8temp it87 lm85

[mavrothal]

So it looks like this?

Like this

Code: Select all

--- a/usr/bin/pmcputemp.sh	
+++ b/usr/bin/pmcputemp.sh	
@@ -46,7 +46,7 @@
 check_temp_data_exists() {
 	#echo "checking data" # COMMENT THIS IN REAL LIFE
 	# the rough order is Intel, AMD, whatever else
-	for a in `find /sys/devices/platform -type f -name 'temp*_input'|sort` \
+	for a in `find /sys/devices/platform/coretemp.0 -type f -name 'temp*_input'|sort` \
 			`find /sys/devices/pci* -type f -name 'temp*_input'|sort` \
 			`find /sys/devices/virtual -type f -name 'temp'|sort`
 	do find_func "$a"

Edit: Just to clarify for some... This is about MacbookPro. They actually have 41 thermal sensors. The change above picks up only the CPU sensors of the 4 cores and shows the temperature of the first core doing more or less what this simple app suppose to do (show the CPU temperature).
For a full thermal report you may want run sensors-detect and add (compile) psensor for an informative GUI. And of course clean and lube the damn thing

[Sage]

Some folks never listen! What are you trying to measure? where? why?how does it relate to cpu internal architecture, mounting, cooling/& co. Multicore? which core, which diode? If you're worried about thermal runaway - it's gonna be too late! The humble external thermocouple would be a better general guide to what's going on and can be connected to an old-fashioned chart recorder for the serial paranoids.

I covered the broad outlines earlier. For those folks determined to use laptops despite advice, determined to use Intel despite advice and pre-built boxes with someone else's choice of hardware (based on lo-cost/hi-profit) rather than technical merit and suitability - I repeat that they deserve the problems they encounter. Determined laptop users would better use their time and effort keeping the internals and air-channels dust-free; buy a vacuum cleaner? re-Lube the fan annually?

Then there's the 'free' Windydoze' (re)install issue which searches for the embedded W code in commercial kit which can screw up booting of Linux, BSD, Haiku, w.h.y....

[Sage]

Edit: Just to clarify for some...

Still missing the point! Thermal engineers only need apply?
How does that plethora of info enrich your experience?
What'ya gonna do about it?

If you're worried about thermal runaway - it's gonna be too late!

MacbookPro - poof, more wasted dosh. Apart for few posters, most folks here don't use them. Apple is just a money-making machine, always has been. Posers preference.

[stefan21]

While in fd800 it was possible to mount a luks partition via syslinux.cfg -

append rootfstype=ramfs savefile=ram:device:sdb2:/fd64save.ext4:dmcrypt waitdev=5

this does not work with fd801. While booting (from sdb1) no passphrase for sdb2 is asked. Do I overlook something?

Maybe a bug?

BTW: thank's a lot to jamesbond for packing unbound.

regards,
stefan

[SFR]

While in fd800 it was possible to mount a luks partition via syslinux.cfg -

append rootfstype=ramfs savefile=ram:device:sdb2:/fd64save.ext4:dmcrypt waitdev=5

this does not work with fd801. While booting (from sdb1) no passphrase for sdb2 is asked. Do I overlook something?

Maybe a bug?

BTW: thank's a lot to jamesbond for packing unbound.

regards,
stefan

I've never been using this feature before, but I just installed 801 on sda1 partition in VBox, encrypted sda2 partition, formatted it to ext4, created a savefile there and it asks me for password (see screenshot).

Can you access that partition manually?

Code: Select all

cryptsetup open /dev/sdb2 sdb2

801 contains an updated version of cryptsetup, so maybe that's the problem, however the new version opens my encrypted savefile created in 800 just fine...

Greetings!

[stefan21]

@SFR

Thank you for your reply.

Here's what I did:

Booted from an USB-Stick, dd'ed with the fd801 iso.

Followed your hint and did a cryptsetup open /dev/sdb2 sdb2. That worked.

Installed (again) from this USB-Stick on (now) sdc1 fd801. Changed in syslinux.cfg from

append rootfstype=ramfs savefile=ram:device:sdb2:/fd64save.ext4:dmcrypt waitdev=5

to

append rootfstype=ramfs waitdev=5 savefile=ram:device:sdb2:/fd64save.ext4:dmcrypt

Shut down the system and removed the dd'ed stick to boot with the new one. I don't know why, now the luks partition works.

After booting in fd801 the desktop is wiped, no icons at all... Well, this seems to be another problem, so the original problem is solved. Thank's for helping me out.

regards,
stefan

[stefan21]

Sorry to bother again, I couldn't find a solution to my problem in the forum.

I'm running fd801 in the way the posts before describe. The desktop is empty, no icons at all.

While trying to drag and drop i.e. libreoffice with rox on the desktop, it's simply not working.

Is there a way to restore the desktop to default?

regards,
stefan

[SFR]

Looks like ROX either isn't running or the pinboard is covered by the root window for some reason.
I think it could be the latter, because I've experienced something like this in 801 before, but only under JWM.

Anyway, you can (re)start ROX with:

Code: Select all

rox-desktop

This should help.

Greetings!

[stefan21]

Thank you for your reply.

Here's what happens (cli urxvt):

# rox-desktop
sh: rox-desktop: Kommando nicht gefunden. (command not found)

regards,
stefan

[stefan21]

Coming closer:

I removed in pwallpaper the background. Here we go, now it looks nearly like the default desktop. Except the drive icons. Still missing. We'll see if I can find them.

regards,
stefan

[stefan21]

No, after restarting "X", same look and behaviour as before...

[SFR]

# rox-desktop
sh: rox-desktop: Kommando nicht gefunden. (command not found)

That's odd. If you're running 800/801 this command must be there.
Anyway, let's do it differently:

Code: Select all

killall ROX-Filer
rox -p ~/.config/rox.sourceforge.net/ROX-Filer/PuppyPin

This should restart ROX.

Also, please check if it (the absence of ROX pinboard) happens without savefile (savefile=none) and with a newly created one.
I suspect there's something wrong your current savefile.

Greetings!

[stefan21]

This is how the fd800 desktop looks like:

The rox command works with a space... Meanwhile I found this out. But every restart of "X" turns the desktop back.

The savefile works in fd800. No problems at all.