Cannot log in after fresh installation of Fedora Jam KDE 44

Ask Fedora
1

I have freshly installed Fedora Jam with KDE using the DVD image Fedora-Jam_KDE-Live-44-1.7.x86_64.iso.

My PC already had another OS on it using two partitions.

I made three new partitions for the Jam installation and assigned the following during installation:

ext4: /boot
btrfs luks2: /
btrfs luks2: /home

The installation was successful and after restarting (out of the live version into the new installation, via GRUB), KDE provided me with the ‘first use’ screen to enter the host name, my full name, my user name, my password and my password confirmation (it also pointed out that this user would be an administrator).

I filled in the above and then it went to the login screen, where my user (the only one available) was already selected.

Upon entering my password, I could not log in. The behaviour was exactly as I am used to from my regular experience with Fedora/KDE when entering the wrong password: there was a slight delay, the password box shook from side to side and I can’t remember the message, but I think it was essentially that I had entered incorrect login details (I am not currently at home with that computer, so I can’t check). I tried restarting, but the same thing happened.

I have also tried using Ctrl+Alt+F# to try logging into the shell, but that is also not possible.

It would be extremely unlikely that I had entered the wrong password and confirmed it with the same, but to make certain, I did the whole installation process again, and the same thing happened.

What am I doing wrong, and is there anything I can do to fix it without having to install a third time?

2

I wonder if it’s a LUKS/KDE issue…

Can you boot into rescue and unlock LUKS successfully?

3

We had someone on Matrix last night who installed Fedora Jam and had exactly the same problem.

4

If you mean to choose Rescue Mode from GRUB, I just tried this; it goes to the login screen and everything looks identical to the login screen when booting normally - I can’t see any indication that it is in a different mode and there don’t appear to be any options for ‘rescuing’. (Also, the behaviour is the same when trying to log in).

5

Yeah, from GRUB, select “Rescue” or hit “e” on the regular boot entry and add systemd.unit=rescue.target to the kernel line; then, press Ctrl+x to boot. As far as I know, you should be prompted for the LUKS password to unlock the encrypted volumes.

6

From what I’ve read, it seems the LUKS2 password and user account password are getting conflated or, somehow, “mis-set” during the KDE First Use wizard. Someone much more knowledgeable than me suggested kde-initial-setup might be setting the user account password, but PAM either expects the LUKS passphrase to unlock /home first and the user account password differs from what was stored or kde-initial-setup creates the user but something goes wrong writing the password hash and that leaves the account in a locked or inconsistent state.

Since there’s a separate, encrypted /home partition Fedora needs to auto-unlock it at login and if that’s not configured correctly, login fails even with the right password.

7

I added the rescue bit to the kernel line and it then correctly went into rescue mode. Interesting that it doesn’t work using the actual entry for it…

Once in, it said “Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.”

After viewing the man page, I’m not sure how to use sulogin for this case. Does it somehow have to be passed from GRUB?

8

I don’t know a great deal about Linux, although I’ve been using it exclusively for the last few years and am gradually getting to grips with it. But I had already wondered whether something along the lines of what you are saying here is the case. I’ve been on Fedora KDE Plasma Desktop Edition since installing it last year and I have a similar set-up, in that I have a separate /home partition, a separate /var/www partition, and all partitions encrypted. I believe I set it up initially using a very similar method to what I’ve done here. I can’t remember whether I had to add any password and decryption stuff after the initial installation, but I seem to recall there was something.

The PC I’m trying to set up will be my music recording system and I’d rather get it set up quickly than bother about this issue too much, so I will probably just re-install and have home on the root partition. If there are any suggestions over the next couple of days, I could try them before doing that. Thanks for the help so far.

9

That is interesting about the rescue. It makes sense to me that the root account has no password set, since Fedora ships with it locked, and convinces me this is somehow a user account setup issue.

I think your best bet would be interrupt the boot process earlier using the rd.break command. Back at the GRUB menu, hit “e” again and add rd.break to the line starting with linux; again, Ctrl+X to boot. In the minimal initramfs shell that shows up:

  1. remount sysroot read-write with mount -o remount,rw /sysroot
  2. chroot into the real system with chroot /sysroot
  3. reset the user password with passwd <username> with <username> being your actual username.

You should be prompted for the LUKS password during boot and before reaching the shell.

10

