Bug 1955936 - Netinstall Error: Failed to Write Boot Loader Configuration
Summary: Netinstall Error: Failed to Write Boot Loader Configuration
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 34
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Javier Martinez Canillas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-01 14:57 UTC by ghborrmann
Modified: 2021-05-08 21:30 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
/tmp/syslog after error (2.49 MB, text/plain)
2021-05-01 15:09 UTC, ghborrmann
no flags Details

Description ghborrmann 2021-05-01 14:57:19 UTC
Description of problem:
Installation fails near the end with a screen saying "failed to write boot loader configuration".  The computer is left in an unbootable condition.


Version-Release number of selected component (if applicable):
Fedora-Server-netinst-x86_64-34-1.2.iso

How reproducible:
Always

Steps to Reproduce:
1. Boot from DVD burned with above netinstall iso.
2. Choose XFCE and install to a partition
3. Installer stops after successful download & installation of packages

Actual results:
A screen pops up with the message:
"The following error occured while installing the boot loader.  The system will not be bootable.  Would you like to ignore this and continue with the installation?

failed to write boot loader configuration"

As predicted, the computer will not boot.


Expected results:
Completion without error; the computer boots to the new system.


Additional info:
Examination of the journal showed that the error occurred during execution of grub2-mkconfig, with the message:
/usr/sbin/grub2-probe: error: ../grub-core/kern/fs.c:120:unknown filesystem

I chose the option to complete the installation, and tried to boot the new system.  The boot failed, and took me into a grub shell.

I then booted from the DVD, choosing to recover the new system.  I chrooted into the new system and executed grub2-mkconfig.  It failed with the same grub2-probe error.

My system has multiple Fedora systems, so I booted my Fedora 33 partition, chrooted into the new F34 system, and executed grub2-mkconfig with no errors.  I don't understand this: the two environments should be almost identical.

Some other information which might be pertinent:
My computer uses Secure Boot, and is able to boot to different Fedora systems because each has a separate entry in efibootmgr which points to its own subdirectory under /boot/efi/EFI.  Each of the Fedora systems exists in a separate partition of /dev/sda; there is also a Windows 10 system on that disk.

Comment 1 ghborrmann 2021-05-01 15:09:49 UTC
Created attachment 1778164 [details]
/tmp/syslog after error

Comment 2 Vendula Poncova 2021-05-03 09:09:24 UTC
Reassigning to grub.

Comment 3 ghborrmann 2021-05-04 21:59:40 UTC
I have traced the problem to grub2-probe.  The script tries to execute:
     grub2-probe --device /dev/sda1 --target=fs
/dev/sda1 is the EFI partition.  The result of the above command is
     grub2-probe: error: ../grub-core/kern/fs.c:120:unknown filesystem.

I can now explain the reason why grub2-mkconfig worked when I first managed to get into the new system.  Apparently what was installed originally by anaconda was grub2-tools-minimal-2.06~rc1-3.fc34.x86_64, and this version of grub2-probe does not have this bug.  When I installed grub2-breeze-theme, dnf installed grub2-tools-minimal-2.06~rc1-4 as a dependency.  Executing this version of grub2-probe produces the error.

Comment 4 ghborrmann 2021-05-08 21:30:36 UTC
I have identified the cause of the problem.  It occurred because the EFI partition contained a file (FSCK000.REC) with a zero time stamp.    I'm guessing that the file was probably generated at boot time after a system crash.  After changing the time stamp with touch, grub2-mkconfig executed successfully.

What needs to be done:  the function grub_fat_timestamp() in grub-core/fs/fat.c returns the time stamp, but uses zero as an error return.  The function needs to deal with the fact that the time stamp could be zero.  I have changed the severity to low because I think it unlikely that many users would ever encounter this situation.  However, when it happens the user has no clue about how to work around the problem.  Even the -v option of grub2-probe gave no hint of what was wrong.  At the least, some informative error message should be generated.


Note You need to log in before you can comment on or make changes to this bug.