SDB Talk:Encrypted root file system
Should be polished (the layout and title)?
There seems to be interest to have http://old-en.opensuse.org/Encrypted_Root_File_System also in the 'new' wiki: http://lists.opensuse.org/opensuse-de/2010-10/msg00009.html . So I did the import. But I doubt that this is the 'right' namespace (maybe [[SDB:]] ?) or the article is fitting to the new-wiki's beauty-guidelines. And according to so mailing-list someone wants to make some changes to actualize the article? Regards --Pistazienfresser 10:24, 1 October 2010 (MDT)
Links from openFATE
- There is a link from "openFATE #305633: Support installation with encrypted root file system" to Encrypted Root File System with SUSE HOWTO. Is this article or its predecessor meant? --Pistazienfresser 10:11, 4 October 2010 (MDT)
Statements to be executed as root AND sudo
It says: Please execute the commands and edit the files listed below as root.
And after that each and every statement shown is prefixed by "sudo".
I know usage of sudo spreads like a disease, but this is really double.
Stuck on swap disk at boot
After applying .root.key to not only my root partition, but also my (encrypted) swap and home partitions and rebooting, the boot got stuck waiting for the swap disk. It turned out that my swap had been set to passno 0 in /etc/fstab, while the root partition had passno 1. IIUC, this resulted in a kind of deadlock: root won't be mounted before swap comes up, and swap can't be unlocked without access to the root disk (where crypttab is).
I'm not sure if that passno 0 was my own doing, or something that happened by default, so I'm not sure if it's relevant to add to the main page. Still, it may be useful to someone, so... putting it here.
Oh, and the solution was to boot in recovery mode and change the swap's passno to 2. I also ran mkinitrd; not sure if that was necessary or not. Snild (talk) 08:30, 2 April 2022 (UTC)
Not sure if I was just lucky before (that is, my "fix" wasn't really a fix) or if my `zypper dup` earlier this week broke something, but... the problem came back. This time, I fixed it by removing the "resume=" kernel cmdline arg from /etc/default/grub. Snild (talk) 14:20, 10 April 2022 (UTC)