Won't mount /home since update

English Install/Boot/Login
1

Hi everyone! I have a severe issue with Leap 42.1, but I don’t really know how to nail it down… Here’s what I did:

I (re-)installed openSUSE Leap 42.1, during installation, it asked me whether I want to use my legacy /home-directory; I clicked “yes”. The home dir is an encrypted XFS partition (I created it like the default installation in openSUSE 13.2, but afaik nothing has changed since). Apart from that, I went with the default settings for Leap 42.1 – i.e. a seperate btrfs / partition.
Everything worked so far.
I ran a “zypper up”, got ~300 new packages. I did not do anything but specifying my WiFi password and running zypper up…

I rebooted.

Now, the system hang on boot. [https://lut.im/2VqSG6J6pN/QbYLP54dO3nFn2gM.JPG]
https://lut.im/2VqSG6J6pN/QbYLP54dO3nFn2gM.JPG
That’s what it says… In my interpretation, it cannot mount /home, and it doesn’t even ask me to enter my passphrase for the encryption.
I really don’t know what I can do about it. I had the same problem before, I though I could have done s.th. wrong; But now, I really didn’t do anything but installation, updates, reboot.

Any idea how I should proceed?

–
openSUSE Leap 42.1, Gnome DE, on an Asus ZenBook, i5-3317U processor, ADATA SSD

2

I have seen a bug report about a similar situation. However, as best I remember, it was for Tumbleweed rather than for Leap 42.1. That makes me wonder if you have mixed repos and are getting “systemd” from Tumbleweed or Factory repos.

In any case, when that happens you should be able to login as root at the command line. And then you can try handling the crypto at the command line.

First use:

# cat /etc/crypttab

Then (assuming LUKS encryption), you need:

# cryptsetup luksOpen <second-column> <first-column>

where those are the columns of the appropriate line in “/etc/crypttab”.

If you do that, the chances are that “/home” will be automatically mounted, and you can resume the interrupted boot. It it is not mounted automatically, the command for that should be:

# mount /dev/mapper/<first-column> /home

though just “mount /home” might work.

Yes, it is tedious to do that every time. But at least it gets you in, and maybe you can find more information about the problem.

3

Hi, thank you so far (at least I have a working PC now^^).

This is what happened:I updated my system again… The log told me this: http://paste.opensuse.org/16879288 – I couldn’t find s.th. that helped me.
As expected, on reboot I got no /home to mount.

So I logged in as root, found that my /etc/crypttab and /etc/fstab looked as before.
So, as you advised me (thanks again), I went for a manual luks-mounting/opening.


cryptsetup luksOpen /dev/disk/by-id/ata-ADATA_XM11_256GB_._2300404502000024-part4 cr_ata-ADATA_XM11_256GB_._2300404502000024-part4  
Device /dev/disk/by-id/ata-ADATA_XM11_256GB_._2300404502000024-part4 doesn't exist or access denied.

did not yield the result I had hoped for. Anyway, during my tab-completion in /dev/disk/by-id/, I had seen it knew a slightly different name:


cryptsetup luksOpen  /dev/disk/by-id/ata-ADATA_XM11_25**6GB_230**0404502000024-part4  cr_ata-ADATA_XM11_256GB_._2300404502000024-part4

asked me for my passphrase and worked on. It is the same string, but omitting the **._ **in between. I have no understanding of how these names are created, so I don’t really understand what I did here; However, it was positive (I think).
I went on with mounting:


mount /dev/mapper/cr_ata-ADATA_XM11_256GB_._2300404502000024-part4 /home
mount: cr_ata-ADATA_XM11_256GB_._2300404502000024-part4 is already mounted on /home busy
       cr_ata-ADATA_XM11_256GB_._2300404502000024-part4 is already mounted on /home

This was confusing! Just before I had logged in as root, I had verified that logging in as my normal user resulted in the “no /home found” error message (I forgot the exact wording, but the thing you get if it can’t find your /home partition).

Anyway: As of now the computer works. Thank you so far.

However, I don’t feel this is a good solution. If any of the more experienced Geekos could give me some insight on what I did wrong / what actually went wrong, I would appreciate this! And surplus: I wonder whether that is something I should file an official bugreport for. Unfortunately, I have a very limited understanding on the topic, nonetheless, in the first place I just installed openSUSE from scratch, made the updates, didn’t do anything else, and found my system broken – so this should be something, openSUSE devs deal with, shouldn’t it?

4

At least you now have something that you can work with, though a bit inconvenient.

From your description, possibly there is something wrong about the “/etc/crypttab” entry. Or possibly it depends on your language selection and how characters are interpreted. And it is possible that the update affected that.

The format of “/etc/crypttab” is:

virtual_device_name     real_device_name    password  option

Usually the last two fields (password, options) are “none” and “none”.

I suggest that you edit “/etc/crypttab” and make sure that the real_device_name is something recognized. The safest might be to use the UUID. Assuming that this is your first and only disk, use the command (as root)

# blkid /dev/sda4

I’m getting that “4” from the “part4” in the names that you are using. The UUID will be a string of hexadecimal digits and hyphens. For one of my partitions, it is “4f9ef32b-5814-4fe4-a320-5e91e99ffcac” but that won’t be the UUID for yours. You need to find the actual UUID (copy/paste is great for this.

In the “real_device_name” field (second column), you can use “UUID=string of characters” (without the quote). So, for my example partition, I would use

UUID=4f9ef32b-5814-4fe4-a320-5e91e99ffcac

.

After that change, it should start prompting for the key during boot.

5

Thank you, indeed, that solved it. I changed my crypttab from

 cr_ata-ADATA_XM11_256GB_._2300404502000024-part4 /dev/disk/by-id/ata-ADATA_XM11_256GB_._2300404502000024-part4 none       none

to

 cr_ata-ADATA_XM11_256GB_._2300404502000024-part4        UUID=889479d9-c479-42cf-9991-b678a0b359dd       none       none

and that solved it.

Nonetheless: I don’t understand how these (weird?!) names were created in the first place (some YaST2-magic…?) and why it broke – as I said: I had my /-partition formatted and the freshest, unchangest openSUSE possible on it. And I still wonder whether or not that’s worth writing a bug report…

Anyway: Thanks a lot! :nerd:

6

Any time a partition is create or maybe moved a random number is assigned as UUID This makes a unique identifier to reference the partition

7

I’m glad it’s working.

Those “weird” names are pretty standard for linux. The simpler device names, such as “/dev/sda4” are not reliable. If you happen to have a USB plugged in when you boot, then on some hardware, that disk partition might come up as “/dev/sdb4”. So the disk ID names is supposed to avoid that, by using a name that should always work (and it didn’t always work for you). That’s the idea.

If you only have one disk, then

ls /dev/disk/by-id/*part4

will list the possible ID names for your home partition.