Bug 1575957

Hmm, we couldn't reproduce this.

> 1. Attempt a bare metal installation with existing partitions.

Did you use the automatic option and then reclaim space? ("Automatic" option, "Reclaim Space" and "Delete All").

If you can, could you boot with inst.nokill=1 and once the installer exits after the error, check if there's more information in program.log?

You can also alt-f2 or so at the error dialog and get a shell with logs.  One trick is to insert a USB stick and copy them there, or upload them to a pastebin if you have internet.

I used the normal partitioner.

My computers use normal partitioning, as it doesn't make much sense to use LVM on a laptop.

At one point, I did try the reclaim space method — but it's mostly useless, as I can't identify partitions* in it and I really don't want to nuke the wrong one.

(* The partitions in question are LUKS encrypted and, as a result of a poor decision in the UI, do not show the amount of space used.)

I managed to grab a bunch of logs from the last install I did — I'll attach a few.

Created attachment 1433551 [details]
anaconda.log

Created attachment 1433553 [details]
program.log

Created attachment 1433556 [details]
storage.log

Created attachment 1433557 [details]
syslog

So, the interesting bit is:

```
07:40:17,311 INF program: Running... ostree admin --sysroot=/mnt/sysimage deploy --os=fedora-workstation fedora-workstation:fedora/28/x86_64/workstation
07:40:25,419 INF program: Relabeling /var (no stamp file 'var/.ostree-selabeled' found)
07:40:25,420 INF program: **
07:40:25,420 INF program: OSTree:ERROR:src/libostree/ostree-bootloader-grub2.c:354:_ostree_bootloader_grub2_write_config: assertion failed (deployments->len > 0): (0 > 0)
07:40:25,421 DBG program: Return code: -6
```

Not sure what to make of this yet.

Offhand, I think this symptom happens when reusing an existing /boot partition.  Something like the bootloader symlink not being right?

In general supporting the "dual boot with classic" is something where we've hovered at 90% working, but the last 10% details get hard.

Created attachment 1434481 [details]
coredump of ostree admin deploy

I've ran into the same issue. I tried to replace my Fedora 28 workstation with Silverblue.

I saw the bootloader_grub2_write_config error, removed /boot/efi/EFI/fedora and tried to install again. no luck. same error.

"tried to replace": I ran the ISO installer from USB and re-formatted every partition but the home data partition.

This is a shot in the dark, though could you check if /boot/loader/grub.cfg exists, and if so then delete/rename it. OSTree uses this file to determine whether the system is BIOS or EFI.

Created attachment 1434498 [details]
program.log (failing on grub2-mkconfig)

/boot/loader/grub.cfg did not exist. 

But there was /boot/efi/EFI/ubuntu which contained a grub.cfg (its a dell notebook which was pre-installed with Ubuntu). I've now removed this one too.

And now according /tmp/program.log the ostree admin deploy command succeeds.

but fails with another issue:

```
14:05:49,452 INF program: Running in chroot '/mnt/sysimage/ostree/deploy/fedora-workstation/deploy/ef3d3262fe9c62d20e18637d656943a285530363060696ece175f2313683003d.0'... grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
14:05:49,901 INF program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
14:05:49,902 INF program: /sbin/grub2-mkconfig: line 249: /boot/efi/EFI/fedora/grub.cfg.new: No such file or directory
```

/boot/grub2/grubenv is a symlink to /boot/efi/EFI/fedora/grubenv and the /boot/efi/EFI/fedora directory does not exist.

running `mkdir /mnt/sysimge/boot/efi/EFI/fedora` and then again re-installing made the installer complete. 

but the system won't boot. I don't think grub was installed correctly.

the grub EFI issue is that the binaries are copied to /boot/efi/EFI/EFI instead to /boot/efi/EFI. sounds like "cp -R /usr/lib/ostree-boot/efi/EFI /boot/efi/EFI" which then creates /boot/efi/EFI/EFI.

Can confirm with same error
Installation fails with

