Fatdog64-710 Final [4 Dec 2016]

[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!

[bpuppy2]

Greetings,

Timestamping of the system messages is showing my desktop clock time fine now. It makes it more realistic. Thanks.

I am posting the output here:

bpuppy2

[SFR]

Alright, thanks for confirmation!

Anyway, the output of ls -v /sys/fs/aufs/*/br[0-9]* turned out to be not enough. Can you post the output of:

Code: Select all

ls -v /sys/fs/aufs/*/br[0-9]* | xargs sed 's/=.*//'

Oh, and this time as a text, not a screenshot, if you could.

Thanks &
Greetings!

[rufwoof]

sda1 ext3 partition cleared except for menu.lst and grldr (grub4dos) bootloaders.

Installed FD by extracting the main sfs from initrd and extracting the main sfs to a savefolder (/fd64save). Dropped initrd (that excludes the main sfs) and vmlinuz into /boot

... booted, installed all outstanding updates and configured to UK locale/keyboard/timezone.

Changing the resolution had my monitor (I use a TV as a monitor) having to be readjusted each time (using the TV remote to Adjust Position). At FD startup it would frame/jig around ... and then just click to a incorrect position.

Running cvt and dropping the modeline into xorg.conf didn't help. Adding another xrandr command into Startup folder however did. It starts up off centre and then when that Startup file runs it correctly repositions the screen nicely.

Tried out skype sfs (figured out you also have to install the 32 bit sfs) and that's working well.

Using a grub4dos menu.lst of

title FatDog
find --set-root /menu.lst
kernel /boot/vmlinuz basesfs=none savefile=ram:device:sda1:/fd64save
initrd /boot/initrd

it boots nice and quickly.

[bpuppy2]

[quote="SFR"]
Anyway, the output of ls -v /sys/fs/aufs/*/br[0-9]* turned out to be not enough. Can you post the output of:

Code: Select all

ls -v /sys/fs/aufs/*/br[0-9]* | xargs sed 's/=.*//'

I get this, this time:

sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br0: No such file or directory
sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br1: No such file or directory
sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br2: No such file or directory
sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br3: No such file or directory
sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br4: No such file or directory
sed: can't read /sys/fs/aufs/si_ef4eb0245344c929/br5: No such file or directory

bpuppy2

[step]

@rufwoof, an unpacked basesfs as the saveforlder... it's a neat idea. Did you have a specific application in mind for this setup, or is it just for experimenting?

[step]

@bpuppy2, those sed errors are rather strange, they shouldn't happen. Did you run the command from inside sandbox.sh? If so, run it again outside sandbox.sh.
@SFR, line 104 should be: else if (mode == 4), though it doesn't matter, by chance.

[bpuppy2]

@step

The output comes from outside sandbox.sh already.

[rufwoof]

@rufwoof, an unpacked basesfs as the savefolder... it's a neat idea. Did you have a specific application in mind for this setup, or is it just for experimenting?

Its the way I usually prefer to run frugals Step. HDD space nowadays is extremely inexpensive. In the Debian based system I boot as a everyday the save partition is / and again the main sfs is empty ... which means it can also be booted as though a full install; Or be booted frugally without saving (useful for testing things out, or to be using a layered system so that sfs's can also be loaded).

Conceptually for FD if everything is in the save folder and fd64.sfs is empty/non existent as I currently have it setup, then I can make a sfs of that savefolder and reboot using that sfs ... without a 'savefile' as a no changes saved type session for testing things out (just shutdown and not save at the end of the session).

In Debian I run mostly as a restricted user session, so if a hacker breaks out of the browser they drop into a very limited user account (I went around and chmod most folders so that that userid can't get to see other folders/files such as personal documents). For documentation I just ctrl-alt-Fn and login as a normal user ... but don't use that account for any web stuff (kodi, skype, firefox ...etc). Most pup's are single user, FD is multi-user (can also ctrl-alt-F1 for instance and log in). However there's less need for that as FD isolates web programs anyway (run as spot). Another benefit of FD is that its like most other pup's ... already setup and ready to go. Debian is a headache to setup (and the group are nowhere near as friendly either, rather the complete opposite).

One of the best pup's around is FD. The main negative as I see it is not being a rolling release and having to re-setup all over again at each new release.

[step]

@bpuppy2, try this on a command line

Code: Select all

( . $BOOTSTATE_PATH ; ls -v /sys/fs/aufs/$AUFS_ROOT_ID/br[0-9]* | xargs sed 's/=.*//' )

And if you still get the sed error, that's the reason why dialog fails short of arguments. I'm writing this comment for SFR, when he will be able to take a look again.

[step]

@rufwoof, which pups are rolling, do you know? I don't.