Reproduction steps: 1. Run installer on a laptop with flaky efi that won't accept new boot entries. 2. When installer asks if I want to continue installation despite that, say yes. 3. Finish installation, reboot machine. 4. Have grub2 run correctly, but with no menuentries to boot into (except "UEFI Firmware Settings"), since no configs under `/boot/loader/entries` are present. Expected result: 1. Even when installer encounters errors when editing efi boot entries, the kernel boot config under `/boot/loader/entries` should've been generated to increase the chance system will be bootable. Context: I have an old Acer Spin 1 SP111-32N on which I've just recently installed fedora 36 (kde version). Unfortunately the laptop has a known flaky efi that will not let efibootmgr set new entries correctly[1]. [1] For comparison here's the gymnastics needed to get ubuntu installed on the machine – https://gist.github.com/volcanoauthors/c7c9480dc78f1ba55d589d2125db4832 It appears to me that the installer in effect assumes that if it can't edit efi entries, then that means nothing will work. That's too pessimistic. On my particular machine even with the boot entry not set correctly (it says `Unknown Device`), the Acer Insyde H2O BIOS has a reasonable fallback in that it still looks at the emmc drive, finds the efi partition and runs whatever's present in `EFI/BOOT`. And that fallback is fully sufficient to get a working system as long as there are bls configs for grub to read. Workaround: If you found this via google and are hoping for a solution: 1. Once the installation completes, don't shut down the installer. 2. Open a terminal window, and `sudo chroot /mnt/sysroot` (I think it was /mnt/sysroot…; you can run `df -h` and look at last few entries to verify where your disk is mounted) 3. Regenerate kernel configs with `kernel-install add`. For me with the kernel I have in `/boot` the command looks like: `kernel-install add 5.16.20-200.fc35.x86_64 /lib/modules/5.16.20-200.fc35.x86_64/vmlinuz`. Or you can just `dnf reinstall kernel-core`, but that takes longer. 4. `cat /etc/fstab` and take note of the UUID of the `/` mount point. Say mine is `e8b683a6-f15d-4946-912e-3ca373dd6820` 5. Go to `/boot/loader/entries` and edit the config that's not the rescue to make sure the line starting with `options` is correct. Mine wasn't. 5a. For me the correct line would be (without disk encryption): `options root=UUID=e8b683a6-f15d-4946-912e-3ca373dd6820 ro rootflags=subvol=root` 5b. Or with disk encryption: `options root=UUID=e8b683a6-f15d-4946-912e-3ca373dd6820 ro rootflags=subvol=root rd.luks.uuid=luks-745d007e-e2f5-4b3f-949a-0459faa09099` 5c. You can find the `rd.luks.uuid=...` bit in `/etc/default/grub`. 6. Close the terminal window and now you can complete the installation.
Please, attach all files with installation logs, especially the file named syslog. You can find them during the installation in /tmp or on the installed system in /var/log/anaconda/. If you are gathering the log files manually - outside of the automatic bug reporter - please make sure that either the file syslog or journal.log is included. If you are in the Live CD environment, and neither file exists, please create the journal dump manually by running journalctl > journal.log and attach the file.
Created attachment 1893348 [details] Installer logs Attaching all the /var/log/anaconda logs from the system.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.