Remounting sysroot seems to have worked, but it said chroot command wasn’t found.

I should have have mentioned earlier that there is always a prompt for the LUKS password, which may be the prompt you are referring to - it appears some time after the selected option in GRUB has started to load (whether I am doing rescue mode, have added arguments, or whatever). It is the prompt I am used to from my main Fedora installation - the password box has a blue border and is centred on the screen, with an instruction below to "Please enter passphrase for disk ST500DM002-1BD142 (luks-a32e…). On my main machine, this prompt appears only once, despite having multiple encrypted partitions, the rest of which I assume are unlocked once the root is unlocked. This new installation also gives me this prompt once.

There is one further thing I see I can do, which is to view a log using the command journalctrl (I think that was what it was), as suggested by the system upon entering that minimal shell. This log contained about 900 lines, and there were a couple of things in there which I thought might be useful to you (including some user that wasn’t found, but wasn’t my user), but I need some advice on how to save this log somewhere - a USB stick would be my most convenient option.

11

Got it… So, sometimes, chroot isn’t in PATH in the rd.break shell, so you could use /usr/sbin/chroot /sysroot instead. If that also fails, we’ll have to try a different route.

Your LUKS setup sounds fine, which suggests the issue really is with the user account.

To save your journalctl output to a USB stick, you need to first find the USB stick’s device name with lsblk; there’s a good chance it’s something like /dev/sdb. Then mount the usb’s primary partition after making a place for it to go: mkdir /mnt/usb && mount /dev/sdb1.

Now, you can tell journalctl to send its output to the mounted usb drive with journalctl > /mnt/usb/boot-journal.txt. Once that’s finished, unmount the drive with umount /mnt/usb and you can share the output here.

12

/usr/sbin/chroot /sysroot failed with No such file or directory.

lsblk gave command not found but /dev/sdb1 was present and seemed most likely to be my stick. However, trying to mount it gave can't find in /etc/fstab, and I found that fstab did not exist (fstab.empty did, if that is of any significance).

In the end I just tried saving the boot journal to a couple of locations on the HD, before finding a location where it didn’t complain, which was directly in/root. I then booted from the live DVD in order to retrieve it, only to find it missing.

Viewing the disk via the live system, I can see /var/log/boot.log. Will this be where journalctl gets the data from?

13

That’s not frustrating at all. :frowning:

As I understand it, journalctl reads from /run/log/journal or /var/log/journal, not boot.log.

Since you have access to the disk via the liveusb, can you check two files after mounting the root partition?

cat /mnt/sysroot/etc/shadow | grep <username>
cat /mnt/sysroot/etc/passwd | grep <username>

Again, just replace <username> with your actual username. :slight_smile:

14

/run/log/journal doesn’t seem to exist.

var/log/journal exists as a folder which contains a single sub-folder with a UID-style name. This folder contains system.journal, which is 8MB and seems to contain binary data, and a number of other *.journal files of the same size and with various timestamps from the last few days since I installed this system, also seeming to contain binary data.

/var/log/boot.log is present and contains readable entries, with a few hundred entries per occasion that I’ve booted up.

/etc/shadow contains my username: wesley:!:20583:0:99999:7:::
/etc/passwd both contain my username: wesley:x:1000:1000:Wesley Gibbard:/home/wesley:/bin/bash

15

Those /etc/shadow results confirms your account was created during setup, but (for some reason) the password was never properly set!

Since your partition is mounted at /mnt/sysroot, you can edit the shadow file directly with openssl. First, generate a password hash with openssl passwd -6 yournewpassword (obviously, make “yournewpassword” your, uh, new password). That command will output a long string of characters.

Next, open the shadow file with nano /mnt/sysroot/etc/shadow, find the wesley line that looks like this

wesley:!:20583:0:99999:7:::

and replace the ! after the first colon with the full hash output from above.

Save the file and reboot; if it worked, you’ll be able to login.

A quick note: Your LUKS password hasn’t changed, so still make sure enter that correctly when asked for it.

16

Maybe because the new KDE installer only sets the password and user account after the system in installed and the user reboots.

17

That’s a good thought!

18

This worked. Thank you very much for the help. Sorry to have dragged it out over a few days but I’ve been busy with other things.

Do I need to file a bug report for this?

19

You should, something went wrong with the installer.

20

Done. 2477902 – Cannot log in after fresh installation of Fedora Jam KDE 44