Day 25 - Quarter of the way there!

I am 25% there. That’s one part in four, I just need to do the thing that I have already done, 3 times over. Sounds doable, from here on atleast! I just wish I don’t miss a day in between. I missed one day in between till now, and that was not even the day I was most tired on. In fact, the days that I was most tired on, turned out to be the challenging ones when I struggled to write the 500 words and git add and git commit and git push.

I would like to talk a little bit about the encrypted FS setup that I have got going on, in my computer right now. It’s been about a week (or two?) since I installed Ubuntu 16.04, and I setup two encrypted partitions when I was installing it. Now, the dust has settled for the most part, and it is looking good now! This post is a continuation of the post on day 15.

I added these two volumes to /etc/crypttab and to /etc/fstab.

/etc/crypttab

partname UUID=... none luks,nofail

Here, the luks and nofail in the last argument are VERY IMPORTANT. Without the nofail flag set in that argument, the boot fails because it couldn’t find the right password for that block device. Also, the none must be spelled out so that Ubuntu will interactively ask you for your password. This is only one part of the setup though, only adding this will also lead to boot failure. More on how to recover from there later.

/etc/fstab

/dev/mapper/partname /media/username/mountpt ext4 defaults 0 2

The partname is automatically referred once the block device has been unlocked using LUKS and there are two parts of the partition now (the decrypted one is mounted at the provided mountpoint).

Not doing any of the above steps properly, will lead to a failure in the boot process. What this means, is that the boot will simply fail and bring you to a black screen (sometimes the screen also has text, I was a little bit panicked to check what was going on on that screen).

A simple way to get out of this is to boot into Ubuntu in the recovery mode, and from there get a root shell. This root shell only has read-only access to the disk. So, from here, you should run something like reboot which will restart your computer. There is a sequence of commands that can be run here to get you to a root shell with write access to the disk. I used this sequence to reset the fstab and crypttab files to their default values when I ran into trouble. Unfortunately, I can’t remember what that sequence is. I am sorry if this part is so unhelpful.

I can only say that rebooting was definitely part of the process, and then something like “continue boot” in the recovery mode list.

Once on this write-access enabled root shell, you can do one of two things

1. Rollback all changes to these two files, and restart. This will definitely work all the time. You can simply make the right changes and then restart to get it to work properly again

2. If you are feeling adventurous, then you could change the files in this root shell and reboot. If you have made the right set of changes, the interactive password prompt will come up.

If you don’t enter anything in the interactive password prompt for a long time, then it goes to a blank screen. There’s absolutely nothing on that screen. I had to pull the plug and restart both times that I ran into this problem. No clue whether there is a better way to pull the computer out of this situation.

One thing that I have not yet tested is what happens when you enter the wrong password in the interactive prompt.

POST #25 is OVER