Fatdog64-903 Final [17 Aug 2024]

[retiredt00]

Dear fatdog team
using fd901 full time I noticed that reconnecting to the network after suspend takes a rather long time (around 30 seconds in my i7 2,2 GHz, 16G ranm SSD laptop).
Looking at the (I think) relevant scripts, suspend.sh, network-setup.sh and 50-Wpagui, I was wondering if network settings could be saved before the suspend and try to reuse directly after wakeup and if user has moved to another place then go though the entire setup and discovery process.
Would you think that is possible?
Thank you

[jamesbond]

... network settings could be saved before the suspend and try to reuse directly after wakeup and if user has moved to another place then go though the entire setup and discovery process.
Would you think that is possible?

@retiredt00, unfortunately it is not possible. When you suspend, every device needs to be powered off; this includes the network adapter, or otherwise the machine won't suspend in the first place. That's why we have to disconnect, and then turn the wifi off; and re-do the entire discovery when you wake up.

By the way @step is our resident Mac export. Many of the Mac adaptations that goes into Fatdog came from him or improved by him (the original adaptation came from @mavrothal but he is now busy with other things). So you're talking to @step is the right ... well, step (pun intended)

[retiredt00]

... network settings could be saved before the suspend and try to reuse directly after wakeup and if user has moved to another place then go though the entire setup and discovery process.
Would you think that is possible?

@retiredt00, unfortunately it is not possible. When you suspend, every device needs to be powered off; this includes the network adapter, or otherwise the machine won't suspend in the first place. That's why we have to disconnect, and then turn the wifi off; and re-do the entire discovery when you wake up.

Dear jamesbond
I understand that everything must be powered off for suspend.
What I was wondering if the last good interface and access point can be saved to a file/mem and then just power up the specific interface and try to reconnect to the last access point directly without going through the entire rediscovery.
If this fails, then go through the standard longer routine.

Also, since we are on the subject, while I was looking around the wifi connection process I noticed that /etc/wpa_supplicant.conf shows all known access points and passwords in plane text. Is this appropriate ?

[fatdoguser]

while I was looking around the wifi connection process I noticed that /etc/wpa_supplicant.conf shows all known access points and passwords in plane text. Is this appropriate ?

That file is owned and the content only visible by root. Anyone who has root access can see that content, as can they see any other file/device on the system, meddle with your systems firmware, copy password or key files (such as .ssh/ssl private keys) to their own system to determine attack vectors at their leisure ...etc. In the scale of things from a compromised system perspective a wifi access SSID and password that requires being geographically close to the system ... is of relatively low interest. Of greater interest might be what could be modified in order to have persistent at-a-distance access to the device/system, firmware/whatever, which are equally visible by root.

From a stolen laptop (local) perspective then easier visibility of a LAN access is a issue, but so also are other elements such as files/cache contents. It's common for those who are at greater risk of the loss/theft of their laptop to use additional methods such as disk encryption.

/etc/wpa_supplicant.conf as-is, is fine ... relatively/generally speaking. But add additional security if you so prefer.

[jamesbond]

Dear jamesbond
I understand that everything must be powered off for suspend.
What I was wondering if the last good interface and access point can be saved to a file/mem and then just power up the specific interface and try to reconnect to the last access point directly without going through the entire rediscovery.
If this fails, then go through the standard longer routine.

Ah, okay. This is possible. You can modify suspend.sh to do exactly that - detect the connected wifi ("wpa_cli status"), then modify wpa_supplicant.conf to filter out all configure blocks except the currently connected (some scripting required with either bash or awk), after making a backup copy. When the computer returns from suspend, it waits for a while (say 1 minute) to see if the reconnection is successful (wpa_cli status again), and if not, restore the backup wpa_supplicant.conf and then re-start the entire wifi network stack ("service Wpagui restart"), otherwise leave it as is.
But I'm not sure that the speed of the re-connection will be faster even after doing all these.

Also, since we are on the subject, while I was looking around the wifi connection process I noticed that /etc/wpa_supplicant.conf shows all known access points and passwords in plane text. Is this appropriate ?

@fatdoguser has given an excellent answer. I just want to add two things:
1. You can use wpa_passphrase to create an hashed version of the wifi password, (and manually edit wpa_supplicant to replace the plaintext password with its hashed version), HOWEVER,
2. In terms of actual security it doesn't matter, because the hashed password works as good as the plaintext password. Somebody who steals the hashed password can use it connect to your wifi network directly without having to decrypt it at all.

