Problematic fresh F35 install on HP laptop

Ask Fedora Ask in English
,
1

Situation

I’m using the Fedora 35 KDE ISO on a USB drive to install Fedora as the sole OS on this laptop. The installer throws errors about setting up the bootloader, but allows the installation to continue.

If I try to boot after the install is done, there is not grub entry for my fedora, 2 entries that point to the live session, which of course don’t work.

After a chroot and package reinstall as instructed here, the system is now bootable, but won’t allow me to login. Neither in graphical mode nor in any TTY. After the login, the screen flashes and I’m returned to the login prompt.

I’ve done the install by setting the user as administrator without a password. This implicitly disables the root user.

What I’ve tried

  • reinstalling the system and setting a password for the user
  • set a password for the root user in chroot with LiveCD
  • change the user password in chroot with Live CD
  • logging in as both my user and root from the TTY

None of these allowed me to login.

Logs

I’ve found via chroot in /var/log/messages an error like:

user@1000.service /var/lib/system/systemd failed to start systemd Permission denied

I reproduced this log message from memory.

2

If you have boot loader installed and working i will be try to go level3( past ‘3’ after ‘quiet’ on bootline of your kernel ) just tty and try to login with your user and password.One question did you tick box for administrator for your user when you set up installation ?

3

Yes I did. From chroot I can see that the user is in the wheel group.

I don’t understand what you mean with the level3 part.

I tried editing the grub entry when booting the system and adding tty after quiet. There was no change.

4

No add just 3 after ‘quiet’ and press ctrl + x buttons to boot with added 3 parameter you wil go to login screen

5

Please if you go to login try to login with your user and password and if successfully login just mv .config .config-old and mv .ceche .cache-old and rm .config & rm .cache reboot system and try to normally login

6

OK, got it now. I added the 3 and it took me straight to TTY1. I take it that this stops the systemd targets at multi-user.target and does not run graphical.target anymore, right?

Login attempts for both my user and root are failing. I’m just presented with the login prompt without showing any errors. Just like before.

7

ok run tty3 like ctrl + alt + f3 and try to login like that

8

I’ve already done that, as mentioned in my initial post.

9

Normally you can open tty1,tty2,tty3,tty4,tty5.tty6 with ctrl+alt+F1 to F6
just try tty3

10

I tried them all. Same result: After I hit Enter, I get back the login prompt. No error, no other text.

Sometimes I can get a quick, half a second, look at a 2 line message which says when was my last login. After which I’m back to the login prompt.

11

Ok it is not working this way can you run livecd and open file manager go to other location and select your home volume and select your user

12

Make sure you in preference of file menager select hidden files that will show .config and .cache directories

13

I tried removing those and al other files in my user’s home dir to trigger the regeneration of the user home dir. But that didn’t change anything.

Am I looking for something in particular in there?

14

did you try copy cp /etc/X11/xinit/xinitrc ~/.xinitrc and select plasma on xorg best if you select xorg plasma and like that try to login

15

Sorry to hear of your issues, this must be annoying.
Since you have this unusual large issue in just getting the chance to log in, I’ll go back to the beginning and ask whether you verified the checksums on your installation media. Seems like something went wrong very early.
You mentioned errors from the installer when setting up the bootloader; did you happen to have captured the messages? That seems curious as well.
Not to take you in a completely different direction than @ledeni, but I think if I were troubleshooting, I’d try downloading, verifying, installing Fedora 35 with the Gnome desktop and see what issues occur. That can help narrow down OS specific issues as distinct from KDE. I know KDE is your desired endpoint, so Gnome is just for debugging your basic issue.

17

@mhdave :

I have tried:

  • creating the bootable medium using Balena etcher
  • Creating the bootable medium using Fedora media writer (on another fedora laptop)
    • this does the ISO download and checksum check
  • Check the bootable contents from the live CD grub menu
  • Using F34 and F35 both KDE, which I have both used on other laptops and have had no issues with
    • F34 on this laptop just hangs on the “installing bootloader” step. It hangs for over 24 hours
    • F35 throws an error saying it failed to write the bootloader and that this could be a kernel or firmware bug
      • It threw this error 2 times during the installation process
      • reinstalling shim-* grub2-efi-* grub2-common from chroot, fixed the booting issue
  • Installing a 32bit debian based system ( I think it’s a Lubuntu, but don’t really remember)
    • This worked with no issues. System was running normally.
  • Disabling UEFI (use legacy BIOS)
    • Got UEFI errors from grub2-mkconfig
  • Disabling Secure Boot
    • Got Secure Boot errors from grub2-mkconfig

