Fatdog64-903 Final [17 Aug 2024]

[Clarity]

I've just booted both v814 and v900 via their ISO files to desktop: v900 beat v814 by 1 second even though v900's ISO file is larger (620MB vs 504MB). Repeating 3 times, average time is 45 seconds to boot a desktop Core2DUO PC.

PC used for FATDOG booint.png (88.73 KiB) Viewed 2923 times

This was done over the LAN with the simple instructions posted earlier of PXE ISO file booting.

In my final test, I instructed FD to use the save folder when booting savefile=ram:device:label:Persistence:/Sessions/Fatdog/ with no timing differences between the 2 versions.

@proebler could you be using different devices when booting?

[proebler]

Thank you step, don570 and Clarity.
Changing from grub4dos to Grub 2 has solved the problem with FD-900 boot delay.
Boot time to the login screen is now approx. 20sec.
Fast for this nearly 10 year old 'de-Chromed' Acer c720 chromebook with a newly installed 128 GB SSD and SeaBIOS.
It has only 2GB of RAM but zram seems to be working in FD.

However my BionicPup64 and LxPupSc64, which are on a separate (extended) partition, in separate sub directories, won't boot anymore.
Grub reporting that it does not find vmliuz.
Bugger! I will yet sort that out!
regards
proebler

[fatdoguser]

Running FatDog64-900 on a Intel(R) Celeron(R) 2955U @ 1.40GHz, I notice that boot time is approx. 1min 35sec and thus much longer than with FatDog64-813 . (approx. 40sec).
Boot times for BionicPup64 or LxPupSc64 on the same machine are very similar to that of FatDog64-813.
I am puzzled by this and wonder why with FatDog64-900 it is so slow.

Menu entry for grub4dos:
title FatDog-900 NEW INSTALL
uuid=3a4f57a9-44b0-4a75-9566-56e6f55dcdec
kernel /.900/vmlinuz savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900/fd64save_NEW.ext4
initrd /.900/initrd

regards
proebler

@proebler

copy initrd to hdd with reasonable free space and in that folder ...

Code: Select all

mkdir t
cd t
cat ../initrd | cpio -i
mv fd64.sfs ../fd64.sfs
find . | cpio -o -H newc >../initrd.new
cd ..
rm -rf t
mv /.900/initrd /.900/initrd.original
mv initrd.new /.900/initrd
mv fd64.sfs /.900/fd64.sfs

change your menu.lst to

Code: Select all

title FatDog-900 NEW INSTALL
uuid=3a4f57a9-44b0-4a75-9566-56e6f55dcdec
kernel /.900/vmlinuz basesfs=direct:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900/fd64.sfs savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900/fd64save_NEW.ext4
initrd /.900/initrd

You've moved fd64.sfs that is inside of initrd to outside and added a pointer to that in menu.lst (basesfs=....). That will boot a lot quicker, and use less memory. When booted programs will initially be a little slower to start, but once started once, will tend to remain cached and be quicker to start. For you that will be the quickest to boot, and use the least amount of ram, important on your 2GB limited system. To improve things further, make it quicker, reform the fd64.sfs using lz4 compression

Code: Select all

unsquashfs fd64.sfs
mv fd64.sfs fd64.sfs.original
mksquashfs squashfs-root fd64.sfs -comp lz4 -Xhc
rm -rf squashfs-root

[don570]

fatdog64 900 boots fast for my Dell 990 desktop
partition is formated ext4
frugal install
grub4dos menu.lst

Code: Select all

## start section Fatdog64-900
title Fatdog64 900 save file
find --set-root --ignore-floppies /fatdog900/vmlinuz
kernel /fatdog900/vmlinuz pfix=fsck psubdir=fatdog900  savefile=direct:device:sda3:/fatdog900save
initrd /fatdog900/initrd

__________________________________________________

[proebler]

