If a BIOS update doesn’t fix it, report a bug against kernel. Maybe shutdown leaves the system in a weird state that doesn’t allow power-on.
There was a recent BIOS update. I’m not sure if that was before or after I installed Fedora. I’ll do some more tests with restarts and power off from Windows too.
1 Like
Where would I find logs that might shed some light on the issue?
I tested booting into Windows with the F12 Boot menu and Windows boots without the charger.
Then if I restart or power off and turn on again and try booting Fedora with the charger disconnected, it still gets stuck on a black screen.
Bug submitted: 2083098 – Dell laptop stuck on boot when booting on battery power
2 Likes
This really sounds like something in fedora that does not like the way power is reported from the battery. I have had similar on my Asus laptop but only when the battery was <15%. In that case it started booting and then shutdown again.
My system expects grub.cfg to be in /boot/efi/EFI/fedora/. Without it I end up with a grub> prompt.
After running these commands I had to copy the grub.cfg file from /boot/grub2/ to /boot/efi/EFI/fedora/
Yes, Fedora expects to find a grub.cfg file at that location. Since fedora 33 that has been a stub file that redirects grub to the actual grub.cfg file located at /boot/grub2/grub.cfg.
System updates only update the file in /boot/grub2 and the links /etc/grub2.cfg and /etc/grub2-efi.cfg both point to that file.
After running which commands?
I doubt you had to copy the file there. You certainly may have chosen to do so.
If you do that it may work once, but then system updates will require you to manually repeat that action for each time the grub.cfg file is automatically updated since that file does not ever get updated by anything except a reinstall of certain parts of grub. Certainly with each kernel update you will have to repeat the copying of grub.cfg. If not you will never be able to access the newly installed kernel.
Following the instructions in the third post above I deleted the /boot/efi/EFI/fedora/grub.cfg file; reinstalled grub2-efi and ran the grub2-mkconfig command as instructed. This didn’t create any grub.cfg file in the /boot/efi/EFI/fedora/ folder and rebooting without that file brought me to a grub> prompt.
The only way I found to make my system boot is to copy the new grub.cfg present under /boot/grub2/ to the /boot/efi/EFI/fedora/ folder using a live USB.
How do I restore the default configuration?
So looking at this page it seems that to recreate the stub at /boot/efi/EFI/fedora/ you have to reinstall grub2-common and not grub2-efi. I tried deleting the grub.cfg I had copied and reinstalled grub2-common and sure enough a grub.cfg file appeared in the folder.
This solved the issue with having the wrong grub.cfg file but didn’t solve the issue of not being able to boot on battery power.
I just discovered a workaround to boot Fedora on battery power. If I press F12 to get to the boot menu, go into the “Change boot options” entry, press Esc, computer reboots and voila! Grub menu shows.
1 Like
I tried removing quiet from /etc/default/grub to see if anything shows up on screen that might hint at what the problem is, but I still got stuck on the Dell logo. It seems the problem arises before even grub launches.
Could it be due to:
- Something wring with EFI
- Relatied to the fact that the
/bootfolder is on a BTRFS file system
What about using a different boot manager? I read about systemd-boot.
Checking with gparted, i do have the boot and esp flag on the fat32 boot/efi partition active.
/boot is ext4 with a size of 1 GB
You can try to fix this and see if this helps.
Can it bee, that you have a second disk with a boot flag on the partition in your system?
I do have problems when i try to boot from such a disk (on usb).
I have to deactivate EFI in my bios first, that i can boot from it.
Check your bios settings for such a miss configuration.
From gparted I see that the only partition with the boot flag is the efi or esp partition. I don’t have any other internal disks on my system.
I don’t have a separate boot partition at the moment and, after looking around the internet, didn’t find instructions on how to safely create one without remaining locked out of the system. I can resize a partition, create a 1Gb ext4 partition using a liveUSB. I would need to add an entry to the fstab file, but about how to shift the kernels, etc, and reconfigure grub safely, I’m not sure how to go about it.
I’ll check my BIOS to see if there is anything that looks strange under boot options.
I’m trying to check if the problem is related to Secure Boot. I’m following this doc
I ran mokutil --sb-state and as expected I got SecureBoot enabled. Then I tried running sudo keyctl list %:.system_keyring and got Can't find 'keyring:.system_keyring'.
Is there something wrong with my system’s secureboot keys or am I doing something wrong?
I discovered I was looking at old documentation for Fedora 26! Running the commands found here, i.e. sudo keyctl list %:.builtin_trusted_keys I get only one key labelled asymmetric: Fedora kernel signing key: [long number].
The documentation shows a longer list.
If I run sudo keyctl list %:.secondary_trusted_keys I get: [9-digit number]: ---lswrv 0 0 keyring: .builtin_trusted_keys
Is there something wrong with my keys and how do I go about fixing them? Why aren’t the Windows keys showing?
This is not a good idea. The cleanest way for fedora to install and boot, and the default installation gives an efi (esp) partition that is formatted vfat and mounted at /boot/efi so no additional modules are required for grub to access and boot the system.
Additionally there should be an ext4 partition mounted at /boot. Again that is created with the auto install and so no additional modules are required for completing the boot process. When the kernel is actually loaded it loads the modules required to access the btrfs file system.
How this relates to the issue of hanging at the logo when booting from the battery I cannot say.
When I installed Fedora, it was not at all clear what an automatic installation would do and I wanted to replace my Ubuntu install with removing Windows. Anaconda is confusing to me. So a search suggested setting up a root partition and linking /boot/efi to the esp partition which is what I did. I didn’t create a separate /boot partition.
That said, I tried disabling secure boot and rebooting and the system rebooted properly twice in a row. I re-enabled secure boot and it rebooted properly again. Let us see if this simple trick solved the issue or if the issue returns.
Powering off the laptop and rebooted and the problem returned.
How do I create a separate /boot partition safely?
I would:
- Boot from a live USB and create a new 1 Gb partition formatted as ext4. Let us call it
/dev/nvme0n1p8and mount it say at/media/boot - rsync /boot to that partition and delete the /boot/efi folder (that I imagine rsync will copy) from the new partition with
rsync -avz /path/to/boot/on/root /media/boot - Move the original /boot to /boot.orig just in case with
mv /path/to/boot/on/root /path/to/boot/on/root.orig - Check the UUID of the new boot partition with
sudo blkid - Create an fstab entry for /boot like this:
UUID=123456789 /boot ext4 defaults 0 0 - Then I imagine I have to somehow recreate grubconfig file. Can I reinstall grub using a liveusb? Not sure how though.
- Reboot
If my system boots, then I should be able to delete the original /boot.orig folder in the root partition. Otherwise I would have to reverse the above process to return to the original configuration.
I created a separate /boot partition and the problem remains.
Then I entered the BIOS configuration utility and added a 5 second POST delay (intended for reading any messages). It seems that the issue has been solved. I’ll confirm after a few more reboots and power offs.
I realised that even though I had a separate boot partition, the system was booting from the kernels in the boot folder on the root partition. After fixing this issue the system is booting properly with the 5 s post delay.