I’ve installed, reinstalled, chrooted and debugged this for the past 3-4 days.
Found many conflicting Fedora documentation pages that contradict each-other:

  • This says one thing: Bootloading with GRUB2 :: Fedora Docs, and this GRUB 2 - Fedora Project Wiki contradicts it
    • With regards to, but not limited to running grub2-install
  • All documentation talks about a rescue mode for fixing grub, but no Fedora LiveCD, not even the Workstation DVD has a grub entry for rescue. Rescue only exists in the installed system grub entries, which in my case does nothing different. AFAIK that rescue mode just boots an older kernel, which is not the case needed here.
  • regenerating the grub config without mounting the efi partition, the /boot partition, separately the 2 default created BTRFS subvolumes and bind mounting /dev/ /proc /sys and /run, fails.

The documentation is a mess here, and I’d love to fix it, but I’m not confident that I’m right with this. It’s just a “this worked for me” situation at this point.

The current issue at hand is that the login does not work. Anything with the graphical session has no connection to this, since I can’t even login in the TTY.

The only lead I have now is the log message fetched while in chroot from /var/log/messages:

Apr  3 16:16:57 afrodita systemd[1]: Created slice User Slice of UID 1000.
Apr  3 16:16:57 afrodita systemd[1]: Starting User Runtime Directory /run/user/1000...
Apr  3 16:16:57 afrodita systemd-logind[723]: New session 5 of user alessandro.
Apr  3 16:16:57 afrodita systemd[1]: Finished User Runtime Directory /run/user/1000.
Apr  3 16:16:57 afrodita audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=user-runtime-dir@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita systemd[1]: Starting User Manager for UID 1000...
Apr  3 16:16:57 afrodita audit[934]: USER_ACCT pid=934 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="alessandro" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[934]: CRED_ACQ pid=934 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:setcred grantors=? acct="alessandro" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Apr  3 16:16:57 afrodita audit[934]: USER_ROLE_CHANGE pid=934 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 selected-context=unconfined_u:unconfined_r:unconfined_t:s0 exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[934]: USER_START pid=934 uid=0 auid=1000 ses=6 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:session_open grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="alessandro" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[934]: AVC avc:  denied  { transition } for  pid=934 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="sda3" ino=208359 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0
Apr  3 16:16:57 afrodita systemd[934]: user@1000.service: Failed to execute /usr/lib/systemd/systemd: Permission denied
Apr  3 16:16:57 afrodita audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Apr  3 16:16:57 afrodita audit[927]: USER_START pid=927 uid=0 auid=1000 ses=5 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="alessandro" exe="/usr/bin/login" hostname=afrodita addr=? terminal=/dev/tty3 res=success'
Apr  3 16:16:57 afrodita audit[927]: CRED_REFR pid=927 uid=0 auid=1000 ses=5 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="alessandro" exe="/usr/bin/login" hostname=afrodita addr=? terminal=/dev/tty3 res=success'
Apr  3 16:16:57 afrodita audit[927]: USER_LOGIN pid=927 uid=0 auid=1000 ses=5 subj=system_u:system_r:kernel_t:s0 msg='op=login id=1000 exe="/usr/bin/login" hostname=afrodita addr=? terminal=tty3 res=success'
Apr  3 16:16:57 afrodita audit[937]: AVC avc:  denied  { transition } for  pid=937 comm="login" path="/usr/bin/bash" dev="sda3" ino=2472 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0
Apr  3 16:16:57 afrodita audit[927]: CRED_DISP pid=927 uid=0 auid=1000 ses=5 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="alessandro" exe="/usr/bin/login" hostname=afrodita addr=? terminal=/dev/tty3 res=success'
Apr  3 16:16:57 afrodita audit[927]: USER_END pid=927 uid=0 auid=1000 ses=5 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="alessandro" exe="/usr/bin/login" hostname=afrodita addr=? terminal=/dev/tty3 res=success'
Apr  3 16:16:57 afrodita audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=user-runtime-dir@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  3 16:16:57 afrodita systemd[934]: user@1000.service: Failed at step EXEC spawning /usr/lib/systemd/systemd: Permission denied
Apr  3 16:16:57 afrodita systemd[1]: user@1000.service: Main process exited, code=exited, status=203/EXEC
Apr  3 16:16:57 afrodita systemd[1]: user@1000.service: Failed with result 'exit-code'.
Apr  3 16:16:57 afrodita systemd[1]: Failed to start User Manager for UID 1000.
Apr  3 16:16:57 afrodita systemd[1]: Started Session 5 of User alessandro.
Apr  3 16:16:57 afrodita systemd[1]: getty@tty3.service: Deactivated successfully.
Apr  3 16:16:57 afrodita systemd[1]: session-5.scope: Deactivated successfully.
Apr  3 16:16:57 afrodita systemd[1]: getty@tty3.service: Scheduled restart job, restart counter is at 1.
Apr  3 16:16:57 afrodita systemd-logind[723]: Session 5 logged out. Waiting for processes to exit.
Apr  3 16:16:57 afrodita systemd[1]: Stopped Getty on tty3.
Apr  3 16:16:57 afrodita systemd[1]: Started Getty on tty3.
Apr  3 16:16:57 afrodita systemd[1]: Stopping User Runtime Directory /run/user/1000...
Apr  3 16:16:57 afrodita systemd-logind[723]: Removed session 5.
Apr  3 16:16:57 afrodita systemd[1]: run-user-1000.mount: Deactivated successfully.
Apr  3 16:16:57 afrodita systemd[1]: user-runtime-dir@1000.service: Deactivated successfully.
Apr  3 16:16:57 afrodita systemd[1]: Stopped User Runtime Directory /run/user/1000.
Apr  3 16:16:57 afrodita systemd[1]: Removed slice User Slice of UID 1000.
18

