I'm encountering a difficulty in the restore process when"protect" is used. The position of the encryption password entry in the boot sequence seems as if it may be jinxing the restore process.
Any suggestions would be welcome.
The situation is as follows:
Booting live cd of tinycore 3.5 using boot codes "tinycore waitusb=20 secure protect", generates a boot dialog that includes this sequence:
Loading Extensions ... Done.
Restoring backup files from /mnt/sda1/ mounted over
device /dev/sda1 Done
Setting keymap to us Done
Enter password .... for root: ....
Enter password .... for tc: ....
Enter password .... for encryption
At which point X starts, but it does NOT include my backup.
I think this is occuring because of the boot sequencing, for while tinycore is correctly locating the backup on sda1, it is unable to restore it without having yet received the encryption password. (This would also explain why the us keymap loads instead of the uk one specified in the backup....)
By contrast, booting the same system without "protect", (i.e. as "tinycore waitusb=20 secure") restores successfully (provided of course that my non-encrypted backup is on the usb, instead of the encrypted one!)
A possible solution suggests itself:
Since the encryption password seems only to be needed at boot, would it work to move the encryption password entry to occur BEFORE restoring, whilst keeping the root and tc passwords AFTER restoring, as at present?
This would retain the very real benefit of having the root and tc passwords entered in the correct keymap, so they can be used again throughout a session after the keymap has been set, but it would also enable encrypted users to share in that benefit, which at present they cannot if, like me, their restore is unable to occur during backup because of the delayed password, and therefore has to be performed manually after boot.)
As far as I can tell, tc's encryption password is never required again after boot - so the keymap issues that affect the root and tc passwords really don't apply to it, i.e. whatever sequence of keystrokes is typed will work without regard to what characters the us keymap will assign to the keystrokes. (Although if you wish to know just what the system will "see", I find you can "test" your password on the live cd's bootcode line where you can see it, or by booting "tinycore base norestore" and typing in terminal ....)
In summary: In its present position the encryption password entry seems to jinx the restore process, so it seems to me that moving itearlier in the sequence might be helpful. Alas I have no clue howto do this, so for now it's "workaround time"!
For now, my workaround is to do a manual restore after X loads, then control+alt+backspace, "sudo /opt/bootlocal.sh",return, "exit", "tc", and enter tc's password. (It's a bit time-consuming as you can imagine, but is improving my typing skills no end!!!)
Any consideration or advice you can give on this issue will be greatly appreciated. Many thanks.