[wognath]

Hello,
I'm trying out FD 901 in a vm. It looks fantastic, congratulations and thanks!
I think I found a bug: in the primer for puppy users, it says to press window key and g to see Spot's home, so I tried it. It set off a "fork bomb" and the vm had to be shut down. I checked, I don't have a stuck key.

[fatdoguser]

Hello,
I'm trying out FD 901 in a vm. It looks fantastic, congratulations and thanks!
I think I found a bug: in the primer for puppy users, it says to press window key and g to see Spot's home, so I tried it. It set off a "fork bomb" and the vm had to be shut down. I checked, I don't have a stuck key.

Hi @wognath When I right click the Sven Multimedia Keyboard tray icon in Fatdog (Openbox) and select Preferences, the Keyboard category indicates that WIN+g triggers open-spot-home. When I run

Code: Select all

which open-spot-home

in a terminal it indicates /usr/bin/open-spot-home Looking at the content of that script I don't see any fork-bomb content. There's perhaps a conflict with your vm keyboard layout/setup. a.k.a. not a Fatdog issue, something else.

[wognath]

Hi fatdoguser, thanks for the reply. You're probably right that it's a peculiarity of my vm, but I thought I should let you know about it. In FD901 vm, if I run "open-spot-home" from a terminal, it works as expected. Win-g works as expected in FD901 when booted from a flash drive, and in a FD721 vm. --??--

[fatdoguser]

What vm are you using? The documentation for that might indicate a conflict. The other obvious option is to redefine the Fatdog choice of Sven Win+G key combination to another choice.

[retiredt00]

Dear fatdog team
Apologies for bothering you again with my little issues
It turns out that suspend on lid closure is not really working on my macbook
The screen light is off but is not geting into deep sleep.
I noticed because the battery is draining, some times precipitously.

I looked at the kernel messages (bellow) and indeed it is not suspending.
It actually wakes up immediately, though is not clear to me why.

Any suggestions on how to determine where the problem might be is very welcome
Thank you.

Code: Select all

[  160.564991] PM: suspend entry (deep)
[  160.579777] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  160.609679] Filesystems sync: 0.044 seconds
[  160.610671] Freezing user space processes
[  160.612095] Freezing user space processes completed (elapsed 0.001 seconds)
[  160.612104] OOM killer disabled.
[  160.612106] Freezing remaining freezable tasks
[  160.613287] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[  160.613355] printk: Suspending console(s) (use no_console_suspend to debug)
[  160.621469] ERROR @wl_notify_scan_status : 
[  160.621476] wlan0 Scan_results error (-22)
[  160.622621] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  161.199193] sd 0:0:0:0: [sda] Stopping disk
[  161.216685] ACPI: EC: interrupt blocked
[  162.185698] ACPI: PM: Preparing to enter system sleep state S3
[  162.186648] ACPI: EC: event blocked
[  162.186650] ACPI: EC: EC stopped
[  162.186652] ACPI: PM: Saving platform NVS memory
[  162.186724] Disabling non-boot CPUs ...
[  162.207669] smpboot: CPU 1 is now offline
[  162.209729] smpboot: CPU 2 is now offline
[  162.230578] smpboot: CPU 3 is now offline
[  162.251487] smpboot: CPU 4 is now offline
[  162.272304] smpboot: CPU 5 is now offline
[  162.274474] smpboot: CPU 6 is now offline
[  162.276727] smpboot: CPU 7 is now offline
[  162.277837] ACPI: PM: Low-level resume complete
[  162.277867] ACPI: EC: EC started
[  162.277868] ACPI: PM: Restoring platform NVS memory
[  162.278252] Enabling non-boot CPUs ...
[  162.278309] x86: Booting SMP configuration:
[  162.278310] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  162.375475] CPU1 is up
[  162.378529] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  162.466277] CPU2 is up
[  162.470344] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  162.552253] CPU3 is up
[  162.555171] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  162.561806] CPU4 is up
[  162.561822] smpboot: Booting Node 0 Processor 5 APIC 0x3
[  162.582751] CPU5 is up
[  162.582873] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  162.607039] CPU6 is up
[  162.607178] smpboot: Booting Node 0 Processor 7 APIC 0x7
[  162.638305] CPU7 is up
[  162.640589] ACPI: PM: Waking up from system sleep state S3
[  162.642080] ACPI: EC: interrupt unblocked
[  162.715587] ACPI: EC: event unblocked
[  162.727693] sd 0:0:0:0: [sda] Starting disk
[  163.033316] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  163.033636] ata1.00: unexpected _GTF length (8)
[  163.034162] ata1.00: unexpected _GTF length (8)
[  163.034338] ata1.00: configured for UDMA/133
[  163.305227] OOM killer enabled.
[  163.305230] Restarting tasks ... 
[  163.305342] usb 2-4: USB disconnect, device number 2
[  163.305859] done.
[  164.782633] Bluetooth: hci0: Opcode 0x c01 failed: -4
[  164.782669] video LNXVIDEO:00: Restoring backlight state
[  164.783037] PM: suspend exit
[  166.786629] usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
[  170.842635] usb usb2-port4: Cannot enable. Maybe the USB cable is bad?

