Fatdog64-710 Final [4 Dec 2016]

[mavrothal]

An installed package can be uninstalled from the command line with slapt --remove <packagename>, for instance slapt --remove yad-0.36.3-x86_64-1 removes yad.
Putting it all together, doinst.sh could be

Code: Select all

<snip>
( sleep 2; slapt-get --uninstall $THIS_PACKAGE ) &

This sample code is untested. If you find it useful, please let us know if it works for your case. Thank you.

I had some trouble running the remove command in a sub-shell, so I ended up with this doinst.sh which appears to work

Code: Select all

if [ "$(uname -r)" != "4.4.35" ]; then
	Xdialog --title "$(gettext 'Error')" --msgbox \
	"$(gettext 'This package is only for the 4.4.35 kernel. Will now uninstall it')" 0 0
	cat <<EOF>/tmp/removeFTpkg.sh
#!/bin/sh
sleep 10
slapt-get --remove -y facetimehd-0.1-x86_64-1
EOF
	chmod 755 /tmp/removeFTpkg.sh
	exec /tmp/removeFTpkg.sh &
	exit 1
else
	... 

Unrelated but still... Does the fbxkb package from the repo works for anyone?

[Keef]

@SFR

Drive icons working properly on a fresh boot and after making a new save directory. I had done a small number of updates previously, so I went through these again. The drive mount/unmount icons stopped working after I upgraded util-linux. We may have a culprit...

EDIT

Just to be sure, rebooted with savefile=none.
Set up networking, and used the Fatdog system updater to update util-linux.
Ext3 partition no longer showed as mounted when clicked.

[rcrsn51]

Drive icons working properly on a fresh boot and after making a new save directory.

This should ALWAYS be your first trouble-shooting step before reporting a problem.

[SFR]

The drive mount/unmount icons stopped working after I upgraded util-linux.

Ok, I can reproduce it now.
Fatdog, like other Pups, is using a wrapper script for mount/umount, so upgrading util-linux overwrote it (or rather symlinks to it) with binaries.
Where did you get it from, btw? Built by yourself? There's no newer version in the repo...
But, actually, even (re-)installing it from repo would break it in the same manner, as the wrapper is provided separately in fatdog-scripts package.

Anyway, if you don't want to start from scratch and this is the only breakage you've experienced, the fix would be:

Code: Select all

cd /bin
mv mount mount-FULL
mv umount umount-FULL
ln -s fatdog-mount-wrapper.sh mount
ln -s fatdog-mount-wrapper.sh umount

@Bpuppy & Dr. Dan: DO NOT apply the above code, unless you've also upgraded util-linux.

Greetings!

[bpuppy2]

Drive icons:
The patch did not fix it. Attached feedback of the patch.
Starting Fatdog w/o savefile works fine for the drive icons.
I did not update the util-linux package. The original is in place.

Calendar and bold font in menu [SOLVED]:
Thanks for the QT tweaks script. Like you say all i have to do is fiddle with it and analyze my GTK theme. Thanks.

As you see, the list is getting shorter
Great job guys!

@rcrsn51:
Great idea. I'll put that on top of my troubleshooting method next time.

[dr. Dan]

Watching and waiting. Of my three computers running Fatdog64, only one of them has the drive icon issue. While I can see that this is not a full solution, would re-installing fatdog-scripts solve the issue for me? (I'm not currently at that machine, but I'll try it later just for fun.)

Now for a more important issue. This laptop doesn't seem happy about saving to my save folder.
According to the properties option, fd64save = 1903M. It is set up as a save folder.
According to GParted: sda2 = 7.11GiB, Used = 6.72GiB, is boot partition, ext2 flash drive, mount points /aufs/devsave, /aufs/pup_save. sda1=7.91GiB, contains nearly all of my personal files other than e-mail data, fat32.
From Graphical Disk Map, devsave contains fd64save, /boot, one .sfs file, and a small number of other files. pup_save seems to contain everything in fd64save, but none of the rest. They are both 1.78GiB. pup_rw contains a copy of /root, which is also in fd64save and pup_save.
When my savefile is updated every 1/2 hour, it bogs down the system, then warns me that my savefile is full. Am I doing something wrong? Why is there so much duplication?
As always, I am grateful for the knowledge of the creators of FD64!!!

[Keef]

@SFR

As I mentioned above, I used the Fatdog system updater (via the Control Panel) to update util-linux. It is listed as an available update. Thing is, I don't usually bother with updates unless I know of a good reason. Anyway, I started from scratch again, and all is as it should be.

[SFR]