18:15:16,461 INF program: OSTree:ERROR:src/libostree/ostree-bootloader-grub2.c:354:_ostree_bootloader_grub2_write_config: assertion failed (deployments->len > 0): (0 > 0)
18:15:16,461 DBG program: Return code: -6

Just creating new / ext4 partition and providing existing boot/efi, because other OSes live on notebook

*** Bug 1635514 has been marked as a duplicate of this bug. ***

Also having this issue.

Just to clarify - this occurs despite using a cleanly formatted /boot partition and removing the existing Fedora EFI entry at /boot/efi/EFI/fedora.

This bug is preventing me from installing Silverblue --  I am also installing to a fresh boot partition.

I ran into this as well when trying to install Silverblue on a machine that was previously booting both Fedora28 and Windows 10.

I didn't try to preserve anything from the old Fedora28 install -- I reclaimed the old fedora boot partition. However, I did not reclaim the EFI partition (as I don't want to do anything that might break that system's Windows install). The old boot/efi contents are present in /mnt/sysimage/boot/efi/EFI/fedora during the install process, including my grub.cfg file from Fedora 28.

I tried moving the old fedora folder aside and manually attempting to ostree admin deploy, but it did not help -- I still get the same error.

I was eventually able to get it installed.

I tried a number of different things -- I was able to make some progress (getting past the ostree-admin deploy fatal error), but ultimately continued to run into problems where it wouldn't generate a bootable fedora installation.
I tried manually fixing it with chroot, but ran into some difficulties.

However, what did work was simply doing manual partitioning, and creating an entirely new EFI partition. I have one EFI filesystem used by Windows (with some remnants from my old Fedora install), and an entirely separate one for Silverblue. Afterwards, the install worked fine. The only drawback I can see is losing like 100 MiB of disk space, which is fairly trivial.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I am getting this same error with the Silverblue 30 installer.

This laptop earlier had Silverblue 28 on it with a separate /var/home. Initially I tried installing by reformating every partition except /var/home and the EFI partition, but that failed with this error. Then I tried wiping all partitions and re-creating from scratch which again ran into this error.

Since this wasn't a dual boot, but just an attempt to do a clean Silverblue 30 installation over SB28, my workaround was to ensure that the EFI partition was reformatted.

Apparently, earlier, even when I had told Anaconda to re-create all the partitions from scratch, it wasn't reformatting the EFI partition.