[wognath]

@fatdoguser I'm using VirtualBox 7.0.14-2, booting Fatdog from the iso. I don't find any vbox shortcuts using the win key. In the vm, win- e, t, k and s work normally but win-g locks it up every time. I should add that my computer locked up requiring a hard restart while doing other things in the FD virtual machine (only once, and I don't remember what I was doing at the time). I agree it must be some obscure interaction between vbox and fatdog. Have there been other reports of this? I'd hate for people trying out Fatdog in a vm to be scared off!

[dr__Dan]

@retiredt00, what does the log show if you suspend from terminal, or using the menu buttons?

Dan

[retiredt00]

@retiredt00, what does the log show if you suspend from terminal, or using the menu buttons?

Dear dr__Dan
as shown below goes to suspension (black screen, no network) and then wakes up immediately
Maybe I should increase kernel log level?

Code: Select all

# /etc/acpi/actions/suspend.sh 
dhcpcd-wpagui: no process found
50-Wpagui - loading wpa_supplicant for wlan0
Successfully initialized wpa_supplicant
no such user dhcpcd
# 
# dmesg
[ 5720.374664] PM: suspend entry (deep)
[ 5721.099894] Filesystems sync: 0.725 seconds
[ 5721.100889] Freezing user space processes
[ 5721.101907] Freezing user space processes completed (elapsed 0.001 seconds)
[ 5721.101916] OOM killer disabled.
[ 5721.101918] Freezing remaining freezable tasks
[ 5721.102940] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 5721.103018] printk: Suspending console(s) (use no_console_suspend to debug)
[ 5721.116014] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 5721.738385] sd 0:0:0:0: [sda] Stopping disk
[ 5721.756030] ACPI: EC: interrupt blocked
[ 5722.685983] ACPI: PM: Preparing to enter system sleep state S3
[ 5722.686887] ACPI: EC: event blocked
[ 5722.686890] ACPI: EC: EC stopped
[ 5722.686892] ACPI: PM: Saving platform NVS memory
[ 5722.686957] Disabling non-boot CPUs ...
[ 5722.688617] smpboot: CPU 1 is now offline
[ 5722.709512] smpboot: CPU 2 is now offline
[ 5722.729849] smpboot: CPU 3 is now offline
[ 5722.750878] smpboot: CPU 4 is now offline
[ 5722.772457] smpboot: CPU 5 is now offline
[ 5722.775541] smpboot: CPU 6 is now offline
[ 5722.777572] smpboot: CPU 7 is now offline
[ 5722.779180] ACPI: PM: Low-level resume complete
[ 5722.779208] ACPI: EC: EC started
[ 5722.779209] ACPI: PM: Restoring platform NVS memory
[ 5722.779587] Enabling non-boot CPUs ...
[ 5722.779648] x86: Booting SMP configuration:
[ 5722.779649] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 5722.875566] CPU1 is up
[ 5722.878579] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 5722.964314] CPU2 is up
[ 5722.967657] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 5723.048216] CPU3 is up
[ 5723.051418] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 5723.058529] CPU4 is up
[ 5723.058546] smpboot: Booting Node 0 Processor 5 APIC 0x3
[ 5723.079214] CPU5 is up
[ 5723.079339] smpboot: Booting Node 0 Processor 6 APIC 0x5
[ 5723.103479] CPU6 is up
[ 5723.103620] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 5723.133439] CPU7 is up
[ 5723.135515] ACPI: PM: Waking up from system sleep state S3
[ 5723.136776] ACPI: EC: interrupt unblocked
[ 5723.215847] ACPI: EC: event unblocked
[ 5723.227089] sd 0:0:0:0: [sda] Starting disk
[ 5723.533498] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 5723.533849] ata1.00: unexpected _GTF length (8)
[ 5723.534413] ata1.00: unexpected _GTF length (8)
[ 5723.534590] ata1.00: configured for UDMA/133
[ 5723.654346] OOM killer enabled.
[ 5723.654347] Restarting tasks ... done.
[ 5724.123964] Bluetooth: hci0: Opcode 0x c01 failed: -4
[ 5724.124022] video LNXVIDEO:00: Restoring backlight state
[ 5724.124291] PM: suspend exit
# 

