Description of problem:
I attempted to install Fedora 28 Workstation, Silverblue edition (was: Fedora Atomic Workstation) on bare metal, on two different laptops, using Anaconda.
Regardless of the partitioning scheme (with home on /home or /var/home or without home at all), installation failed.
Version-Release number of selected component (if applicable):
Fedora 28 Silverblue @
This happens every time, on both a ThinkPad X230 and a Dell XPS 13.
I tried all sorts of paritioning schemes (including just /boot/, /boot/efi/, and /); also without network, hostname, and timezones changed (originally I modified these, but figured I'd minimize the changes from default).
Steps to Reproduce:
1. Attempt a bare metal installation with existing partitions.
Fatal error, with the following dialog:
The following error occurred while installing. This is a fatal error and installation will be aborted.
ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] existed with code -6
Installation of Atomic-based Fedora 28.
Same image was used to install successfully in a VM with default partitioning. USB stick was also checked in the installer option.
Twitter thread @ https://twitter.com/garrett/status/993819000005152768
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]
Created attachment 1433553 [details]
Created attachment 1433556 [details]
Created attachment 1433557 [details]
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.