Aside from the problem with installing, this raises the question of whether anyone other than me is testing ISOs on bare metal at all. Queued for meeting because of this.

I downloaded the Nov 21 ISO from here:

https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161121.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-25-20161121.0.iso

...and wrote it to a USB key. Then successfully booted from the key and installed on an old x86_64 baremetal system I have at my desk.

I also did the same with the latest released ISO found here:

https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161207.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-25-20161207.0.iso

Maybe it is something specific with the minnowboard?

thanks @miabbott, I also just tried out the latest ISO and it works for me.

It also passed the Automated tests in OpenQA https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Atomic&build=Fedora-Atomic-25-20161121.0&groupid=1

This might be UEFI vs bios - if you're using default virt-manager you get BIOS. Some more info here https://fedoraproject.org/wiki/Using_UEFI_with_QEMU

Hmmm. Didn't have issues with 24. Let me retest now that 12/7 is available.

Per atomic-devel list, ISOs are in fact broken for UEFI.

Report from the field:

Last night, I'm try to install Fedora 25 atomic host on UEFI notebook.
But all the time installation finished with error fail to install bootloader.
As I see after this message /mnt/sysimage have no grub files in boot (grub install not put files) also no grub.cfg
I'm try some partition layouts like:
1) part1 - fstype EFI, size 500 /boot/efi
     part2 - lvmpv
     lvmvol - /boot size 500 ext4
     lvmvol - / all size ext4
2) part1 - fstype EFI, size 500 /boot
     part2 - lvmpv
     lvmvol - / all size ext4

Fedora-Atomic-ostree-x86_64-25-20161207.0.iso in virt-manager set to use UEFI; and default automatic partitioning.

program.log

12:04:03,606 INFO program: Running... efibootmgr
12:04:03,647 INFO program: EFI variables are not supported on this system.
12:04:03,648 DEBUG program: Return code: 2
12:04:03,648 INFO program: Running... efibootmgr -c -w -L Fedora -d
/dev/vda -p 1 -l \EFI\fedora\shim.efi
12:04:03,658 INFO program: EFI variables are not supported on this system.
12:04:03,659 DEBUG program: Return code: 2
12:04:03,660 INFO program: Running... grub2-mkconfig -o
/boot/efi/EFI/fedora/grub.cfg
12:04:04,055 INFO program: /usr/bin/grub2-editenv: error: cannot
rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No
such file or directory.
12:04:04,056 INFO program: /sbin/grub2-mkconfig: line 247:
/boot/efi/EFI/fedora/grub.cfg.new: No such file or directory
12:04:04,057 DEBUG program: Return code: 1

However, if I get to a vt and run efibootmgr there is no error. So I'm
not sure why anaconda has a problem running it. The last two errors
likewise don't make sense on their own, so to try and reproduce the
problem I tried:

# chroot /mnt/sysimage
chroot: failed to run command '/bin/sh': No such file or directory

Huh. So that usually works on netinstalls and lives. And /bin/sh does
exist, it's a symlink to bash and /bin/bash does exist also. So I'm
still confused.

Huh. So that usually works on netinstalls and lives. And /bin/sh does
exist, it's a symlink to bash and /bin/bash does exist also. So I'm
still confused.

in this environment bin is a symlink and that symlink isn't set up at this stage:

[anaconda root@localhost tmp]# ls /mnt/sysimage/
boot  dev  etc  home  ostree  proc  root  run  sys  tmp

I'll take this issue.

@kushal - can you make sure we have an OpenQA ISO test for this in the future once this gets fixed. You can use UEFI in KVM/QEMU with --boot uefi parameter.

FYI walters has opened this upstream issue for this problem: https://github.com/rhinstaller/anaconda/issues/900

Anaconda PR with updates.img available: https://github.com/rhinstaller/anaconda/pull/903

A new version of anaconda made it to stable. It has also been tagged such that the next isos that are generated should have the new anaconda in them.

The new anaconda is not making it into the install tree so this probably won't make this week's two week release. Will work with releng to figure out how to get that fixed.

You can also reproduce this issue by installing fedora atomic in qemu+kvm using UEFI BIOS (edk2-ovmf) ;)

We were also affected by this issue and spent a huge amount of time figuring out why the installation fails. Are there any updates from releng?

We were also affected by this issue and spent a huge amount of time figuring out why the installation fails. Are there any updates from releng?

hi @nightvisi0n - due to the recent holidays we didn't have much time to work through the bug in releng that is causing this to be held up. Sorry for the delay

Hey @walters I created an updates.img with your change in it and I'm seeing an issue where the install succeeds but the grub.cfg in the efi partition seems to have the wrong locations for the kernel and initrd.

It has

/ostree/fedora-atomic-0431f592fabc7397b2d571a52edea5853f767078ecc7f155757064f4 035b6c40/vmlinuz-4.8.15-300.fc25.x86_64

when i think it should have:

/boot/ostree/fedora-atomic-0431f592fabc7397b2d571a52edea5853f767078ecc7f155757064f4 035b6c40/vmlinuz-4.8.15-300.fc25.x86_64

I'll note that if I give myself a boot partition (i.e. a filesystem mounted at /boot) then things work ok:

# Partition info
zerombr
clearpart --all
reqpart
part pv.01 --grow
volgroup atomicos pv.01
logvol / --size=3000 --fstype="xfs" --name=root --vgname=atomicos
logvol /boot --size=300 --fstype="xfs" --name=boot --vgname=atomicos

Yeah, merged /boot with ostree doesn't quite work for us yet. See https://github.com/ostreedev/ostree/pull/215

Yeah, merged /boot with ostree doesn't quite work for us yet. See https://github.com/ostreedev/ostree/pull/215

hmm. and that is only an issue on UEFI because I've been doing legacy boot without a /boot partition for a while now. Is the work in that PR pretty close to "ready"? I know how to test it now :)

We were also affected by this issue and spent a huge amount of time figuring out why the installation fails. Are there any updates from releng?

hi @nightvisi0n - due to the recent holidays we didn't have much time to work through the bug in releng that is causing this to be held up. Sorry for the delay

Hey @nightvisi0n, until we get our releng bug fixed you can workaround by doing two things:

• 1st - add updates=https://dustymabe.fedorapeople.org/fixuefi-updates.img to your kernel command line when you boot into anaconda
• 2nd - make sure you have a boot partition in your kickstart file like I showed in https://pagure.io/atomic-wg/issue/185#comment-48712

here is a pungi rfe that will enable us to get the anaconda update in once it is fixed:

@lsedlar is going to work on it tomorrow.

First build is out that contains this fix. Please test:
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170118.1/compose/Atomic/x86_64/iso/

Keep in mind you will need to have a /boot partition in order for this to work. There is an example in the comment from above

VM install of Fedora-Atomic-ostree-x86_64-25-20170118.1.iso to a clean LV succeeds, for both BIOS and UEFI firmware. Using default partitioning, the required layout is created. Both installations completely startup, I can login, docker-pool has been created, and docker is running.

VM install of Fedora-Atomic-ostree-x86_64-25-20170118.1.iso to a clean LV succeeds, for both BIOS and UEFI firmware. Using default partitioning, the required layout is created. Both installations completely startup, I can login, docker-pool has been created, and docker is running.

you're awesome @chrismurphy

@dustymabe I tested this on one of the minnowboards, and it installed and booted fine.

Note that, instead of allocating specific bytes for /boot, you can use this KS command:

reqpart --add-boot

Closing this as the fix is in and will be in the next two week release.