x60 Hanging After Entering Disk Encryption Password

11 risposte [Ultimo contenuto]
strypey
Offline
Iscritto: 05/14/2015

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?

strypey
Offline
Iscritto: 05/14/2015

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.

nadebula.1984
Offline
Iscritto: 05/01/2018

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.

strypey
Offline
Iscritto: 05/14/2015

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?

strypey
Offline
Iscritto: 05/14/2015

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.

strypey
Offline
Iscritto: 05/14/2015

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?

liberpoolesque
Offline
Iscritto: 01/07/2020

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.

strypey
Offline
Iscritto: 05/14/2015

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.

liberpoolesque
Offline
Iscritto: 01/07/2020

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.

strypey
Offline
Iscritto: 05/14/2015

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.

strypey
Offline
Iscritto: 05/14/2015

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.

lanun
Offline
Iscritto: 04/01/2021

> 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.