I reverted from the unfamiliar Grub 2 back to grub4dos , thus I'm again able to boot Bionic64 and LxPupSc64 as well as FatDog .
I applied fatdoguser 's solution with success - or almost so.
The basesfs fd64.sfs was not found, it was missing from where it should have been.
I had previously manually, and also using the fatdog-split-initrd.sh , separated out fd64.sfs already.
But I did not realise that it had done all that was necessary, I was unsure in particular whether system-init had/or needed to be edited.
So after placing that fd64.sfs into the correct directory, everything worked. SUCCESS !

BTW I have found that grub4dos tolerates two versions of writing the kernel argument for "basesfs", both 'basesfs=..' and 'basefs=..' equally work.
Below are three different menu entries that work for me, using a simple savefile, a savefolder and an encrypted savefile.

Code: Select all

title FatDog-900_split-New-with-direct
 uuid=3a4f57a9-44b0-4a75-9566-56e6f55dcdec
 kernel /FD_split/vmlinuz basesfs=direct:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900/fd64save_NEW.ext4
 initrd /FD_split/initrd

Code: Select all

 title FatDog-900_split_savefolder
 uuid=3a4f57a9-44b0-4a75-9566-56e6f55dcdec
 kernel /FD_split/vmlinuz basefs=uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900_170923/fd64save dofsck
 initrd /FD_split/initrd

Code: Select all

  title FatDog-900_"auto-split"_savefile
 uuid=3a4f57a9-44b0-4a75-9566-56e6f55dcdec
 kernel /FD_split/vmlinuz basefs=local:/FD_split/fd64.sfs savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.900_170923/fd64save_dmcrypt_.ext4 dofsck
 initrd /FD_split/initrd

Booting is amazingly fast! No need to change the compression of fd64.sfs .
Before. with the original initrd , the delay happened when initrd got read/loaded at what seemed 8MB/sec; for 572MB that amounts to 71.5 sec.

@don570 , I did apply your suggested menu entry but it did not make any difference to the booting.

Thanks again for the help provided.
proebler

[fatdoguser]

Booting is amazingly fast! No need to change the compression of fd64.sfs

basesfs=direct ... means it remains on disk rather than basesfs=ram ... where its copied into ram. When on disk you'll get faster read speeds with a lz4 compressed fd64.sfs. On your SSD however the differences are likely small, just a bit less time for initial loading of programs (generally no difference once they've been cached).

[proebler]

Booting is amazingly fast! No need to change the compression of fd64.sfs

basesfs=direct ... means it remains on disk rather than basesfs=ram ... where its copied into ram. When on disk you'll get faster read speeds with a lz4 compressed fd64.sfs. On your SSD however the differences are likely small, just a bit less time for initial loading of programs (generally no difference once they've been cached).

... so, with each working equally well/fast:

Code: Select all

basesfs=direct:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs

basefs=uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs

basefs=local:/FD_split/fd64.sfs

does the basesfs remain on disk (i.e. the SSD) in each case and is then the SSD accessed/written-to (more) frequently rather than when basesfs=ram is used?
But in fact, the filesystem does NOT get decompressed and written to the disk - that would make a full install, not a frugal one .
.. so no, I think I have answered myself, it DOES all take place in ram.
How then is the magic of decompressing the filesystem to ram (which MUST happen) performed without being noticeable ?
Is somehow 'savefile=ram ...' responsible for that?

[jamesbond]

... so, with each working equally well/fast:

Code: Select all

basesfs=direct:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs

basefs=uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/FD_split/fd64.sfs

basefs=local:/FD_split/fd64.sfs

does the basesfs remain on disk (i.e. the SSD) in each case

Yes

and is then the SSD accessed/written-to (more) frequently rather than when basesfs=ram is used?

No, they're accessed just as often. It's only "read", never "written" as SFS is read-only.

But in fact, the filesystem does NOT get decompressed and written to the disk - that would make a full install, not a frugal one .