As I mentioned above, I used the Fatdog system updater (via the Control Panel) to update util-linux. It is listed as an available update. Thing is, I don't usually bother with updates unless I know of a good reason. Anyway, I started from scratch again, and all is as it should be.

Oh, I missed that edit, sorry.
So, effectively you just re-installed the same version of util-linux.
From what I see in fatdog-updater.sh it picks packages with newer date, not version.
And only these pkgs are excluded:

Code: Select all

EXCLUDES="^aaa-.*|^fatdog-scripts|^fatdog-bins|^glibc$|^xorg-server$"

I guess util-linux should be on that list, too.
___________

The patch did not fix it. Attached feedback of the patch.

Yes, it fails for me, too, if I copy/paste it from the forum - some thing with whitespaces most likely, adding '-l' switch to patch command fixes that.
I attached already patched script, though. Goes to /usr/sbin.

I did not update the util-linux package. The original is in place.

And what about using fatdog-updater?
To ensure, you can just check if /bin/mount and /bin/umount are symlinks (good) or binaries (wrong).
___________

While I can see that this is not a full solution, would re-installing fatdog-scripts solve the issue for me? (I'm not currently at that machine, but I'll try it later just for fun.)

Well, it could break the system in some unexpected ways. This package is blocked in Gslapt for a reason.

Now for a more important issue. This laptop doesn't seem happy about saving to my save folder.
According to the properties option, fd64save = 1903M. It is set up as a save folder.
According to GParted: sda2 = 7.11GiB, Used = 6.72GiB, is boot partition, ext2 flash drive, mount points /aufs/devsave, /aufs/pup_save. sda1=7.91GiB, contains nearly all of my personal files other than e-mail data, fat32.
From Graphical Disk Map, devsave contains fd64save, /boot, one .sfs file, and a small number of other files. pup_save seems to contain everything in fd64save, but none of the rest. They are both 1.78GiB. pup_rw contains a copy of /root, which is also in fd64save and pup_save.
When my savefile is updated every 1/2 hour, it bogs down the system, then warns me that my savefile is full. Am I doing something wrong? Why is there so much duplication?
As always, I am grateful for the knowledge of the creators of FD64!!!

pup_save is merely a mountpoint for fd64save.
pup_rw is a ram layer that keeps all the changes to root (/) filesystem, until saved.

Hard to tell what's going on here...
What if you execute snapmergepuppy from terminal? Any errors?

Greetings!

[rufwoof]

