save2session is looking for sdc, but my disk is at /dev/sdb

[je55eah]

How should I move it to sdc? I actually lost some data because this happened once before and when I saved my session it silently failed to write anything.

[je55eah]

Since my boot menu entry specifies the UUID, I don't even understand why save2session is wanting /dev/sdc

Code: Select all

menuentry "Fatdog64 with unencrypted USB multisession support" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs waitdev=10 coldplug ntfsnoperm HOSTNAME=fatdog0284-E81B savefile=direct:multi:uuid:0284-E81B:/saves/fatdog813save.ext4
	initrd /initrd
	echo Booting ...
}

[step]

I'm not an expert in that part of Fatdog code but I'll try to help.
I think the multisession save device is determined once and saved to /etc/BOOTSTATE as MULTI_DEVICE=/dev/sdX
The determination is done with this command, in your case,
blkid | grep -im 1 uuid=\"0284-E81B\\b.\*\" (plus some irrelevant formatting)

If you then unplug the device in the course of the same session, then plug it back, it is possible for the kernel to assign the removable disk a different /dev/sdY. Then the new sdY will differ from the sdX recorded in /etc/BOOTSTATE, which is the device tobe used to save the session.

If I was trying to troubleshoot the same issue, when you wanted to save the session I would try to re-create the same initial conditions when /etc/BOOTSTATE was created: plugging USB devices into the same ports, unplugging devices that weren't there when the device booted, etc.

I'm not going to suggest to edit /etc/BOOTSTATE because results are unpredictable.

[je55eah]

Thanks step. I did already try a lot of plugging and unplugging to try to get it back on sdc, but nothing seems to get sdc anymore in this session.

Despite your warning, it sounds like changing MULTI_DEVICE is probably my best option. Why is that unpredictable?

[je55eah]

I backed up my files and gave it a try. Perhaps something went awry behind the scenes, but I don't have any problems o report. Chancing sdc to sdb in the BOOTSTATE file seems to have worked flawlessly. Thank you.

Rather than saving the MULTI_DEVICE variable, it would seem to be better to find the drive with the UUID at the time of saving.

[step]

Despite your warning, it sounds like changing MULTI_DEVICE is probably my best option. Why is that unpredictable?

Because /etc/BOOTSTATE isn't meant to be changed after boot time. That file is read over and over by many system scripts. Changing one value might work for you but not for other users who set up the system differently. So YMMV. Glad you could solve your issue.