This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]opensuse.org

SDB Talk:Encrypted root file system

Jump to: navigation, search

Should be polished (the layout and title)?

Icon-cleanup.png This article is in need of attention because it does not follow our wiki guidelines.
If you want to contribute, please read the rules for this wiki and if you have any questions, don't hesitate to contact the wiki team, we are more then willing to help you! :-)

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

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)