Fatdog64-710 Final [4 Dec 2016]
A few glitches to keep us busy...
Sorry for taking a long time to reply. I had to create a new account due to a messup in my password.
@step:
LS_COLORS [SOLVED]:
I removed the LS_COLORS... from the ~/.shinit file and created a ~/.fatdog/profile containing only the 'export LS_COLORS=...', saved and rebooted.
It works just fine now and it is persistent. Thank you.
@SFR:
Drive icons: i followed the steps mentioned and the mounted partition's icon is the plain one, w/o the green 'X' box in the left corner. I also tried the script you provided. See attached png. It then showed the icon with the green box but when i dismounted it, the icon did not refresh.
Bold Font everywhere [SOLVED]:
You have a keen eye SFR! You are right, the bold font shows up everywhere. I checked an option i had not used in a very long time:
Fatdog Control Panel > Desktop > GTK Theme Chooser > changed the font in the input field at the bottom of the form and all is well now! Thank you SFR for your insight!
obconf in terminal:
The onyx themes do not update. The others do as far as windows are concerned. The menu colors, taskbar and bold font in the menu never updates and neither does the calendar colors.
Time issue:
I did set all my puppies, ubuntu and windows to UTC time and now it works well in all OSes.
Some entries in the Messages file, still show a 4-hour difference even though they happened within a few minutes. Could syslogd be confused ?
Anyone else has this issue?
Could these wrong timestamps potentially create time critical issues... like crond missing my birthday? ... or maybe i shouldn't worry about these timestamps )
Calendar:
I have not changed the QT theme (calendar) as i would not even know how or where to look for it. It still has bad weekdays colors.
bpuppy2 (previously bpuppy)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fatdog 710|TahrPup 605|Ubuntu 14.04 LTS|Windows 8
@step:
LS_COLORS [SOLVED]:
I removed the LS_COLORS... from the ~/.shinit file and created a ~/.fatdog/profile containing only the 'export LS_COLORS=...', saved and rebooted.
It works just fine now and it is persistent. Thank you.
@SFR:
Drive icons: i followed the steps mentioned and the mounted partition's icon is the plain one, w/o the green 'X' box in the left corner. I also tried the script you provided. See attached png. It then showed the icon with the green box but when i dismounted it, the icon did not refresh.
Bold Font everywhere [SOLVED]:
You have a keen eye SFR! You are right, the bold font shows up everywhere. I checked an option i had not used in a very long time:
Fatdog Control Panel > Desktop > GTK Theme Chooser > changed the font in the input field at the bottom of the form and all is well now! Thank you SFR for your insight!
obconf in terminal:
The onyx themes do not update. The others do as far as windows are concerned. The menu colors, taskbar and bold font in the menu never updates and neither does the calendar colors.
Time issue:
I did set all my puppies, ubuntu and windows to UTC time and now it works well in all OSes.
Some entries in the Messages file, still show a 4-hour difference even though they happened within a few minutes. Could syslogd be confused ?
Anyone else has this issue?
Could these wrong timestamps potentially create time critical issues... like crond missing my birthday? ... or maybe i shouldn't worry about these timestamps )
Calendar:
I have not changed the QT theme (calendar) as i would not even know how or where to look for it. It still has bad weekdays colors.
bpuppy2 (previously bpuppy)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fatdog 710|TahrPup 605|Ubuntu 14.04 LTS|Windows 8
- Attachments
-
- fatdog-drive-icon-refresh-icon.png
- This is the debug info from running your script on /dev/sda10 while it is actually mounted.
- (32.46 KiB) Downloaded 108 times
-
- Shot-obconf.png
- Obconf launched from the terminal returns these error messages.
- (25.08 KiB) Downloaded 591 times
So this script works ok...bpuppy2 wrote:Drive icons: i followed the steps mentioned and the mounted partition's icon is the plain one, w/o the green 'X' box in the left corner. I also tried the script you provided. See attached png. It then showed the icon with the green box but when i dismounted it, the icon did not refresh.
Could you please also try the original version of it?
Code: Select all
/usr/sbin/fatdog-drive-icon-refresh-icon.sh /dev/sdXY
1. Save this as refresh_icons.patch:
Code: Select all
--- /aufs/pup_ro/usr/sbin/fatdog-drive-icon-mount-helper.sh 2016-12-03 15:43:19.000000000 +0100
+++ /usr/sbin/fatdog-drive-icon-mount-helper.sh 2017-04-21 13:37:11.790533638 +0200
@@ -75,6 +75,7 @@
esac; then
EXIT_CODE=$?
if [ $EXIT_CODE -eq 0 ]; then
+ fatdog-drive-icon-refresh-icon.sh "$1" # SFR: force refreshing for all filesystems, not only NTFS
if [ $(id -un) != $USER ]; then # change permissions if requester is not root
chgrp $ACCESS_GROUP "$2"
chmod $ACCESS_MODE "$2"
Code: Select all
patch /usr/sbin/fatdog-drive-icon-mount-helper.sh -i refresh_icons.patch
___________
First thing - all Onyx themes are almost identical.bpuppy2 wrote:obconf in terminal:
The onyx themes do not update. The others do as far as windows are concerned. The menu colors, taskbar and bold font in the menu never updates and neither does the calendar colors.
And second thing is that the menu that you can see on preview images in obconf is the one that shows when you right-click a window's titlebar (and also the applications menu when you right-click the desktop).
The applications menu on the panel is a part of LxQt-Panel, so Qt5 applies there, not GTK nor Openbox.
And all colors and stuff are defined in /usr/share/lxqt/themes/<current_theme>/lxqt-panel.qss.
___________
Hmm, just checked and some entries in my messages file are also few hours off. They're showing in UTC, to be exact.bpuppy2 wrote:Time issue:
I did set all my puppies, ubuntu and windows to UTC time and now it works well in all OSes.
Some entries in the Messages file, still show a 4-hour difference even though they happened within a few minutes. Could syslogd be confused ?
Anyone else has this issue?
Could these wrong timestamps potentially create time critical issues... like crond missing my birthday? ... or maybe i shouldn't worry about these timestamps )
I think I know what's the culprit here, but I need to consult with other guys.
___________
Customizing the looks of Qt5 apps is a PITA...bpuppy2 wrote:Calendar:
I have not changed the QT theme (calendar) as i would not even know how or where to look for it. It still has bad weekdays colors.
Anyway, I found this little app: https://sourceforge.net/projects/qt5ct/.
Just install the attached package and add:
Code: Select all
export QT_QPA_PLATFORMTHEME=qt5ct
Next: Menu -> Desktop -> Qt5 Settings and fiddle with fonts/styles; maybe this will help...
Greetings!
- Attachments
-
- qt5ct-0.31-x86_64-1.txz.gz
- Remoe fake .gz extension!
MD5: 10dd71eaa5545e2edbcb1eeb5f719f98 qt5ct-0.31-x86_64-1.txz - (157.25 KiB) Downloaded 111 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
@SFR
I tried the refresh_icons.patch, but no improvement.
or restarting X will change the mounted/unmounted icon, but nothing else.
I tried the refresh_icons.patch, but no improvement.
Code: Select all
/usr/sbin/fatdog-drive-icon-refresh-icon.sh /dev/sdXY
or restarting X will change the mounted/unmounted icon, but nothing else.
@Mavrothal,
You asked, how to make a package dependent on the kernel version? I assume that you mean how to make the installation of a package dependent on the kernel version. Slapt doesn't provide a way to find out the kernel version, so I think we need to proceed in a round-about way; installing, checking the version, and uninstalling if the version is incorrect.
uname -r or busybox uname -r outputs the running kernel version. This command can be placed in install/doinst.sh, which slapt runs after all package files are installed, and before the installation is finished. This is better explained in step 3 of http://distro.ibiblio.org/fatdog/web/faqs/pet-package.html (it's incorrect where it says that the package manager doesn't support an uninstall script like puninstall.sh - Fatdog64-710 does, but the script file name is slack-uninstall.sh).
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
This sample code is untested. If you find it useful, please let us know if it works for your case. Thank you.
You asked, how to make a package dependent on the kernel version? I assume that you mean how to make the installation of a package dependent on the kernel version. Slapt doesn't provide a way to find out the kernel version, so I think we need to proceed in a round-about way; installing, checking the version, and uninstalling if the version is incorrect.
uname -r or busybox uname -r outputs the running kernel version. This command can be placed in install/doinst.sh, which slapt runs after all package files are installed, and before the installation is finished. This is better explained in step 3 of http://distro.ibiblio.org/fatdog/web/faqs/pet-package.html (it's incorrect where it says that the package manager doesn't support an uninstall script like puninstall.sh - Fatdog64-710 does, but the script file name is slack-uninstall.sh).
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
THIS_PACKAGE=<name>-<version>-x86_64-1 # fill in <name> and <version>
MIN_VERSION_MAJOR=<X> # fill in <X> actual required value here
MIN_VERSION_MINOR=<Y> # ditto <Y>
MIN_VERSION_SUB=<Z> # ditto <Z>
x=`uname -r`
kversion=$x
kversion_major=${x%%.*} x=${x#*.}
kversion_minor=${x%%.*} kversion_rev=${x#*.}
if [ $kversion_major -ge $MIN_VERSION_MAJOR -a $kversion_minor -ge $MIN_VERSION_MINOR -a $kversion_sub -ge $MIN_VERSION_SUB ]; then
echo "package is installed for the right kernel version $kversion"
exit 0
fi
# Remove installation
echo "wrong kernel version $kversion, undoing installation..."
# Allow installation to complete, then uninistall.
( sleep 2; slapt-get --uninstall $THIS_PACKAGE ) &
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
@Keef & Bpuppy:
Dr. Dan mentioned that the drive icons were working ok, until some point.
Was it broken from the very beginning for you two or just like in Dr. Dan's case?
Also, is it reproducible on fresh boot (with pfix=ram) and with a new savefile/folder?
Greetings!
Dr. Dan mentioned that the drive icons were working ok, until some point.
Was it broken from the very beginning for you two or just like in Dr. Dan's case?
Also, is it reproducible on fresh boot (with pfix=ram) and with a new savefile/folder?
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
I had some trouble running the remove command in a sub-shell, so I ended up with this doinst.sh which appears to workstep wrote: 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 beThis sample code is untested. If you find it useful, please let us know if it works for your case. Thank you.Code: Select all
<snip> ( sleep 2; slapt-get --uninstall $THIS_PACKAGE ) &
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?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
@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.
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.
Ok, I can reproduce it now.Keef wrote:The drive mount/unmount icons stopped working after I upgraded util-linux.
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
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
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.
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.
- Attachments
-
- drive_patch.png
- (11.85 KiB) Downloaded 370 times
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!!!
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!!!
Oh, I missed that edit, sorry.Keef wrote: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.
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$"
___________
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.bpuppy2 wrote:The patch did not fix it. Attached feedback of the patch.
I attached already patched script, though. Goes to /usr/sbin.
And what about using fatdog-updater?bpuppy2 wrote:I did not update the util-linux package. The original is in place.
To ensure, you can just check if /bin/mount and /bin/umount are symlinks (good) or binaries (wrong).
___________
Well, it could break the system in some unexpected ways. This package is blocked in Gslapt for a reason.dr. Dan wrote: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.)
pup_save is merely a mountpoint for fd64save.dr. Dan wrote: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_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!
- Attachments
-
- fatdog-drive-icon-mount-helper.sh.tar.gz
- MD5: d73e6f8285353c27f0be4a60b65795e8 fatdog-drive-icon-mount-helper.sh.tar.gz
- (1.46 KiB) Downloaded 107 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
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).
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).
@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.
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.
- Attachments
-
- runiso.sh.gz
- (868 Bytes) Downloaded 88 times
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
I'm unable to reproduce it...rufwoof wrote: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).
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.
I'm using practically the same options and no probs.rufwoof wrote:Tried booting the iso using qemu-kvm .... with no luck
Do you have another OS installed to try VBox/QEmu+FD on?
Didn't work how? Any errors popped up?rufwoof wrote: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.
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.
From FAQ (the 'Help' icon on the pinboard), emphasized by me:rufwoof wrote: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).
Did you use that boot param?FAQ -> Humongous initrd wrote: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.
If so, could you post how exactly it looks like?
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.rufwoof wrote:Haven't read the entire thread maybe this review has already been mentioned.
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.
Don't be sorry and don't be quiet. Every non-hostile and well-founded criticism is appreciated and helps.rufwoof wrote: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).
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
@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:
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!
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]
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!
Snapmergepuppy saves the session. Well, technically it also runs at shutdown.dr. Dan wrote:@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:
This is part of the shutdown procedure, right? Does it run at other times?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]
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.
Do you mean some unexpected/hard shutdowns?dr. Dan wrote: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.
You could also check S.M.A.R.T. then:
Code: Select all
smartctl -A /dev/sda
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Re-trying using basesfs=local and it was fine. Must have been a typo/mistake on my original path to fd64.sfsSFR wrote:From FAQ (the 'Help' icon on the pinboard), emphasized by me:Did you use that boot param?FAQ -> Humongous initrd wrote: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.
If so, could you post how exactly it looks like?
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.
@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.
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.