Savefile Not Recognized After Replacing Kernel

[m1k3]

I may be missing something basic but, after replacing vmlinuz and the kernel modules, my savefile is no longer recognized on the USB stick. I followed the instructions (preferred method) and replaced the original kernel and modules with 5.10.63 versions. After rebooting, my encrypted fd64save_dmcrypt_.ext4 savefile seems to be ignored (no passphrase prompt) and I boot into a prestine fd64.sfs.

The location of my savefile and grub config hasn't changed. Here's the parameters I use in the menuentry which previously worked:

Code: Select all

linux /vmlinuz rootfstype=ramfs savefile=ram:uuid:f225960f-8a1a-4c91-af3f-27ddfe38c478:fd64save_dmcrypt_.ext4 waitdev=5

Am I missing something?

[step]

@JakeSFR knows this piece of Fatdog better than me. Hopefully he can chime in.
Worth trying adding "coldplug waitdev=5:5" to ensure that all involved modules and drives are ready.

[m1k3]

Worth trying adding "coldplug waitdev=5:5" to ensure that all involved modules and drives are ready.

Thank you for the suggestion! Unfortunately, that did not seem to work.

[JakeSFR]

Recently, I temporarily switched to 5.10.63, in order to check something, and it did recognize my (also encrypted) savefile. It's on my internal drive, though.

It won't hurt to use 'Control Panel -> Install -> Savefile Argument Builder' and see if you'll still get the same argument.
You could also try more generic savefile=ram:usb:fd64save_dmcrypt_.ext4 waitdev=5 or even savefile=ram:usb waitdev=5.