No, they are decompressed "on-the-fly", "on-demand", as needed. Nothing is ever written to disk.

.. so no, I think I have answered myself, it DOES all take place in ram.
How then is the magic of decompressing the filesystem to ram (which MUST happen) performed without being noticeable ?

Because you have an SSD. SSD is __fast__.

The filesystem is not decompressed to RAM wholesale. To do so, it will require a lot of RAM (uncompressed fd64.sfs takes more than 2.5 GB of space). The decompression is done "on-demand", as needed; and result is stored (temporarily) in the cache.

Is somehow 'savefile=ram ...' responsible for that?

No. savefile=ram only affects savefile; that is, when you're loading/saving your own personal data, not the applications contained in the basesfs.

[proebler]

Tanks to the Expert for explaining
One more thing:
With grub4dos I need to take the basesfs out of initrd, but when using Grub 2, it manages to boot fast with the large initrd.
Does Grub 2 do the separating out of fd64.sfs automatically in the background?

[fatdoguser]

Tanks to the Expert for explaining
One more thing:
With grub4dos I need to take the basesfs out of initrd, but when using Grub 2, it manages to boot fast with the large initrd.
Does Grub 2 do the separating out of fd64.sfs automatically in the background?

grub4dos is inclined to use slower BIOS firmware for reading the initrd whereas grub2 uses faster reads. With the fd64.sfs outside of initrd you significantly reduce the amount of slower BIOS firmware based reading. So no, grub2 isn't separating things in the background, just using a faster method of reads.

With fd64.sfs separated out you could use basesfs=ram: ... which will copy fd64.sfs into ram, which will then be used/accessed, on slower disks (CD/DVD/USB) that can be a appropriate choice, with your fast SSD and 2GB ram however it would be wasteful of ram space. To access a file the system will read in the block(s) that file is contained within, decompress each block into ram/cache. LZ4 compressed blocks will do that decompression quicker than gzip or xz compressed blocks.

[step]

@proebler it's basesfs not basefs. Fatdog only looks for "basesfs". The reason basefs appears to work in your case is just a coincidence.

[proebler]

@fatdoguser , @step , @jamesbond
Thank you for the comprehensive answers

[fatdog]

Please see first post.

[fatdoguser]

The Fatdog team is pleased to announce the release Fatdog64-901 Final.

This is a special release to address glibc bug CVE 2023-4911.

Wow! https://sysdig.com/blog/cve-2023-4911/

The Looney Tunables vulnerability is very serious due to how many Linux distributions are involved and the relative ease of exploitation.
.
.
Since there are currently not many ways to mitigate, patching the vulnerability should be a top priority. This vulnerability will affect not just your standard Linux server, but also containers, appliances, and IoT devices. Anywhere Linux is, this vulnerability may be present.

[gpgb23]

Buongiorno a tutti. Ho installato Fatdog64-900. Ottimo lavoro, complimenti a tutti gli sviluppatori.

Good morning everyone. I installed Fatdog64-900. Great work, congratulations to all the developers.

[step]

@gpgb23, on behalf of the Fatdog64 team, thank you for your feedback and welcome to the forum!

[Duprate]

Hello! Thanking the FatDog64 developer team for their quick intervention in fixing the glibc bug CVE 2023-4911, with the release of version 901.

[fatdoguser]

900 to 901 upgrade with existing save ... didn't seem to be working right.
Clean install and working very well. Installed nvidia specific driver (that requires kernel sources/devx to build) and that's running fine.
Installed a printer via the seamonkey web pages and a simple few clicks.
Thanks Fatdog team

[fatdoguser]

[step]

Thank you for posting this video review of Fatdog64 813. Spoiler: he doesn't recommend Fatdog64. Too bad he didn't review Fatdog64 901. I stopped watching after 3 minutes (the video is 11 minutes).

[fatdoguser]