(In reply to Thomas Mueller from comment #15)
> the grub EFI issue is that the binaries are copied to /boot/efi/EFI/EFI
> instead to /boot/efi/EFI. sounds like "cp -R /usr/lib/ostree-boot/efi/EFI
> /boot/efi/EFI" which then creates /boot/efi/EFI/EFI.

Seems this is a culprit of the problem. Anybody tried to find the place in the code where it happens?

The fix:
https://github.com/rhinstaller/anaconda/pull/2329

that PR above solves part of the problem - it will work when first OS doesn't use grub for boot (i.e Windows).
If grub.cfg exists in EFI directory of the first OS - there is still error at install time.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
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
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Please, change the version - it still present on Fedora SB 31, and probably 32 too, since the fix was not merged.

I know it's there in 31 but I've not done a new install of 32 so bumping to 31. Someone else can confirm it's still there in 32 and bump it further.

I can confirm that this bug is still present in SB 32

I can confirm it's still there in the SB 32 release version.

I can also confirm bug is there in SB 32 downloaded today.

Also confirmed for SB 33 using: 
Fedora-Silverblue-ostree-x86_64-Rawhide-20200524.n.0.iso

Created attachment 1691672 [details]
The fix (see Detail)

Comment on attachment 1691672 [details]
The fix (see Detail)

The fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1575957#c26
https://github.com/rhinstaller/anaconda/pull/2329

Comment on attachment 1691672 [details]
The fix (see Detail)

https://bugzilla.redhat.com/show_bug.cgi?id=1575957#c26

(In reply to Andrey from comment #26)
> The fix:
> https://github.com/rhinstaller/anaconda/pull/2329

FYI, it's merged now.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
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
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Bumping to 32. Can someone confirm this is fixed in 33? Thanks!

Still the very same issue with Fedora Silverblue 33 if you don't reformat the EFI partition (I still don't know if formatting EFI is something I should do or not). If the target folder /boot/efi/EFI exists while installing, the installer aborts with a error that "ostree admin --sysroot=/mnt/sysimage deploy ..." exited with 1. running the command with "--verbose" says "grub2-mkconfig" failed.

Workaround: 
* after creating the disk partitioning and before starting the installation process
* switch to a shell (Ctrl-Alt-F2)
* mount the EFI partition somewhere
* rename the EFI folder
* umount
* start installation process.

Thanks Thomas for trying it.
We had two issues here with similar symptoms, and you faced with not the one I fixed.
IIRC, as a workaround you could also just rename existing grub's config file in EFI dir.
It would be good if you could confirm.

I'm not familiar with that problem details, hopefully someone can say more.
Please, bump to 33.

This is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1483818.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
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
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This is still a problem in Fedora 34

(In reply to Thomas Mueller from comment #41)
> Workaround: 
> * after creating the disk partitioning and before starting the installation
> process
> * switch to a shell (Ctrl-Alt-F2)
> * mount the EFI partition somewhere
> * rename the EFI folder
> * umount
> * start installation process.

Direct commands after partitioning, before "Begin installation":
# mkdir /boot-temp
# mount /dev/sda1 /boot-temp
# rm -r /boot-temp/EFI/fedora
# umount /boot-temp

Then Ctrl+Alt+F6 to return to installation menu. Begin the installation.


---

This applies if you're trying to install a single Fedora installation over another Fedora installation.

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Still a problem on Fedora Silverblue 36

(In reply to James Baxter from comment #46)
> (In reply to Thomas Mueller from comment #41)
> > Workaround: 
> > * after creating the disk partitioning and before starting the installation
> > process
> > * switch to a shell (Ctrl-Alt-F2)
> > * mount the EFI partition somewhere
> > * rename the EFI folder
> > * umount
> > * start installation process.
> 
> Direct commands after partitioning, before "Begin installation":
> # mkdir /boot-temp
> # mount /dev/sda1 /boot-temp
> # rm -r /boot-temp/EFI/fedora
> # umount /boot-temp
> 
> Then Ctrl+Alt+F6 to return to installation menu. Begin the installation.
> 
> 
> ---
> 
> This applies if you're trying to install a single Fedora installation over
> another Fedora installation.

I can't install Fedora Silverblue 36 because of this bug.
The mentioned workaround doesn't work for me, there is no /boot-temp/EFI/fedora file.

This _should_ work, but you might have to change the /dev/sda1 to your boot partition which might be named something else like /dev/nvmep1

Check the partitions with `lsblk` or `ls /dev/`

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
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 '35'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 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 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 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.

I installed Fedora Sericea successfully, bounced off of Sway, and then attempted to install Silverblue 39 and ran into the same error.  Having a footnote in a doc about it (https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/#_unable_to_install_fedora_silverblue_on_efi_systems) is helpful, but finding it *after* things have gone wrong isn't the best.

My solution was to hit Control-Alt-F2 to get a recovery shell, rm -rf /mnt/sysroot/boot/efi/efi/fedora and then reboot for another install attempt which worked.

Issue still present in Fedora Silverblue 39 installer. Reproduced on a laptop with Windows 10 Home installed. The workaround "Reformat the EFI partition on the host during the install process." worked for me.

Reopening.

Clarification on the above, the sequence of events was this:

 0. Laptop has Windows 10 Home installed
 1. Install Fedora SB40 Beta, which installed successfully, but did not boot - on reboot it went straight to emergency mode.
 2. Install Fedora SB39, which failed to install due to `ostree admin deploy` failure
 3. Retry install, setting "Reformat" option on EFI partition, which succeeded.