But other than that, I'm not sure...
Does the USB stick work at all with that kernel (you didn't write whether you boot from it or use it only for the savefile)?

Greetings!

[m1k3]

You could also try more generic savefile=ram:usb:fd64save_dmcrypt_.ext4 waitdev=5

Thanks! That worked. I guess the uuid I got from the argument builder was throwing it off?

[Clarity]

Similarly, I remember having a similar issue the arg builder use and the outcome. I dont remember the specifics but do remember my struggles. The ARG builder is great, but can sometimes required an external tweak for proper booting in both a pristine expectation and normal expectation where the savefile is to be found, and when using different versions of fatdog.

My case is unique in comparison to most users: I keep ALL of my persistence on a system drive that has a linux file-system labeled Persistence where they are ALL contained in a folder named "/Sessions". This is done for simple housekeeping.

For me, specifying the partition negates the problem that I sometimes have run into trying to use the UUID.

I ASK: IS there a way to use the partition's LABEL? versus the partition ID (for example; I currently use the partition ID "sdb4" and would find it more useful to use the label in the SAVEFILE parameter, if possible)

[JakeSFR]

Thanks! That worked. I guess the uuid I got from the argument builder was throwing it off?

Alright, glad it worked, I wasn't so optimistic about it!

But still, I wasn't able to reproduce it booting FD in QEmu, using UUID, with a savefile on a USB stick - it worked for me with both 5.4.152 and 5.10.63 kernels, so the mystery remains unsolved, I'm afraid...

I ASK: IS there a way to use the partition's LABEL? versus the partition ID (for example; I currently use the partition ID "sdb4" and would find it more useful to use the label in the SAVEFILE parameter, if possible)

I've never tried it personally, but it seems to be possible:

label:dev-label:path:crypt
"label" command is identical to "device" command, except that instead of specifying the device/partition by its device name, you specify the device label. You can name your device/partition using tools such as Gparted. Note: label cannot contain space or colon.

Greetings!

[m1k3]

@JakeSFR, I spoke too soon. I rebooted again and got the same message about the savefile not being found and then booting into a pristine environment. Then, I thought, why not make waitdev=10 and see what that does. After doing that it found the savefile again. Not sure exactly why sometimes the file is found and sometimes it doesn't.

Edit: I just found the waitdev=n bit in the FD help so I guess my USB stick must be intermittently slow for some reason.

[JakeSFR]

Yeah, most likely it takes slightly more or less than 5 seconds for the new kernel to recognize the USB device, that's why it works only sometimes.
I mistakenly thought that Step's waitdev=5:5 would take care of this possibility, but the second 5 occurs after searching for a savefile.

Greetings!

[Clarity]

hI @JakeSFR and thanks muchly for your guidance here.

If I read your post correctly, you suggest for my system's linux partition (ext4), that I can replace this 'unit ID' section with the partition label instead of the partition ID.

I keep all of my Sessions on a system drive's partition (sda4) which has a label (Persistence) where there is a folder for all sessions (Sessions).

So I think you indicate

• that the current savefile=ram:multi:sda4:/Sessions/ which works today,

• with a rewritten parm of savefile=ram:multi:Persistence:/Sessions/ and expect the same result.

[JakeSFR]

Not exactly, according to /aufs/pup_init/sbin/system-init:

Code: Select all

#             - multi:dev:path:n - load in multisession mode, dev & path optional 
#                   --> default dev = first dvd drive (sr0), n = don't load the last n sessions
#                   --> dev isn't necessarily a dvd, it could be harddisk too ...
#             - multi:label:label:path:n 
#               multi:uuid:uuid:path:n
#               multi:device:dev:path:n
#                   --> new format to specify multisession device by device, label or uuid

it should be:

Code: Select all

savefile=ram:multi:label:Persistence:/Sessions/

although it's still kinda incorrect, because the last chunk (/Sessions/) should actually point to an SFS file within that directory, not the directory itself.

If it works anyway, great, but just pointing it out.

Greetings!

[Clarity]

...
Edit: I just found the waitdev=n bit in the FD help so I guess my USB stick must be intermittently slow for some reason.

Hi Mike, YES that is a common and an specific problem for flash-sticks as well as some PC's USB ports.

I can account for many of the symptoms you show in your experiences. I have one USB drive that will work 1st time power on but never after. Another I have is after a use, on reboot, in order for the PC to discover the unit, the unit MUST be repowered for the PC to discover it. Another ...

This behavior does not exist for system drives.

And, I have learned to NEVER (in my experiences) use a USB as an interactive system drive. USB performance has been found (in my testing couple years back) can and does impact the system's performance behavior when "mounted" and attempts to use it as a running interactive system drive. I never found if it was due to USB's controllers or the PC port timing element or ???

Today, I ONLY use USBs for

• maintaining ISO files that I boot from

• long term storage

• file transfers between locations when I travel.

At my most recent count, I have 43 USBs unit with storage sizes from 512MB up to 256GB for flash-sticks where each has varying performances and behaviors which are bothersome and time wasters when observing and trying to diagnose problems.

This is just my experiences and what I settled to do when using USBs....for boot ONLY and NEVER for saving sessions from ANY of the forum PUPs/DOGs.

[Clarity]

Thanks @JakeSFR. From your above post with "multi" example, does that match what you see in SAVEFILE Argument Builder utility on your end?

Try running an example in QEMU to see. I used the builder in a QEMU pristine build of FD 812, I have. I set up a storage for QEMU to store and try the builder to mimic my PC. You can do same and see if your recommendation matches builder.

QEMU Scenario

1. X86 boot

2. a storage to be the system drive

3. booted the FD ISO file

4. Ran the savefile builder

Curious to see your observations.

[JakeSFR]

Thanks @JakeSFR. From your above post with "multi" example, does that match what you see in SAVEFILE Argument Builder utility on your end?

Well, obviously not, because SAB doesn't support label, only device and uuid.
As I said in the other thread, it supports only a subset of all available savefile options.

But more important question is: did the example I gave you work for you or not?

Greetings!

[Clarity]

Thanks @JakeSFR I will do a bare-metal test tonight when I shutdown for a test to compare which of the savefile parms I try work using the partition label.

Soon.

[Clarity]

Thanks @JakeSFR

The 2 commands produce identical results.

Code: Select all

using the partition ID
[    0.000000] Linux version 5.4.152 (root@fatdog64-07b) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Mon Oct 11 10:17:20 EDT 2021
[    0.000000] Command line: rootfstype=ramfs savefile=direct:multi:sdb1:/Sessions/1st/  initrd=initrd BOOT_IMAGE=vmlinuz 

Using the partition label-name
[    0.000000] Linux version 5.4.152 (root@fatdog64-07b) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Mon Oct 11 10:17:20 EDT 2021
[    0.000000] Command line: rootfstype=ramfs savefile=direct:multi:label:Persistence:/Sessions/1st/  initrd=initrd BOOT_IMAGE=vmlinuz 

Maybe a future 'builder' may be in order. Of course, this depends on user usage.