Bug 1483818 - OSTree fails to install during deployment phase on UEFI systems with existing operating systems
Summary: OSTree fails to install during deployment phase on UEFI systems with existing...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: ostree
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1635831 1896687 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-22 03:51 UTC by Victor Hugo
Modified: 2021-08-10 12:45 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)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1482922 0 unspecified CLOSED grub2 symlink handling causes FAH installer failures under UEFI systems 2021-02-22 00:41:40 UTC

Internal Links: 1482922

Description Victor Hugo 2017-08-22 03:51:06 UTC
Description of problem:

OSTree's grub2 integration causes it to fail during the deployment phase.


Version-Release number of selected component (if applicable):
ostree-2017.9-2.fc26

How reproducible:

Always.

Steps to Reproduce:
1. Obtain OVMF firmware from repositories
2. Create VM with OVMF as UEFI firmware
3. Acquire atomic host image
4. Install image to system
5. Preserve EFI partition
6. Install again

Actual results:

00:29:34,474 INFO program: Running... ostree admin --sysroot=/mnt/sysimage init-fs /mnt/sysimage
00:29:34,491 DEBUG program: Return code: 0
00:30:35,549 INFO program: Running... ostree admin --sysroot=/mnt/sysimage os-init fedora-atomic
00:30:35,804 INFO program: ostree/deploy/fedora-atomic initialized as OSTree root
00:30:35,804 DEBUG program: Return code: 0
00:30:35,805 INFO program: Running... ostree admin --sysroot=/mnt/sysimage deploy --os=fedora-atomic fedora-atomic:fedora/26/x86_64/atomic-host
00:30:40,565 INFO program: Relabeling /var (no stamp file 'var/.ostree-selabeled' found)
00:30:40,566 INFO program: **
00:30:40,566 INFO program: OSTree:ERROR:src/libostree/ostree-bootloader-grub2.c:365:_ostree_bootloader_grub2_write_config: assertion failed (deployments->len > 0): (0 > 0)
00:30:40,566 DEBUG program: Return code: -6

Expected results:

Installation completes instead of failing during deployment phase

Additional info:
Only happens in UEFI installations, affects 26, 27, rawhide, should affect 25 but wasn't tested as time of bug report

Comment 1 Dusty Mabe 2017-08-22 22:43:35 UTC
I was able to reproduce this.

Comment 2 Jonathan Lebon 2017-08-23 13:23:28 UTC
I can reproduce this as well. I hit it while trying to reproduce https://bugzilla.redhat.com/show_bug.cgi?id=1482922.

Comment 3 Colin Walters 2017-08-23 13:28:04 UTC
With what ISO?  Reproduce in a VM or on bare metal?  Any custom partitioning?  With another OS installed or clean disk?

Comment 4 Jonathan Lebon 2017-08-23 14:30:35 UTC
I did this on VM from the latest stable ISO (20170807). I used "Custom" on the first install to make the VG only take up half of the disk. I used "Automatic" on the second install to let it fill the second half of the disk.

Seems like at some point during the second install, we lose the loader --> loader.N symlink, which then confuses ostree when it tries to find existing entries.

Comment 5 Colin Walters 2017-08-23 14:33:30 UTC
I suspect in this scenario Anaconda is sharing `/boot` between the two.

Comment 6 Dusty Mabe 2017-08-23 14:36:35 UTC
in my scenario I installed atomic host (all defaults) on a UEFI VM. Then run another install and this time do custom partitioning. Delete all partitions except `/boot/efi/` (i.e. allow /boot/efi to be re-used) and continue with the install. You'll see a failure. 

can we remove the link between this bug and https://bugzilla.redhat.com/show_bug.cgi?id=1482922 ?

Comment 7 Fedora End Of Life 2018-02-20 15:25:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 8 René Kraneis 2018-10-06 13:10:21 UTC
*** Bug 1635831 has been marked as a duplicate of this bug. ***

Comment 9 René Kraneis 2018-10-06 13:13:31 UTC
Still happens with Silverblue 29 beta 1.5 on "bare metal" as mentioned in bug #1635831.

Comment 10 René Kraneis 2018-10-06 13:17:13 UTC
Also this happens regardless of sharing of /boot between previous (F28) and new (SB29) install.

Comment 11 René Kraneis 2018-10-28 17:03:47 UTC
Still happens with latest installation media Silverblue 29 1.2.

Comment 12 Andy Richardson 2018-11-03 20:59:09 UTC
This still happens on the recent Fedora 29 Silverblue stable release.

For reference, further discussions on this issue can be found below:

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

https://discussion.fedoraproject.org/t/fedora-29-silverblue-stable-fatal-error/654

https://ask.fedoraproject.org/en/question/128325/installation-fails-bootefi-cant-be-mounted/?answer=128349#post-id-128349

Comment 13 Andy Richardson 2018-11-03 20:59:34 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1575957

Comment 14 jkliop 2019-02-22 08:59:28 UTC
I was able to work around this by manually creating a new EFI partition during the install.

That is to say, I have an initial EFI partition (which is used by my preexisting operating system), as well as a second EFI partition which is used by Silverblue.

This let the installation proceed successfully, and I still get to dual boot. It only costs me about 100 MiB of disk space, and an uglier partition layout.

Comment 15 Ben Cotton 2019-05-02 19:52:24 UTC
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.

Comment 16 Micah Abbott 2019-05-03 18:08:54 UTC
Bumping to F30;  we're still seeing reports of this from users.

Comment 17 Andrey 2020-02-20 12:23:40 UTC
Fedora Silverblue 31, the same issue. Please bump.

Comment 18 Andrey 2020-02-20 14:43:04 UTC
(In reply to Andy Richardson from comment #13)
> https://bugzilla.redhat.com/show_bug.cgi?id=1575957

It's the same issue indeed, so probably we should close one of these as duplicate.

Comment 19 Andrey 2020-02-21 17:50:42 UTC
The fix:
https://github.com/rhinstaller/anaconda/pull/2329

Comment 20 Ben Cotton 2020-04-30 20:24:51 UTC
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.

Comment 21 Andrey 2020-05-01 01:02:47 UTC
Please bump version to 31 or 32

Comment 22 Henrique Ferreiro 2020-11-30 11:09:45 UTC
*** Bug 1896687 has been marked as a duplicate of this bug. ***

Comment 23 Fedora Program Management 2021-04-29 15:53:32 UTC
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.

Comment 24 Ben Cotton 2021-08-10 12:45:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.


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