#345 F26: 20171003 ISO does not boot on minnowboard
Closed 7 years ago Opened 7 years ago by jberkus.

  1. wrote Fedora-Atomic-ostree-x86_64-26-20171003.0.iso to usb key (used in prior tests)

  2. ran kickstart install of Atomic using my standard f26 kickstart

  3. install ran

  4. On rebook, system goes through bootup messages and dmesg for around 20 seconds, then without warning reboots. This cycle continues as long as I let it (I counted 5 cycles, then turned it off).

  5. Tested with a new USB key and a different minnowboard. Same result.


Metadata Update from @dustymabe:
- Issue tagged with: F26, bug

7 years ago

i'm trying out on my Intel NUC now. Any other tests by anyone with some bare metal would be appreciated.

i'm trying out on my Intel NUC now. Any other tests by anyone with some bare metal would be appreciated.

Works fine on Intel NUC - will do another hardware test if we can find some.

Works fine on Asus Z87-PRO, Intel i7-4770K CPU

Tested on a beige box under my desk - AMD Athlon 64 X2 5200+ using BIOS

Also ran a VM install via 'virt-manager' using UEFI.

Both worked fine for me.

seems isolated to minnowboard - in the past we decided to go ahead and release and report the minnowboard issue upstream to the kernel. I believe we'll probably do the same here. anyone opposed?

Of the other bare metal devices people tested, were any UEFI?

If we have a pass on a standard UEFI device, then let's release. If we don't, we need to test that.

Of the other bare metal devices people tested, were any UEFI?
If we have a pass on a standard UEFI device, then let's release. If we don't, we need to test that.

I tested on Asus Z87-PRO, Intel i7-4770K CPU in UEFI mode and it installs and boots fine.

my nuc test was on UEFI as well.

  1. Installed 9/20 release, which booted fine.

  2. rpm-ostree upgraded to the current release. Failure-to-boot behavior continued.

  3. rebooted and selected the 9/20 release (26.131)

  4. The system continued to fail during bootup.

  5. No rollback possible.

This is kind of alarming, we may need to warn users.

Further:

Ok, not a total loss: the system could be rebooted with a cold boot (that is, power off and back on). For some reason, a hot reboot would not allow you to roll back. But that means the system is rescueable, and this is less of an alarming issue.

@jberkus - can you rebase to the updates-testing tree to see if the newer kernel fixes the problem?

rpm-ostree rebase fedora/26/x86_64/testing/atomic-host

Well, first, when I switched to testing, I got 26.133. Is that right? Seems like I should get something later than 26.141.

Second, bootup failed. During the initial soft boot, it failed and stuck with a specific message:

docker0: link not ready

On subsequent power-cycle boots, it failed the same as 26.141.

Well, first, when I switched to testing, I got 26.133. Is that right? Seems like I should get something later than 26.141.

The testing tree and updates tree are separate streams. This just means that we've had more failures to build in updates-testing than we've had in updates, which makes sense because testing typically gets the buggy stuff and hopefully it doesn't make it to stable.

Second, bootup failed. During the initial soft boot, it failed and stuck with a specific message:
docker0: link not ready
On subsequent power-cycle boots, it failed the same as 26.141.

This tells me its still a problem with the latest kernel. We'll have to file a bug against the kernel and see what we can find out.

I'm going to close this out. please re-open if someone finds this is still an issue.

Metadata Update from @dustymabe:
- Issue status updated to: Closed (was: Open)

7 years ago

Log in to comment on this ticket.

Metadata