Broken boot/login after Windows 10 > 11 reinstall | Luks for home & root

After days in trying and reading I am asking help because I ran out of ideas regarding not being able to access Fedora 37 on my AMD laptop with Fedora37/Win11.

Situation and my actions before the problem occurred (click to open the spoiler)

I was using Fedora since almost a year with no issues on my dual-boot setup. I had Windows 10 only first, then I installed Fedora 36 alongside (later upgraded to 37). A few days ago, due to a problem of Bitlocker (Windows10 changed by itself the ID of my machine, so the credential I saved were useless), I clean installed Win11Pro from .iso on the same partition where Win10 was located, overwriting it basically. Luckly there were just a few games there.

Win11 installed fine, overwriting the EFI partition, so I could only access Win11 on boot. I was expecting this, hence, I used Fedora37 live-usb to chroot into my Fedora system and after trial and errors I finally managed to reinstall grub and EFI boot option correctly. Initially was not able to regenerate grub2 config because I was mounting my partition incorrectly (here how to do it), but then I managed and everything worked. More precisely, during chroot, I

1. dnf update (because config regeneration did not work initially so, silly me, I thought that updating could solve something. it updated ~500MB of stuff, kernel included)
2. removed old grub.cfg files, changed EFI partition UUID in fstab, reinstalled grub* and shim* (basically reading here and the docs).
3. performed a dracut command to regenerate and forcely replace the initfs thing.
4. sync & exit chroot, checked efibootmgr and all was good to go.

After shutting down live-usb, I had my grub2 screen back again!!


Right now, however, starting Fedora does not succeed, that is, I am unable to get to login screen. I boot it (no matter which kernel of the 3), I put my luks password as I have home&root encrypted, unlock it, then the boot process starts and stucks after a while.

Moreover, I am unable to login via tty because at the login prompt I put my “root” user and my password, but it just refreshes the screen and ask me to login again. I also tried another user I have on my system but same results… Typing an incorrect password gives the error of incorrect password, but the correct one does nothing. Yes, I have also tried to change the password in chroot, and indeed I changed it but it does not work anyway.
Rescue mode does not work because it says that my root account is locked. I have not explored emergency mode well enough, though.

Trying to boot with parameters: rd.shell rd.timeout=30 systemd.debug.shell=1 3 (found somewhere here in the forums) seems not working (sometimes it just get stuck, sometimes I am able to write some commands but most of them are not found).

Observing the boot log normally, I see appearing for around 10 times in different positions: [FAILED] Failed to start accounts-daemon.service - Accounts Service. See 'systemctl status accounts-daemon.service' for details. Then the boot stucks at Gnome Display Manager. You can check better in the boot log I found while chrooting in /log folder: https://pastebin.com/bQ7fvqMe

Journalctl, when checked via chroot, does not save logs since 2 months, but somehow it saved one of today: https://pastebin.com/YZWE2Md4

I am not a linux expert by any means and hopefully in the journalctl log there is something useful. Could login/authorization/permission mechanisms have gone corrupted in my installation? I am wondering if this could be the issue and if yes so how to reset them, or via boot parameters, or via chroot.

Moreover, since last time I tried chroot again, I updated some packages and since that moment the laptop does not shutdown, it reboots as soon is turned off via power button or even when using windows11. Only a forced shutdown works (keep power button pressed for 5sec). But I can’t tell what caused the issue to arise.

Anyway, this is a screenshot of my partition during a chroot operation with all the needed partition mounted:

Thank you in advance

Ciao @undigi

I suspect that selinux could be involved.

Dec 28 02:47:59 dora audit[1740]: AVC avc:  denied  { mounton } for  pid=1740 comm="(s-daemon)" path="/run/systemd/unit-root/proc/1740/loginuid" dev="proc" ino=27085 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=file permissive=0

Could you try to boot adding this parameter to GRUB?
enforcing=0

1 Like

You are correct, it finally booted and I am in, so happy it booted as I was trying since days :sweat_smile:

But now. How to repair the system, check if everything is in order and let it boot with enforced?

Determined that the issue was SELinux, you can restore the context and permissions with:
sudo touch /.autorelabel

Then reboot normally. (The boot process may take a little longer than usual).

1 Like

Yes it worked, I booted into my system using the boot parameter enforcing=0 and then in terminal I wrote sudo touch /.autorelabel as you suggested and I am finally back to normal state. I suppose that last command could have been issues also while I was in chroot.

To recap, Windows installation interferred with EFI partition by removing grub, changing UUID of that partition and seems like selinux was also involved in the process. Checking selinux was my missing step to restore everything.

2 Likes