Fatdog64-903 Final [17 Aug 2024]

versatile 64-bit multi-user Linux distribution

Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators

Clarity
Posts: 3833
Joined: Fri Jul 24, 2020 10:59 pm
Has thanked: 1632 times
Been thanked: 524 times

Re: Fatdog64-900 Final [12 Sep 2023]

Post by 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
PC used for FATDOG booint.png (88.73 KiB) Viewed 2943 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
Posts: 87
Joined: Sun Aug 23, 2020 6:48 am
Location: AU-TAS
Been thanked: 23 times

Long boot time

Post by 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! :x I will yet sort that out!
regards
proebler

fatdoguser
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Long boot time

Post by fatdoguser »

proebler wrote: Wed Oct 04, 2023 10:56 am

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
Posts: 688
Joined: Sat Nov 21, 2020 4:43 pm
Has thanked: 5 times
Been thanked: 117 times

Re: grub4dos menu.lst

Post by don570 »

don570 wrote: Wed Oct 04, 2023 5:23 pm

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
Posts: 87
Joined: Sun Aug 23, 2020 6:48 am
Location: AU-TAS
Been thanked: 23 times

Long boot time -SOLVED-

Post by 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
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Long boot time -SOLVED-

Post by fatdoguser »

proebler wrote: Sat Oct 07, 2023 12:16 pm

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

:thumbup2:
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
Posts: 87
Joined: Sun Aug 23, 2020 6:48 am
Location: AU-TAS
Been thanked: 23 times

musings

Post by proebler »

fatdoguser wrote: Sat Oct 07, 2023 3:32 pm
proebler wrote: Sat Oct 07, 2023 12:16 pm

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

:thumbup2:
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
Posts: 717
Joined: Tue Aug 11, 2020 3:02 pm
Location: The Pale Blue Dot
Has thanked: 124 times
Been thanked: 402 times

Re: musings

Post by jamesbond »

proebler wrote: Sun Oct 08, 2023 12:10 am

... 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
Posts: 87
Joined: Sun Aug 23, 2020 6:48 am
Location: AU-TAS
Been thanked: 23 times

musings

Post by proebler »

:idea: 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
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: musings

Post by fatdoguser »

proebler wrote: Sun Oct 08, 2023 9:31 am

:idea: 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
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: Fatdog64-900 Final [12 Sep 2023]

Post by 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
Posts: 87
Joined: Sun Aug 23, 2020 6:48 am
Location: AU-TAS
Been thanked: 23 times

musings

Post by proebler »

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

User avatar
fatdog
Posts: 39
Joined: Thu Sep 10, 2020 3:55 pm
Has thanked: 3 times
Been thanked: 31 times

Fatdog64-901 Final is Released

Post by fatdog »

Please see first post.

-= The Fatdog Team (kirk, jamesbond, SFR and step) =-
Contributed Packages: old | new
This account is used for announcements only. Send PM directly to members' handle.

fatdoguser
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by fatdoguser »

fatdog wrote: Tue Sep 12, 2023 1:58 am

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
Posts: 1
Joined: Sat Oct 07, 2023 7:58 pm

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: Fatdog64-901 Final [10 Oct 2023]

Post by step »

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

User avatar
Duprate
Posts: 309
Joined: Sat Aug 22, 2020 8:14 pm
Location: Southern Brazil
Has thanked: 163 times
Been thanked: 107 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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. :thumbup2:

Attachments
glibc_bug.jpg
glibc_bug.jpg (107.4 KiB) Viewed 2420 times
fatdoguser
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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 :thumbup2:
Image

fatdoguser
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by fatdoguser »

Image

Last edited by fatdoguser on Fri Oct 13, 2023 9:19 am, edited 1 time in total.
step
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by fatdoguser »

step wrote: Fri Oct 13, 2023 8:36 am

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
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: Fatdog64-901 Final [10 Oct 2023]

Post by step »

fatdoguser wrote: Fri Oct 13, 2023 9:24 am

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.

User avatar
dr__Dan
Posts: 83
Joined: Tue Jul 28, 2020 5:06 am
Has thanked: 52 times
Been thanked: 28 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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.

9 years on with Fatdog64. :D

step
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: Fatdog64-901 Final [10 Oct 2023]

Post by step »

@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
Posts: 446
Joined: Mon Jul 27, 2020 8:07 am
Been thanked: 45 times

Chinese language packs for Fatdog64-901 Final [10 Oct 2023]

Post by 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
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

crontab @reboot

Post by 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
Posts: 546
Joined: Thu Aug 13, 2020 9:55 am
Has thanked: 57 times
Been thanked: 198 times
Contact:

Re: crontab @reboot

Post by step »

fatdoguser wrote: Tue Oct 24, 2023 8:36 am

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
Posts: 176
Joined: Sat Aug 05, 2023 10:54 am
Has thanked: 22 times
Been thanked: 79 times

Re: crontab @reboot

Post by fatdoguser »

step wrote: Tue Oct 24, 2023 4:24 pm
fatdoguser wrote: Tue Oct 24, 2023 8:36 am

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
Posts: 3833
Joined: Fri Jul 24, 2020 10:59 pm
Has thanked: 1632 times
Been thanked: 524 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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
Posts: 688
Joined: Sat Nov 21, 2020 4:43 pm
Has thanked: 5 times
Been thanked: 117 times

Re: Fatdog64-901 Final [10 Oct 2023]

Post by 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

Post Reply

Return to “FatDog64”