I have a new problem that occurred after a recent (last week or so) update. The home (/usr, I think) directory no longer decrypts during boot sequence, so my standard user account does not log in. Previously (for years and years) my standard user account has completed auto-login during boot, provided I provide the partition password(s). I am hesitant to update Tumbleweed on other my other computers until I can resolve this issue. I have run a couple more “zypper dup” updates since the problem started, but it is not resolved. To log into my standard user, I have to first log in as root user. I then click on the partition in Dolphin, enter the password and the partition decrypts. After that, I can log into my standard user account and they computer will run as it always has. I do provide the password during the boot process. I don’t recall if I also encrypted my root partition, so I’m not certain whether it is decrypting or not – but there is a second partition/drive that I decrypt during boot and it is decrypting normally. Maybe there is sysctrl command that has been dropped from the startup script, but I do not know where to look for it (and potentially add it). I have attempted to decrypt over multiple reboots, so I do not think I am providing a “wrong password” – I use the same password from the root account and it works fine; and it is the one I have always used during boot.
I am not running Tumbleweed, nor encryption, thus I do not think I can help. But seeing that you did not get any answer until now, maybe this will bump the thread a bit.
BTW
is a bit strange. “The home directory” is a bit multi-interpretable. Each user has his home directory, and all those different home directories of all usera are inside he directory /home, which thus could be called “the home directory”. But in any case, this has nothing to do with /usr (which can be described as “the usr directory”).
You probably mean you have an encrypted /home file system. And because that /home file system is stored in a partition, you call it an encrypted partition.
What is the output from:
df
df $HOME
Check that after everthing is up and running.
I don’t know if there is a way to edit my original post, on some forums one would add SOLVED to the title. Thank you to hcvv and nrickert for taking time to give me some hints regarding what to look for.
In all likelihood, this is a problem affecting no one but me, due to the peculiarities of my computer setup. Just in case, I will explain here. (BTW, I will note that it was a careless error to refer in my original post to “/usr” – thanks for pointing this out. The problem was always that /home partition was not decrypting and mounting, I lost my mind for a moment…)
I run this particular computer from Linux on an external USB drive. When the partitioner set up the encryption many years ago, it referred to the drive on which the /home partition is located as "disk-by-id=scsi[something.] This seemed a bit odd at the time, as it was a usb drive, not a scsi drive.
After latest updates, GRUB was no longer prompting me for the password for the /home directory. The solution was to edit cryptab to replace the “scsi” drive id with the ata drive id provided by listing the drives “by-id”.
I copied the wording of my other encrypted usb drive listed in my cryptab, which is
“cr_[partition_id_name UUID=[UUID of the partition]”
Oddly, the original entry did not set out the UUID, it was simply something like
“cr_home disk-by-id/scsi_[bunch of letters and numbers]”
(I am sorry to say I am not writing these entries out accurately, but I am using a different computer to make this post. Among other things, the computer in question crashed when I started this post. I think the CPU is failing, because I got a message in my Konsole window one time re one of the CPUs freezing or something).
In any event, my best guess is that the latest kernel removed the “scsi” designation altogether, so the original cryptab entry was no longer meaningful and therefore GRUB simply skipped it during boot. Fortunately, I could nevertheless log into my root/administrative account. Then in Dolphin, I could click on the icon for the encrypted drive, which would launch a dialog to enter the partition password. Upon entering the password, the /home directory and my user accounts would appear. Also, when listing drives-by-id and drives-by-UUID, the new drive “dm-1” would appear in the list.
I don’t understand much about the boot and decryption process. I think back in 2020 I edited /etc/cryptab because “enter password for /home” is a lot more useful than "enter password for WDC_500_20M45ff99[etc.] and I think my edit made that change.
In any event, I am happy to report that (a) I did not brick my OpenSUSE Tumbleweed install; and (b) as a result of my edit to /etc/cryptab, the computer starts up correctly now…
Nice it is solved!
You can indeed identify a file system (like /home) in several different ways. You can find all of them as they are on your system by looking in /dev/disk/. Some of these are bound to the file system itself (UUID and LABEL), some are bound to the volume, often a partition, they are on (PATH, ID and on GPT also PARTUUID and PARTLABEL). All have their pro’s and cons for using them.
You can indeed not edit an earlier post. When you would have changed everything there, then our answers would probably have become ridiculous. We like to have a discussion here in the sequence it was developed.
There was a recent Tumbleweed change which removed some of the device IDs available. Apparently you were hit by that.
I ran into that problem several years ago, with an install on an external usb drive. The ID used in the install stopped working a few kernels later. Since then, I have alway used the UUID in “/etc/crypttab”.
But you have to be careful with that for encrypted partitions. There are two different UUIDs involved. There is a UUID from the LUKS header, and there is a UUID from the encrypted file system. In “crypttab” you need the UUID from the LUKS header, because the one from the encrypted file system is not available until it is decrypted.
Since you have it working, you must have found the correct UUID to use.
Good to know. That the file systems UUID will not be available sounds logical, but that the encryption software offers it’s alternative was unknown to me.