Dropped the iso into a VirtualBox and booted. Painfully slow to boot, perhaps a couple of minutes of dots before finally seeing a desktop (I know that's down to huge initrd, but other new users might not be patient enough and simply think something went wrong and reboot).

Added a VB HDD and ran the install program. Didn't work (had to recreate a GPT using gparted first). Re-ran the install program after creating GPT and formatting and it worked OK.

Clicked initrd to open it up, moved fd64.sfs to / and used the rebuild initrd script.

Rebooted .. to command prompt (tried xwin, startx ...etc after logging in as root using woofwoof password, but they didn't work either).

Removed from VirtualBox

Tried booting the iso using qemu-kvm .... with no luck



I've used FD in the past and found it to be very good. The off-put for me is no rolling releases - having to ditch prior versions and changes to have to reinstall afresh and try and remember how to re-do all of the changes made.

Haven't read the entire thread maybe this review has already been mentioned.

Sorry guys. I appreciate the effort involved and could just politely have remained quiet. Sometimes however critique can be a positive and that is my intent here (I'm most certainly not having a dig).

[step]

@mavrothal,

Thank you, I'm glad you got it working.

@rufwoof,

Your constructive feedback is most welcome. Giant initrd slow boot time issues periodically come up in Fatdog threads, and you are right, it can be slow. Fatdog is optimized for frugal install on a hard disk, which is considered the most common case. Booting is fast in that case, and packaging the giant initrd has some support benefits (we have historical evidence in Fatdog64 support threads from 2011-2012).

With the inception of cheap USB flash memory, more and more people frugal install Fatdog to USB keys. Unfortunately, some older computers load from USB with slow BIOS calls, so they take a long time to boot Fatdog's giant initrd. The only cure (besides getting a new computer) is to split initrd with fatdog-split-initrd.sh. Once this is done, booting from USB is fast. CD/DVD booting can also be slow, very slow. Both scenarios aren't considered the most common case, but perhaps we should acknowledge that USB flash memory is becoming more common.

Running fatdog.iso with qemu. Does the attached script work for you? It is taken from the Fatdog ISO builder. Delete the fake .gz extension. Put it in the same folder with fatdog.iso and execute it.

[SFR]

Dropped the iso into a VirtualBox and booted. Painfully slow to boot, perhaps a couple of minutes of dots before finally seeing a desktop (I know that's down to huge initrd, but other new users might not be patient enough and simply think something went wrong and reboot).

I'm unable to reproduce it...
Booting FD from ISO in VBox (also running in FD) with 1G of RAM takes less than 40s down here (Intel i3 @2.13 GHz, 4G RAM + 2G SWAP, VBox-5.0.32).
Booting in QEmu is somewhat slower, but it's still below 90s.
I even booted into my ancient Slacko-5.7 installation and it (FD in VBox) still loads in reasonable time...

Yes, it's a known issue that some BIOSes can't load the huge initrd at reasonable speed, but AFAIK (unless I'm wrong) VMs are emulating BIOS on their own, so this shouldn't be the case here.

Tried booting the iso using qemu-kvm .... with no luck

I'm using practically the same options and no probs.
Do you have another OS installed to try VBox/QEmu+FD on?

Added a VB HDD and ran the install program. Didn't work (had to recreate a GPT using gparted first). Re-ran the install program after creating GPT and formatting and it worked OK.

Didn't work how? Any errors popped up?
Btw, when you select a disk/partition on the first tab in Fatdog Installer, a button "Modify Partitions" appears on the right. It launches GParted for this specific disk.

Clicked initrd to open it up, moved fd64.sfs to / and used the rebuild initrd script.

Rebooted .. to command prompt (tried xwin, startx ...etc after logging in as root using woofwoof password, but they didn't work either).

From FAQ (the 'Help' icon on the pinboard), emphasized by me:

Or, if you only want to get a smaller version (not the smallest):
• Extract only the fd64.sfs by clicking on your installed initrd (this should open it up).
• Move fd64.sfs outside to a place accessible by the bootloader (perhaps the same location of vmlinuz and initrd itself)
• re-pack the initrd by clicking repack-initrd.sh..
• Please remember to use the basesfs parameter on your bootloader to tell Fatdog where to find the basesfs.

Did you use that boot param?
If so, could you post how exactly it looks like?

Haven't read the entire thread maybe this review has already been mentioned.

Yes, I've seen it. Some of the issues mentioned there are addressed in FAQ and some statements are simply not true (e.g. that FD is based on Slackware), but some look like real problems.

The thing about Fatdog is that - although there are many similarities - it's not a Puppy, so an average Puppy user (actually: any user) who's not yet familiar with FD, should really pay attention and carefully read all the stuff.
That comes from my own experience - before I read the docs I also had many issues, e.g. with not finding fd64.sfs, etc.
I'm not saying I haven't had problems that were genuine bugs, though.

Sorry guys. I appreciate the effort involved and could just politely have remained quiet. Sometimes however critique can be a positive and that is my intent here (I'm most certainly not having a dig).

Don't be sorry and don't be quiet. Every non-hostile and well-founded criticism is appreciated and helps.

Greetings!

[dr. Dan]

@SFR: 1- Thanks for the fatdog-scripts warning. Good weather had me doing other tasks yesterday, so my system is not broken.

2- snapmergepuppy gave me the following error:

Code: Select all

rsync: write failed on "/aufs/pup_save/root/.cache/thunderbird/fqpzau56.default/Cache/_CACHE_001_": Structure needs cleaning (117)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.1]

This is part of the shutdown procedure, right? Does it run at other times?

When I have composed my thoughts, I hope to comment about power options: A rough bit of this good system, and probably the cause of my current issue.

Thank you!

[SFR]

@SFR: 1- Thanks for the fatdog-scripts warning. Good weather had me doing other tasks yesterday, so my system is not broken.

2- snapmergepuppy gave me the following error:

Code: Select all

rsync: write failed on "/aufs/pup_save/root/.cache/thunderbird/fqpzau56.default/Cache/_CACHE_001_": Structure needs cleaning (117)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.1]

This is part of the shutdown procedure, right? Does it run at other times?

Snapmergepuppy saves the session. Well, technically it also runs at shutdown.
I think the partition on which your savefolder is needs a good fsck.
It's dofsck boot param.
If you have anything important on that disk, it's better to copy it to another disk before proceeding, just in case.

When I have composed my thoughts, I hope to comment about power options: A rough bit of this good system, and probably the cause of my current issue.

Do you mean some unexpected/hard shutdowns?
You could also check S.M.A.R.T. then:

Code: Select all

smartctl -A /dev/sda

for some reallocated sectors and other errors.

Greetings!

[rufwoof]

From FAQ (the 'Help' icon on the pinboard), emphasized by me:

Or, if you only want to get a smaller version (not the smallest):
• Extract only the fd64.sfs by clicking on your installed initrd (this should open it up).
• Move fd64.sfs outside to a place accessible by the bootloader (perhaps the same location of vmlinuz and initrd itself)
• re-pack the initrd by clicking repack-initrd.sh..
• Please remember to use the basesfs parameter on your bootloader to tell Fatdog where to find the basesfs.

Did you use that boot param?
If so, could you post how exactly it looks like?

Re-trying using basesfs=local and it was fine. Must have been a typo/mistake on my original path to fd64.sfs

I've taken both fd64.sfs and kernel-modules out of initrd and extracted both into the save folder and it now boots REALLY quick (obviously init/VBox doesn't need any of the modules on my kit). No fd64.sfs at all and a lean initrd (less than 5K filesize). That's the same sort of way I boot Debian Frugal ... everything is in the save partition and a empty filesystem.squashfs (equivalent to fd64.sfs).

I've applied all updates (except for upgrading the kernel as I've no idea if that is appropriate or not). With GuestAdditions installed its full-screening nicely on my 1280x720 TV monitor/sound is all good and its running very well



Thanks.

[bpuppy2]

@SFR
I applied the patch manually and the drive icons update when the drives are mounted but they don't update when i unmount them.

Also, i did a Fatdog update from the control panel. There were a lot of them (some 80M) but none for linux-utils. Mount and unmount are binaries and not links even after the update.

[SFR]

@Bpuppy2: Ok, since mount & umount are binaries, it's the same issue as Keef's and the same procedure should fix it.

Greetings!

[dr. Dan]

@SFR: I booted without savefile, used the graphical check disk option, and all seems well.

Part of my goal with using Fatdog64 is to be able to set up others, typically with limited technical skills and limited finances, to have an easy, effective, low-maintenance computer setup for older hardware. With that in mind, I use the command line somewhat, (stumbling along as I go) but prefer GUI options and solutions, and hope to eventually do a remaster with tweaks and preset options to get to that end. There may be a better base than Fatdog, but I like where I am, and hope to continue in this path. All that to explain what I am usually seeking when I post: simple and graphical for the former Windows user.

Thanks!

[bpuppy2]

@SFR

Mount/Unmount drive icons work perfectly now.
Thanks a lot!

All requested issues have been solved for now.

*hugs*
bpuppy

[bpuppy2]

I launched sandbox.sh to test some pet packages (32-bit) after loading the 32bit-fd64_710.sfs and i get this error message (see attached).

Note that i renamed the mount binary as mount-FULL and made the symlink as suggested above.

The only feedback given in the messages file is this one:
fatdog64-07a kern.err kernel: aufs opt_add:809:mount-FULL[6002]: lookup failed Error (-2)

bpuppy2
~~~~~~~~~~~~~~~~~~~
Fatdog 710|TahrPup 605|Ubuntu 14.04 LTS|Windows 8

[SFR]

@Bpuppy2:

It looks like an error in dialog's checklist statement; here's what I've retreived from your screenshot:
"Error: Expected at least 6 tokens for --checklist, have 4. Use --help to list options."
Probably the sandbox's code can't handle one of the mounted devices'/SFSes' name.

Could you post the output of:
1. cat /proc/mounts
2. losetup-FULL -a
3. ls -v /sys/fs/aufs/*/br[0-9]*
so maybe I'll be able to repro this error, however the portion of the code that handles it is written in awk and I'm not an expert...
___________

Regarding messed timestamps in messages file.
It's most likely due to /bin/busybox-logger being built using uClibc.
This should fix it, though:

0. Type:

Code: Select all

echo before > /dev/kmsg

The timestamp of this message in /var/log/messages should be off (UTC).

1. Go to /etc/init.d/ and edit 00sys_logger to make 'start_logger()' function look like this:

Code: Select all

start_logger() {
	# static uclibc syslogd/klogd only understands POSIX tz, convert
	export TZ=GMT$(date +%z | sed 'y/+-/-+/; s/.../&:/')
	mv /var/log/messages /var/log/messages.old 2> /dev/null
	syslogd -m 0
	klogd
}

2. Restart the service:

Code: Select all

service 00sys_logger restart

3. To check if there's any difference:

Code: Select all

echo after > /dev/kmsg

and see if the timestamp in /var/log/messages is correct now.

Greetings!