Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators
Hey guys, I'm running into an issue where I can't boot with an encrypted savefile. I tried playing around with waitdev times but it doesn't matter how many seconds I add for both wait points. It will stop at "Booting..." and not proceed. It will load, however, if I either choose the no savefile grub entry or if I use a non-encrypted savefile.
Thoughts?
Edit: please note that these savefiles were created with 813 and not 812. FD 812 works fine with my USB 3 flash drive and encrypted savefiles.
[I moved your post to a separate thread.]
"Booting..." as in "Booting the kernel"?
That message comes from the kernel itself:
Code: Select all
# strings vmlinuz | grep -i booting
Booting the kernel.long before processing the savefile by sysinit script, even before loading fd64.sfs, which is indicated by another message.
You could try loglevel=7 and showerr boot options, so maybe we'll see in more detail where it stops exactly.
And would it also happen if you replaced the default kernel with k5.4.152 from 812?
Btw, I also use encrypted savefiles with 813 and it boots just fine, incl. USB flash drive.
Greetings!
It seems like the "Booting ..." I'm seeing is from the echo in grub:
menuentry "Fatdog64 with savefile in USB device" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs waitdev=7:7 savefile=ram:uuid:de927a6f-434d-4fb5-90c0-bfa7ed326d23:fd64save_dmcrypt_.ext4
initrd /initrd
echo Booting ...
}
I tried increasing the log verbosity but I don't see any output whatsoever. Should there be boot messages during the boot sequence or after the splash screen? I don't recall ever seeing any log output as long as I've used FD on this machine (ThinkPad x230). Am I safe to assume that if I'm seeing the "Booting ..." message from grub that it successfully loaded the kernel at that point and is getting hung up somewhere else?
Not sure if this matters or not, but I followed the instructions to make the USB flash drive bootable with bios and UEFI as I do with any version of FD. The only thing I do differently is make the second partition (with fd64.sfs) bigger and format it to xfs but that's usually not an issue.
Just to be clear: this only happens when using encrypted savefile?
You can boot ok with standard / non-encrypted savefile?
You can boot ok without any savefile? (when you pass savefile=none to the boot parameter?)
Hmm, that's odd. If you have spare flash drive (and time), can you configure another flash drive but with ext4 instead of xfs, and copy over your failed-to-boot settings? (as in, copy the contents of the partition that contains fatdog and the encrypted save). Just to narrow the possible culprit ...
The situation that I'm seeing right now is that booting from xfs and non-encrypted save all works.
But xfs with encrypted savefile fails with only "Booting ..." which comes from bootloader (grub2).
The kernel hasn't even started yet, and the only reason for that is because the bootloader hasn't finished loading initrd (or got stuck while loading it).
But it doesn't make sense, initrd is initrd, it will be loaded in exactly the same way whether or not you have encrypted save or not. The bootloader doesn't care, the kernel doesn't care either (the only thing that cares about the savefile - encrypted or not - is initrd, __after__ the kernel has started).
Apparently, I'm going crazy because it's working now. On this ThinkPad I normally always keep it in BIOS-only boot mode which has worked fine for FD. After having the boot issues with 813 I changed it to UEFI to test it and was able to boot FD without the savefile. So, just now I figured I would change it back to BIOS-only and try one more time and sure enough, it found the encrypted savefile and booted normally. I'm perplexed because I know that I waited at least 5 minutes days ago in BIOS-only mode and nothing happened. The only difference this time is that the grub stanza is different as it now specifies the laying mode and USB device (uuid) but I don't see why that would matter.
Anyhow, I greatly appreciate your time and assistance with this even though it turned out to be a fluke on my end. I'm honestly not sure why it's working now and starting to think I'm going crazy because I've tried it so many times without success in the past few days. 
You're right, that shouldn't matter. Nevertheless, I'm glad that it works for you.
My working theory is the the "xfs" driver in the bootloader is probably isn't that good, and by editing certain files you're moving blocks here and there; and in certain cases the bootloader can load it, in some cases it can't (that's the reason I asked you to test identical configuration with ext4) ... but it remains a theory.