[dr__Dan]

@retiredt00, Hello again,

This is just a guess, but I wonder if there is a setting in the BIOS forcing it to wake up immediately. I've no experience on a Macbook. @step may see this and chime in. It runs through the process essentially the same as my laptop.

Dan

[jamesbond]

This looks similar to your problem and the solution given in the first response might help.

https://askubuntu.com/questions/1395148 ... er-suspend

[retiredt00]

Dear jamesbond
Thank you for looking into it.
Interesting thread
Unfortunately even with all wakeup devices disabled the behavior is not changing.
The system still wakes up immediately.
I should just power off more often.

[step]

@retiredt00, I'm late to the party, and I don't have anything to say to help! I've never been able to successfully suspend my macbook 2012 (what year is yours, BTW) so I gave up trying.

[retiredt00]

@retiredt00, I'm late to the party, and I don't have anything to say to help! I've never been able to successfully suspend my macbook 2012 (what year is yours, BTW) so I gave up trying.

Dear step thank you for the information.
I think is a general linux issue, as not only puppies/FD but also other linux distributions fail to suspend this machine.
Is a MacBook Pro retina 15", mid 2014.

[don570]

I installed fatdog64 901 on refurbished HP elite desktop 800

I used LICK successfully - lick menu can be used

I also installed other linux version such as EASYOS using legacy boot
which is possible with HP BIOS

I used grub4dos from the fatdog control panel
I selected another Hard disk and installed MBR.
A menu.lst was generated but needed a lot of modification to boot EasyOS

If a backup version of previous menu.lst had been created , it would have helped.
Other Shinobar versions of grub4dos do create backup versions.

[fatdoguser]

I installed fatdog64 901 on refurbished HP elite desktop 800

I used LICK successfully - lick menu can be used

I also installed other linux version such as EASYOS using legacy boot
which is possible with HP BIOS

I used grub4dos from the fatdog control panel
I selected another Hard disk and installed MBR.
A menu.lst was generated but needed a lot of modification to boot EasyOS

If a backup version of previous menu.lst had been created , it would have helped.
Other Shinobar versions of grub4dos do create backup versions.

Hi @don570

You may have already been aware, I wasn't, of the usb-boot folder within the Fatdog iso, that contains a gz file ... within which there are two boot images (.img files). Both seem to contain images that use a chain loading style of boot, where the first layer is a UEFI style, so pretty much can boot on BIOS or UEFI systems. I opted to use the MBR image choice to burn to a usb stick. Once that's dd'd to a usb stick (the actual device such as /dev/sdb, not the partition (/dev/sdb1) - of course taking great care to make sure you specify the actual usb device (dd = device destroyer ) then you can use gparted to resize the second partition (don't change anything in the first partition). Then copy vmlinuz and initrd into that second partition (I prefer to extract fd64.sfs out of the initrd so in my case three files vmlinuz, initrd, fd64.sfs)) and its good to go.

I modified the grub.conf file so that the first/default booted choice (start of grub.conf) looks like

Code: Select all

#insmod png
#background_image /fatdog.png
set timeout=10

loadfont /terminus24.pf2
terminal_output console
terminal_output gfxterm

menuentry "Fatdog64 with multisave sfs in USB device" {
	echo "Copying initrd into ram, please be patient ..."
	linux /vmlinuz rootfstype=ramfs waitdev=5 basesfs=ram:label:OS:/fd64.sfs savefile=direct:multi:label:OS:/
	initrd /initrd
	echo Booting ...
}