Thank you for posting this video review of Fatdog64 813. Spoiler: he doesn't recommend Fatdog64. Too bad he didn't review Fatdog64 901. I stopped watching after 3 minutes (the video is 11 minutes).

I don't understand the language of that video, just saw the picture and the striking resemblance to the Fatdog logo and he seemed very enthusiastic so I posted both. As its not a 901 review I've edited the post to show just the picture.

[step]

I don't understand the language of that video, just saw the picture and the striking resemblance to the Fatdog logo and he seemed very enthusiastic so I posted both. As its not a 901 review I've edited the post to show just the picture.

I think it's fair to include unbiased reviews even if they aren't positive. I agree that this topic isn't the right one for the review of an old Fatdog64 version.

[dr__Dan]

Here are a few video reviews that are new:

https://www.youtube.com/watch?v=xNWJF2BbYHc,

https://www.youtube.com/watch?v=skf0PuEDb3w,

https://www.youtube.com/watch?v=hILKAaYWjgI.

Perhaps they are informative. They seemed positive to me, as far as I could tell.

As I was watching, it occurred to me that perhaps it would be more useful to label "Display Properties (Alternate)" in the Control Panel as the primary tool, with Zarfy listed as a more complete, (fuller, expert, or other similar verbiage) display setup tool. Just a thought.

Related, I recently connected a Fatdog64 laptop to a 4K monitor to evaluate it as a backup tool to display a presentation. Out of the box it worked very well, and another person was impressed with the ease and capability of presenting with Linux and LibreOffice.

[step]

Here are a few video reviews that are new:

https://www.youtube.com/watch?v=xNWJF2BbYHc,

https://www.youtube.com/watch?v=skf0PuEDb3w,

https://www.youtube.com/watch?v=hILKAaYWjgI.

@dr__Dan, thanks for the links. All three reviews are well done, I think.

I think the first link (review of Fatdog64 900) is well suited as a general introduction and walk-through for new Fatdog64 users and newish Linux users in general. It covers the default Xorg desktop, application menu and control panel. Spanish voice over, no music, 16 minutes.

The second link (review of Fatdog64 901) is suited for Linux regulars. The reviewer opens many windows with technical content so you need to understand what's going on. It covers from boot screen through shutdown, including desktop menu and applications. No voice over, all music, 13 minutes.

The third link (review of Fatdog64 900 beta) is by the same reviewer in the second link. No voice over, all music, 14 minutes.

I want to thank here the two reviewers for taking the time to look at Fatdog64 90x and publishing their videos.

[icake]

I. icake language txzes:
I have created 7 half-Chinese language txzes for fatdog64-901:
fcitx Chinese input platform: fcitx64_4.2.7-en-zh-bionic-321.0.6.txz (21 mb)
gcin Chinese input platform: gcin64_2.8.5-en-zh-bionic-321.0.6.txz (6 mb)
hime Chinese input platform: hime64_0.9.10-en-zh-bionic-321.0.6.txz (10 mb)
ibus Chinese input platform: ibus64_1.5.19-en-zh-bionic-321.0.6.txz (55 mb)
rime Chinese input platform: ibus64-rime_1.4.0-en-zh-bionic-321.0.6.txz (76 mb)
scim Chinese input platform: scim64_1.4.14-en-zh-bionic-321.0.6.txz (14 mb)
yong Chinese input platform: yong64_2.5.0-en-zh-bionic-321.0.6.txz (10 mb)

Plus 2 Chinese language txzes each for fatdog64-901:
Simplified Chinese: fatdog64-901-zhcn-321.0.6.txz (4 mb)

Traditional Chinese: fatdog64-901-zhcn-321.0.6.txz (3 mb)

To use:
(a) any 1 of the 7 half-Chinese language txzes will enable you to display and input Chinese in fatdog64-901

