Ok, things get worse. If I rpm-ostree rebase to the current tree, the system will not boot.

I'm thinking it's the kernel.

• after rebase, in the grub prompt can you select the old deployment and the system does boot?
• we introduced the microcode_ctl package in this release. I wonder if that is causing issues. Can you run the same test except this time when you rebase run these commands:

sudo rpm-ostree rebase fedora/26/x86_64/updates/atomic-host
sudo rpm-ostree ex override remove microcode_ctl
sudo reboot

Rollback works fine.

System does not boot after removing microcode.

@jberkus - in that case can you install plain fedora 26 server on one of these minnowboards and then do a dnf update -y and verify you can't boot. Basically we think it's the kernel and this test will help us know it's not something related to atomic host.

If you want to try reverting the kernel, but keeping the rest of the userspace, editing the grub config should work too.

Fedora Server boots with Kernel kernel-4.12.8-300.fc26.x86_64

So, pulling from update as of today works due to new kernel.

What do we want to do about this in terms of releases?

The next two week will pick it up and anyone who's hitting the issue can run an older commit or the newer commit from the updates ref.

@jasonbrooks +1

@jerkus this was a very interesting case - and also one that needed you to boot using the grub menu into the old system and then run things from there. Could we possibly get you to blog about this experience?

Yah, seems worth a writeup.

I can't blog this because the rpm-ostree functionality appears to be broken. See issue:

https://github.com/projectatomic/rpm-ostree/issues/955

fixed in today's release