which boots Fatdog multisession style. Within Fatdog change the Event Manager to a save interval of 0 (only ever saves whenever the desktop 'save session' icon is clicked) and it creates the additional multisession save sfs in the USB each time a save is made. That minimises writes to the usb stick (prolongs its life), and works well. Once configured I mostly just boot/use/shutdown without saving, keep all data files outside of fatdog. If/when many multi-session files have been accumulated (many saves made), you can boot, delete all of the multi-session save files and then run a 'save session' and that consolidates them all back down to just two (base and save sfs's).

That's with everything copied into and run from ram, which is fine when you have loads of ram. As I'm limited to 4GB I also created a swap file on the HDD, dd'd a 20GB /mnt/sda2/swapfile.crypt file and added some code to /etc/rc.local to use that as encrypted swap

Code: Select all

   for drive in sda2 sdb2; do
	mkdir /mnt/$drive
	mount /dev/$drive /mnt/$drive
	RC=$?
	if [ -f /mnt/$drive/swapfile.crypt ]; then
		cd /mnt/$drive
		loop=$(losetup -f)
		losetup ${loop} swapfile.crypt
		cryptsetup open --type plain --key-file /dev/urandom ${loop} swapfile
		mkswap /dev/mapper/swapfile
		swapon /dev/mapper/swapfile
		sync
		# My swap partition is 20GB, so I resize pup_save and tmp to match that
                mount -o remount,size=20G /aufs/pup_save                        

		mount -o remount,size=20G /aufs/pup_multi                       

                mount -o remount,size=20G /tmp                                  

                mount -o remount,size=20G /dev/shm
		break
	else 
	   if [ $RC -eq 0 ]; then
		   umount /mnt/$drive
	   fi
     fi
   done

Note that captures that sometimes linux will assign my HDD sda and usb sdb, other times that's reversed, random.

So even if I copy in 10GB of data into /root folder, my 4GB system still continues to run. The slow down from when swap does kick in is .. acceptable (noticeable but not too laggy that you're inclined to press-hold the power button).

As for grub not automatically making a backup - that should be a automatic manual action First question always ... "you did make a backup"

[don570]

Thanks for info
My only experience of booting with a USB stick I have is when I
was able to boot my Dell Chromebook laptop.
I used the help of mrchromebox modification.

Mrchromebox modifies the bios and provides a bootloader as well.

I believe that to boot fatdog64 I had to navigate some folders
probably to get to grub.conf file. Then the booting went normally
to fatdog desktop. I couldn't get the sound to work unfortunately.

https://mrchromebox.tech/

[fatdoguser]

/etc/wpa_supplicant.conf starts off with just root having read access, but after using the systray network icon to open, scan and connect to a ssid the permissions change to readable by all (whilst including all ssid and passwords in clear text).

Expected the file permissions to remain unchanged rather than being opened up to all.

I note from archlinux https://wiki.archlinux.org/title/Wpa_supplicant

Connecting with wpa_cli

This connection method allows scanning for available networks, making use of wpa_cli, a command line tool which can be used to configure wpa_supplicant. See wpa_cli(8) for details.

In order to use wpa_cli, a control interface must be specified for wpa_supplicant, and it must be given the rights to update the configuration. Do this by creating a minimal configuration file:

/etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/run/wpa_supplicant
update_config=1

Warning: Setting update_config to 1 allows wpa_supplicant to overwrite the configuration file. When overwriting, wpa_supplicant will reset file permissions according to your default umask. It might accidentally make the file readable to everyone thus exposing your passwords, if your system is multiuser.

and the Fatdog default wpa_supplicant.conf has update_config=1

[step]

@fatdoguser Thank you. This will be fixed. In the meantime, everyone concerned can chmod 600 /etc/wpa_supplicant.conf after adding or removing wifi networks via the systray network icon (Network Tool) and the wpa_cli command.

[fatdoguser]

@fatdoguser Thank you. This will be fixed. In the meantime, everyone concerned can chmod 600 /etc/wpa_supplicant.conf after adding or removing wifi networks via the systray network icon (Network Tool) and the wpa_cli command.

I think this works @step

Code: Select all

mv /usr/sbin/wpa_cli /usr/sbin/wpa_cli.bin
cat > /usr/sbin/wpa_cli <<EOF
#!/bin/sh
/usr/sbin/wpa_cli.bin $@ 
chmod 0600 /etc/wpa_supplicant.conf
EOF
chmod +x /usr/sbin/wpa_cli

Thereafter, after wifi net connecting, entering a browser (run as spot) url of

Code: Select all

file:///etc/wpa_supplicant.conf.sample

and the content likely shows, whereas entering

Code: Select all

file:///etc/wpa_supplicant.conf

should fail.

[fatdoguser]

In control panel, install, updater ... I'm seeing 71 entries

Is there a way to identify which are important updates such as security fixes? Or does the ibiblio version of Fatdog 901 get updated to include such fixes/updates that might be downloaded to replace the current installed version of initrd/fd64.sfs?

I did try a trial run of installing all 71 listed entries (in one go ... all ticked), but that failed.

[step]

@jamesbond can be more specific than me. First of all, the updater only updates packages installed in your system. It doesn't pull new packages, that is, new stuff that you have never installed into the system. Then the two labels "(REBUILD)" and "(UPDATE)" refer to the remote package. Sometimes we rebuild a package without updating the version number; that's "(REBUILD)". Other times we rebuild and update the version number, typically because the package received an upstream update; that's "(UPDATE)". In any case, the updater will list all (already-installed) packages that can be updated, then it leaves the choice of which packages to update to the user. As usual, packages may affect each other, so there is no guarantee that a blind, bulk update will succeed. That's unfortunate, but it the current state of affairs with Fatdog (Gslapt) package management.

Is there a way to identify which are important updates such as security fixes?

I don't believe there is. In 720 we used to place a Changelog.txt file in the online repository but we stopped doing so in 800.

Does the ibiblio version of Fatdog 901 get updated to include such fixes/updates that might be downloaded to replace the current installed version of initrd/fd64.sfs?

No. We update the ISO when we release a new version. Fatdog64 isn't a rolling release.

I did try a trial run of installing all 71 listed entries (in one go ... all ticked), but that failed.

Thank you for testing.

[fatdoguser]

Toying with fd64.sfs compression and I sliced the content into two parts, one with more binary content, the other with more text (scripts, configs ...etc.) content. Using mksquashfs high compression applied separately to each of those and the sum of the two was smaller than the bulk standard fd64.sfs. Initially I thought that clustering similar file types seemed to have improved overall compression. However when I re-ran mksquashfs on the whole/total fd64.sfs content using the same xz high compression settings as I used to build both of those individual sfs's and that produced a single sfs of around the same size as the two separates. So my conjecture proved wrong.

A point however is that the mksquashfs settings I used did produce a slightly smaller fd64.sfs.

mksquashfs squashfs-root fd64.sfs -b 1048576 -comp xz -Xdict-size 100% -noappend

As-is fd64.sfs = 456MB, formed with the above and = 436MB

Small 20MB difference, perhaps trivial in the present age, but every little bit might help.

[Clarity]

Nvidia cards in FD901

The drivers for these cards is a source of much discussion over the past 6 months on the PLDF forums.

For @fatdog, this user, @Gobbi, reports an approach here

Is there a chance that FD has a utility where it will guide to this conclusion? ... where it request/downloads the devx and kernel-headers, places the run file and move to instruct reboot? This may not be a reasonable request, but, maybe it is.

For years nvidia and linux has been 'supposedly' coming up with a built-in solution, as I am now old and grey, I dont hold for much hope anytime soon. So we must rely of the forum solutions that ease the pain.

Curious

[step]

[...]
For @fatdog, this user, @Gobbi, reports an approach here

Is there a chance that FD has a utility where it will guide to this conclusion?

Currently there is no such utility. Have you tried Gobbi's approach?

[fatdoguser]

@Clarity As I recall it was simple enough. Went to the nvidia web site, downloaded a install program/script for my particular card/version, and with the fatdog kernel sources and devx loaded that all ran through/installed OK, unloaded the kernel sources and devx sfs's so they weren't stored in the subsequent 'save'.

I do similar with chrome. Installed once using Fatdog control panel, turned that into a sfs, subsequently just download the .deb from chrome for later versions, extract that and replace the /opt/google/chrome folder in the sfs with the one in the extracted .deb set.

I would do the same with the kernel, get it direct from kernel.org etc. however fatdog requires the additional aufs patches so that doesn't work unless you also apply such patches or accept using overlayfs rather than aufs (as I don't tend to dynamically load/unload sfs's that's OK with me). Being able to refine the kernel compile to exclude firmware/modules your hardware doesn't require however only saves relatively little space in present day typical available ram, not really worth the bother. As-is and < 100MB is typically 'small' nowadays (checking /aufs/kernel-modules folder properties as I write this and mine indicates 98MB).