(b) the 2 name+version number corresponding Chinese language txzes will give you Simplified Chinese (zhcn) or Traditional Chinese (zhhk) menus, icon labels, tooltips for fatdog64-901. Please note that all Chinese language pets rely on a suitable half-Chinese language pet already installed to the system to provide Chinese input platform and Chinese fonts. Otherwise the system cannot input Chinese and display Chinese (shown as squares).

II. icake combo txz
I have also created an icake combo txz for fatdog64-901 with all 7 Chinese input platforms above and 3 user interface languages:
icake64-fatdog64-901-combo-est-fghirsy.321.0.6.txz (185 mb)

III. icake combo live iso
I have also remastered 1 icake combo live iso based on fatdog64-901 with all 7 Chinese input platforms above and 3 user interface languages:
icake64-Fatdog64-901-est-fghirsy.iso (854 mb)

so the total number of different systems created by the above icake combo txz and combo live iso is 21:
21 = 7 Chinese input platforms (fcitx, gcin, hime, ibus, rime, scim or yong) X 3 user interface languages (English, Simplified Chinese and Traditional Chinese)

more information about the fcitx, gcin, hime, ibus, scim and yong txzes, please see:
Documentation-and-Tools

[fatdoguser]

crontab -e
@reboot <user> <command>

Doesn't work. I believe because of using busybox crontab, but where that can be fixed: https://stackoverflow.com/questions/352 ... ybox-crond

[step]

crontab -e
@reboot <user> <command>

Doesn't work. I believe because of using busybox crontab [...]

@fatdoguser thank you. There are two alternative "full" cron packages in the repository, dcron and vixie-cron, for users who find busybox cron falling short of their needs. Note: we have not tested the alternative packages.

[fatdoguser]

crontab -e
@reboot <user> <command>

Doesn't work. I believe because of using busybox crontab [...]

@fatdoguser thank you. There are two alternative "full" cron packages in the repository, dcron and vixie-cron, for users who find busybox cron falling short of their needs. Note: we have not tested the alternative packages.

Thanks @step

dixie is indicated as being a lightweight version, vixie is the full version, as used in Debian I believe. Installed that and enabled it in Manage Services (disabled busybox cron) and for @reboot the syntax in crontab -e is just the @reboot followed by the full path to the script to run. Works OK.

Adding the same script to be run in /etc/rc.d/rc.local is a alternative if you just use root alone. When you have users then cron is a simple way for each user to have things being run/started after a reboot (when cron.d is started) rather than using a ~/Startup folder script that has to record/test whether its already been run.

[Clarity]

My PC has an nvidia adapter connecting it to the TV.
Questions

• How can I instruct the FD to use the nvidia support versus the VESA it is using?

• Or how do I migrate the pristine boot to nvidia for A-V use with the TV?

Found this built-in to the running FD v900.

Code: Select all

# find / -name nvid*
/etc/xdg/Startup/nvidia-workaround.sh
/lib/firmware/nvidia
/lib/modules/6.1.46/kernel/drivers/net/ethernet/nvidia
/lib/modules/6.1.46/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko
/usr/lib64/dri/nvidia_drv_video.so
/aufs/kernel-modules/lib/firmware/nvidia
/aufs/kernel-modules/lib/modules/6.1.46/kernel/drivers/net/ethernet/nvidia
/aufs/kernel-modules/lib/modules/6.1.46/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko
/aufs/pup_ro/etc/xdg/Startup/nvidia-workaround.sh
/aufs/pup_ro/usr/lib64/dri/nvidia_drv_video.so

Thanks in advance for any guidance.

P.S. On this old PC with the PCI nvidia adapter, is there a way to get the card to expose itself (make-model) without booting a Windows on the PC? Note: There is ONLY this card for video...nothing on the motherboard of the Intel PC.

[don570]

The oldest nvidia driver 1.0-5332 info says
http://download.nvidia.com/XFree86/Linux-x86_64/

TwinView, TV-Out and flat panel displays are also
supported.
_______________________________________
current driver info
http://download.nvidia.com/XFree86/Linu ... chips.html