Why does Fatdog not use my savefile? - Frequently Asked Questions -- Fatdog64 Linux

# Why does Fatdog not use my savefile?

Usually there are two reasons for that.

1. Fatdog cannot find the device on which the savefile is located.
2. Fatdog cannot find the savefile itself.

Problem #1 can have three potential causes.
A) The most common one is because the savefile is located in a "slow" device, like USB-connected drive (flash drive, portable harddisk, portable SSD ...). In this case, Fatdog boots so fast that when the device is finally ready for use, Fatdog has already completed its boot process and missed the device altogether.
The solution to this is simple, use the waitdev=n boot parameter to slow down Fatdog and tell it to wait a number of n seconds before continuing. Usually 3 or 5 seconds is enough for most devices. Slower devices may need more.
B) The driver for the device that contains the savefile is not built into the kernel, and you need to load its driver (=module) first; otherwise the kernel cannot see the device and hence it will never see the savefile on it.
The solution to this is to use the coldplug parameter, to force the kernel to load drivers for all supported devices. See a similar problem when your keyboard is not detected at boot time.
C) This is especially true for newer devices using SATA devices combined with Intel Optane technology. Many devices are configured with Intel Optane technology (=basically an on-board DRAM cache for harddisk) to "improve" their performance. In this mode, all access to the devices will have to go through a Storage Management Controller called Intel RST (Rapid Store Technology) and cannot be accessed directly.
Unfortunately Linux doesn't talk Intel RST protocols (except in very few exceptions) and thus cannot recognise the presence of the disk behind it. For Linux to be able to access the disk, you need configure your system to bypass Intel RST/Optane and access the disk directly.
This needs to be done in BIOS. The relevant setting is usually called "SATA Mode" or something like that; and the choices are usually "RST" and "AHCI". You don't want "RST", what you want is "AHCI" (Advanced Host Controller Interface - this is the standard SATA controller bypassing RST/Optane).
On some BIOSes, these settings are hidden and are only shown after pressing certain "secret" keys (different BIOSes have different secret keys).
BUT BEWARE!!! BEFORE YOU DO THIS, PLEASE READ ON!!!
If you have Windows on that disk, you don't want to do this without preparation. Apparently Windows is configured to boot from either RST, or AHCI, but not both. If you change the BIOS settings behind Windows' back, it will not be happy and will FAIL TO BOOT the next time you try to boot it.
So what's the proper way to tell Windows that you're about to change the SATA mode settings? The way is of course version specific, but here is the settings that I know work with Windows 8, 8.1, 10, and 11 (at time of writing, 2022), which may change in the future - so if you are from the future and are reading this, you may want to consult your favourite search engine for the updated details instead).
The steps are:

1. Boot to Windows.
2. Configure Windows to enter "Safe Mode" on the next boot (there are many ways to do this - using "msconfig", or other ways). Make sure you know how to do this and make sure that the way to enter "safe mode" works. In fact, you may want to test this one to make sure you can enter safe mode.
3. After that, you can go and enter BIOS settings, and change the SATA mode. Don't forget to save the BIOS settings after you change that.
4. Boot Windows. In "Safe Mode", Windows will be able to boot in either RST mode or in AHCI mode; and it will re-configure itself.
5. Then reboot Windows to leave "safe mode" and return back to Normal mode; to confirm that Windows works after the SATA mode change.

You can change between RST and AHCI and vice versa using the same method as above.

Note that (A), (B), (C) are not independent of each other and could (in theory) happen at the same time; so depending on your luck, you may have to try all of the solutions given above.
Problem #2 usually happens if you renamed the savefile and/or put the savefile in a sub-directory, when you created the savefile. It is important to know that by default, Fatdog only scans for savefiles in the top directory of devices, and then only looks for the default filename of the savefile (without the extension).
The default filename is fd64save.ext4, which means that Fatdog will only find savefiles named `fd64save.ext4`, `fd64save.3fs`, `fd64save-old.ext2`, `fd64save-backup.sfs`, etc. and only if they are located in the root directory.
It is possible to tell Fatdog to search deeper into sub-directories using the search boot parameter, but this is not recommended as searching is slow. The better way is to tell Fatdog exactly where your savefile is and what its name is, using the savefile boot parameter. Doing this stops Fatdog from doing any search at all, instead it will use the given device and given directory and given filename as its savefile. If this fails, it will simply boot without a savefile.
To make this easier, there is an applet in the Fatdog64 Control Panel > Install, named Savefile Argument Builder, that will walk you through the steps to set up the needed boot parameter correctly.

Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online

This page was automatically converted from no-savefile.html on 2024-12-09.