x60 Hanging After Entering Disk Encryption Password
I have a problem with my x60. It was working fine yesterday. But when I try to boot it today, after I put in the disk encryption password, it says:
"cryptsetup: sda2_crypt set up successfully"
... and then just hangs there, with the Trisquel logo flashing.
Any suggestions?
This is a Trisquel 8 system. Following MagicBanana's instructions here:
https://trisquel.info/en/forum/locked-out
... I managed to get to the GRUB menu and boot into a recovery environment, but I'm not sure yet how this can help me. I'd really prefer to fix the problem, although I'm also considering a fresh install of Trisquel 9 into the spare partition I put aside for a secondary OS.
The stupidest method is to boot into a Live environment. Then decrypt the hard disk and make a full backup.
When you re-install the system, if you already filled randomized data to the encrypted hard disk, you wouldn't need to do it again.
A few questions about handling the issue with the encrypted disk on my x60, sorry about the long delay in getting back to this:
1) Is there any way to check that the encrypted disk is still OK?
2) Would it work to just install Etiona on my spare OS partition and mount the encrypted disk as /home?
nadebula.1984:
> The stupidest method is to boot into a Live environment. Then decrypt the hard disk and make a full backup.
3) Why is it a stupid method?
4) How do I mount an encrypted disk in a live system?
> When you re-install the system, if you already filled randomized data to the encrypted hard disk, you wouldn't need to do it again.
5) Why would I want to have " filled randomized data to the encrypted hard disk"?
6) How would I have done that?
So I managed to boot from an Etiona boot USB, and decrypt the encrypted /home partition. I'm guessing that means the files are OK? But I can't check because Caja tells me I don't have the necessary permissions to access the user files, which are under /media, inside protected folders with the names of the users on the system.
I'm still unsure, but given that I can't even access a virtual terminal after typing in the disk encryption password, it seems logical that the problem is with booting the OS from its encrypted btrfs partition.
So I'm still desperate for answers to questions 1) and 2) in my last comment.
Further progress. Someone wise advised me to hit the Esc key after the system seemed to stall. It turns out the ExpressVPN daemon is being started and stopped over and over again, and this could be what's making the system hang. That'll teach me for installing proprietary garbage on my production system instead of having a secondary OS for use with it, or maybe using the Windows version in WINE.
The same wise one suggested I boot into a recovery session and run systemctl disable expressvpn. I did that, and now hitting Esc after typing the encryption password gives me a different message:
> A start job is running for Hold until boot process finishes up ([timing going up] / no limit)
Any suggestions?
Huh. I've entered your error message into a search engine, but I just got some suggestions about overfilled root partitions and some strange package gymnastics with Ubuntu 16. I don't think any of that applies to your problem, and analysing the issue from afar isn't going to be easy. Personally, I'd just advise to reinstall the OS.
There are two ways to do this:
a) Copying all your important files onto a backup drive and reinstalling the OS the ordinary way, by completely overwriting the old system, followed by restoring your backed-up files from your backup drive.
And, assuming your /home is mounted on a separate partition:
b) Installing the OS only onto a single partition (without touching the /home partition) and then hooking up the /home partition by adding the necessary line in /etc/fstab. I have done this once.
Solution (a) is the easiest, though I would recommend checking on a secondary computer if your backup of your /home was completed correctly. Though it is a good idea to keep a backup of all your data in both cases.
You should also consider whether you want to store the backup on encrypted storage media or unencrypted media. The latter may make the encryption of your main computer seem a bit pointless.
If you are ok with one of these two options, tell me which one you want to proceed with, I think I'll be able to help.
I'm not sure if you are familiar with the shell use of tar and sudo, so here's an explanation about backups:
If you are having trouble making a backup because of the permissions, use a terminal to make a TAR archive using root privileges. Navigate to the directory that contains the user directories that you want to save the directories (which in this example will be called "user1", "user2" and "user3"), open the directory containing them in a terminal and execute the following command:
sudo tar -czvf /path/to/backup/directory/home-backup.tar.gz user1 user2 user3
This will contain a compressed (-z) TAR archive containing those directories and store it in the given backup directory. The owner of the archive will be the root user. After the process completes, check the end of the output for any error messages.
About your first question, "Is there any way to check that the encrypted disk is still OK?": Well, if you can still unlock the disk in a live environment, the LUKS header should be fine. It is unlikely that the problem is with the encryption.
About question five, "Why would I want to have " filled randomized data to the encrypted hard disk"?": Factory-fresh storage drives tend to be filled with zeros. Even if you use full-disk encryption to store data, it will be possible to spot where files are saved on the drive (simply by searching for a part that does not consist completely of zeros, and you can do something similar if the drive was used without encryption before). Since the encryption does not change the size of files, someone who steals your drive might infer the type or content of some of your files solely based on their size (but this is kind of a stretch). This can be prevented by filling the drive completely with random data before setting up encryption, because random data is indistinguishable from encrypted data. When installing Trisquel using the default method, the installer offers the option to "overwrite the empty disk space" when asking for an encryption passphrase, so I think that's what is means. It takes a long time, though, with some of my drives, it would take up to a day. I think it is not really necessary, the drive will be filled over time with encrypted data anyways. It is up to you.
I don't currently have an external drive I can use to backup my files, so my preferred option is ...
liberpoolesque:
> b) Installing the OS only onto a single partition (without touching the /home partition) and then hooking up the /home partition by adding the necessary line in /etc/fstab. I have done this once.
Can you give me some instructions, tips, and gotchas for doing this? I have a spare OS partition I can install into. Other than the risk of installing to the wrong partition, which I'm pretty confident I can avoid, I can't think of any others risks to my files here.
Ok, I can help with that, but some knowledge about the layout of your drive would be nice. The layout of the partition table, the LUKS container, the LVM volumes and the filesystem types. This helps me see what needs to be done to make the system work. If you want to, you can just start a live session, mount all partitions that can be mounted, and give me the output of "lsblk" and "lsblk -f". Also the contents of etc/fstab and etc/crypttab of the broken system would be useful.
If you don't want to post this to the world, you can send it to me as a mail. If you are using the mailing list, you can already see my address. Otherwise, you can use my key. My key id is CD7B 095A 30E2 B634 A422 96A0 68EA B5DD 5A3C E94C, and it can be found at https://keys.openpgp.org/vks/v1/by-fingerprint/CD7B095A30E2B634A42296A068EAB5DD5A3CE94C
I accept encrypted mails.
Also, is the spare partition you mentioned inside or outside of the encrypted part of your drive?
If it is outside, the process is easier, but it means that the filesystem root will be unencrypted. This can be a problem. If you open an ebook in the EPUB format in Atril, for example, Atril will dump the contents of the book into the /tmp directory, which would be unencrypted in this case, so anyone with access to your drive could be able to see which books you've been reading recently. As another example, the contents of the log files that your applications might write to /var/log would also be unencrypted.
If it is inside, it will be safe, but making it work is a bit more difficult, because the Trisquel installer does not seem to correctly set up /etc/crypttab if it did not create the LUKS container itself. It requires some typing to fix, but I have done that a few times.
liberpoolesque:
> Also, is the spare partition you mentioned inside or outside of the encrypted part of your drive?
Turns out I didn't make a spare OS partition, I just left enough unallocated space for one. I just used GParted in a live session to create an ext4 partition in that space, just to check I'm right about that, which seems to have worked. So I'm guessing this new partition is outside the encrypted part?
> If it is outside, the process is easier, but it means that the filesystem root will be unencrypted.
That's OK. This system was my first experiment with disk encryption. Before I start making use of it in production, I clearly need to learn a bunch of stuff about things like ...
> partition table, the LUKS container, the LVM volumes and the filesystem types.
The encrypted OS partition is an ext4 primary. The /home is an xfs partition, inside an extended partition. There is also an extra 976MB ext4 partition at the start of the drive, which I'm presuming is a boot partition? I'm not sure how to describe the LUKS container or LVM volumes.
After the events of the last year or so, I can't remember exactly what I did when I installed this system. But I'm guessing I followed my usual practice, ticked the box for encrypting the disk, and let the Trisquel 8 installer do the rest. My usual install practice is to create a pair of ext4 primary partitions for OS, and an ext4 partition for user files with the remaining space. Then during install I use manual partitioning to select an OS partition as the mount point for / and select the user file partition as the mount point for /home.
Are you sure the filesystem root of the old OS is encrypted? I think I remember that Trisquel 8 did this wrong by only encrypting /home, which isn't supposed to happen. But this won't matter.
Since the partition you want to install the new OS in is probably not encrypted, this will be easier. You can just launch the Trisquel 9 installer, go to the "installation type" part and select "something else" (do not select the other option, the one that wipes the entire drive).
Select the new partition you created, and set it to be used as root filesystem "/". Continue the install. You may need to overwrite the bootloader of the old OS.
At the end, it should now be possible to boot into the new OS. Here, we can set up the disk encryption. Copy the /etc/crypttab from the old OS to the new OS. Create the file if it does not exist. Use the following commands to make sure that the boot data is up to date:
sudo update-initramfs -k all -u
sudo update-grub
The update-grub command may display some errors, but you can ignore them.
When rebooting, the system should now ask for the encryption passphrase for the /home partition, and you should be able to open it in the file manager without the system asking for a passphrase afterwards.
You can now add the line from the old /etc/fstab for mounting the /home partition to the /etc/fstab of your new OS, so after rebooting, it should be automatically mounted at /home.
It is also a good idea to add the line for the swap partition to the new /etc/fstab.
liberpoolesque:
> Are you sure the filesystem root of the old OS is encrypted?
Gparted says its file system is "crypt-luks"
Thanks for the detailed instructions, sounds simple enough. I'll try it out out as soon as I can carve out some uninterrupted time.
One other question ...
> You may need to overwrite the bootloader of the old OS.
Do I need to set the 976MB partition to the mount point "/boot" during the manual partitioning stage? Otherwise I'm guessing the system will just boot into the current OS install for the existing grub in that boot partition, not realizing the new Grub in the new OS primary partition is there. Yes?
Actually, I meant the part of GRUB that is stored at the MBR of the DOS-style partitioning table. I tested an install, and it seems that the installer just does this automatically, so that's fine.
You don't need to overwrite the old /boot partition, the newly installed GRUB should automatically find the files of the OS it was installed for, even if /boot is not a separate partition.
But you CAN reuse the old /boot partition, if you plan on never booting the old OS again. It will save a little space on your new OS partition.
And really, booting the old OS after reusing the same home directory for the new OS might result in problems, since the configuration files will have been updated for newer versions of those applications.
It would be possibly to dual-boot if you'd choose a different username for the new OS, so you would habe different home directories for different OS's in your /home. (though then you'd have to copy the new user home directory to the old /home partition before adding the /home line in /etc/fstab)
I'm using this kind of setup myself.
So I did another troubleshooting session with the helpful folks from the NZ Technology Discussions matrix channel, thanks heaps to Zyk and Idanoo for their help. We managed to get into an Openbox session using the startx command within the root console accessed from a recovery session. On their advice, I added dis_ucode_ldr in place of quiet splash in the vmlinuz line under Trisquel menuentry. After this, the system booted to a tty console, to which I could login, startx back into Openbox, and access my files, which is a relief. So it seems like the system is potentially recoverable without reinstall.
Anyway, during the verbose boot I noticed angry red messages about Light Display Manager failing, so on their advice, I ran;
> systemctl status lightdm
Again, angry red messages saying "failed to start Light Display Manager". So this appears to be the problem. My helpers advised me to install Slim and switch to that, which I did. Ended up in Openbox again. Managed to switch into a Mate desktop but it had a constant spinning beach ball, and the start menu wouldn't open. Another reboot sorted it out, seems Mate works normally if I avoid logging into Openbox first ;)
Next steps are to make sure I have copies of all the data on that laptop and do a fresh install of Etiona on it. I need to think about whether I want to continue using disk encryption or not, as it seems to make PC maintenance way more complicated.
For the record, it seems that the error I struck is very similar to this one afflicting a Thinkpad ts 400:
https://trisquel.info/en/forum/trisquel-9-hung-even-boot
... which has a comment proposing the solution discussed here:
https://trisquel.info/forum/update-90-libreboot-now-computer-wont-boot-gui#comment-154973
I will have a look through this thread and see if any of the proposed solutions might work on my x60.
> I need to think about whether I want to continue using disk encryption or not, as it seems to make PC maintenance way more complicated.
I guess the answer will depend on your threat model. If you are only moving around with a relatively small portion of your files, and if you are not the typical information professional handling highly confidential content, full disk encryption might only add a hurdle in your computing life.
Losing data access because of an encryption hiccup sounds a bit like a shot in the foot if the said data were of no real interest for a potential attacker. If they were, then this is of course completely different matters.