And why would I trust that the massive group of respins dated Apr 1 (April Fools) would be correct?

Why should I trust that anything posted with a tinyurl link is official?

Why would you even suspect that is valid and why post such a thing on an official forum that is here to assist users, not mislead them.

AFAIK fedora has never done a respin of any of their final distros in the past, and it certainly seems out of character for them to do so now with the next release just weeks away.

1 Like
19

The “AVC avc: denied” indications for systemd and bash are disturbing, don’t quite know what to make of not having permission for these user startup processes. This is, of course, SELinux giving great protection for your system by denying anyone access. (Sorry, not funny.)
There is a GRUB setting for disabling SELinux. **To permanently disable SELinux:
**

  1. Configure your bootloader to add selinux=0 to the kernel command line: $ sudo grubby --update-kernel ALL --args selinux=0.
  2. Restart your system: $ reboot.

[

Changing SELinux states and modes - Fedora Docs

](Changing SELinux states and modes :: Fedora Docs)

Not a good long term solution, obviously, but might this get you past the inability to log in?

1 Like
20

I tried disabling selinux temporarily from grub by editing the options. I am now able to login. Thank you @mhdave for identifying the dragon. Now to see how to fight it.

21

You can force the system to allow you to boot in single user mode by adding init=/bin/bash to the end of the kernel boot line in grub instead of the ‘3’ that was recommended earlier.

When it boots that way it will be booted to single user mode and actually already be in a root shell (no login required) so you can do recovery actions.

If this is an selinux problem then you might try the command restorecon -vR / to relabel everything properly. You could also set selinux to permissive mode by editing /etc/selinux/config and changing the line that reads SELINUX=enforcing to SELINUX=permissive.

I would recommend you do both since this is such a weird situation.

These changes will put selinux in permissive mode with the next boot and if it actually is selinux blocking the login should allow the system to boot properly. The change to /etc/selinux/config can always be reversed after getting everything to boot properly if you want selinux to be enforcing for you.

1 Like