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 @ http://download.fedoraproject.org/pub/fedora/linux/releases/28/AtomicWorkstation/x86_64/iso/Fedora-AtomicWorkstation-ostree-x86_64-28-1.1.iso How reproducible: 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. Actual results: 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 === Expected results: Installation of Atomic-based Fedora 28. Additional info: Same image was used to install successfully in a VM with default partitioning. USB stick was also checked in the installer option. Twitter thread @ http://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] 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: http://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: http://bugzilla.redhat.com/show_bug.cgi?id=1575957#c26 http://github.com/rhinstaller/anaconda/pull/2329
Comment on attachment 1691672 [details] The fix (see Detail) http://bugzilla.redhat.com/show_bug.cgi?id=1575957#c26
(In reply to Andrey from comment #26) > The fix: > http://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 http://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 (http://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.
Had Fedora 40 sway installed properly a first time, but wanted to re-install it. Ran into the same issue. Without formating the original /boot/efi, or creating another, I removed any non windows file from efi/boot (leaving only BOOTX64.efi) and also removed efi/fedora sub-directory. Also removed existing fedora parition just in case. It worked and I could properly re-install Fedora. Maybe this has to do with re-writing some files into the efi partition.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-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 'version' of '39'. 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 39 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.
Please bump the version
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
(In reply to Andrey from comment #27) > If grub.cfg exists in EFI directory of the first OS - there is still error > at install time. Workaround for Kickstart file, insert this section: %pre # fix ESP install mount PARTLABEL='EFI System Partition' /mnt rm -v /mnt/EFI/fedora/grub.cfg umount /mnt %end