#2354 32-bit ARM installer release-blocking status unclear
Closed: Accepted 4 years ago by zbyszek. Opened 4 years ago by adamwill.

We ran into an interesting situation during Fedora 32 Beta blocker review. This bug renders fresh 32-bit ARM installs unbootable. It would clearly be a release blocker...except that no installer images are listed as release blocking for 32-bit ARM. There is a release-blocking 64-bit ARM installer image, and there are release-blocking 32-bit ARM disk images (that do not use anaconda to deploy).

So technically speaking, right now, we don't have a justification to block on installer issues that are specific to 32-bit ARM, like this one. However, @pwhalen pointed out this is potentially an issue, on the basis that we use installer images to deploy builders.

I see a few options:

1) Throw the 32-bit ARM Everything netinst on the release-blocking images list
2) Declare that we're fine with this and 32-bit ARM installer issues really don't block release
3) Don't put any images on the release-blocking list but still block on installer issues anyway, massaging the release criteria text to somehow back this up

What do folks think? Also tagging @pbrobinson , please tag anyone else who's likely to have an opinion...


I'd be inclined to go for 1). There's still a lot of arm32 hardware out there that people use Fedora on.

@zbyszek note, we do have 32-bit ARM disk images in the release-blocking list, and those would usually be what you would use to deploy to real hardware. The installer images would usually only be used to deploy VMs.

I also like 1. It would be anoying to somehow have a release that couldn't be kickstart installable for our armv7 builders.

I also like 1. It would be anoying to somehow have a release that couldn't be kickstart installable for our armv7 builders.

Hmm, I was all set to vote for 2) until I read this. If our builders are relying on kickstart installs, it seems to me like that's an implicit requirement we should be considering. So I guess I'm voting for either 1) or 3).

I also vote for option 1)

Metadata Update from @churchyard:
- Issue tagged with: F32

4 years ago

Metadata Update from @zbyszek:
- Issue tagged with: meeting

4 years ago

+1 to have our own infrastructure needs to be release blocking, thus on item 1)

This was discussed during today's FESCo meeting (16/3/2020):

  • AGREED: Option 1 is approved (+7, 0, 0) (zbyszek, 15:32:00)
  • ACTION: bcotton to update the wiki or reassign to the next
    "volunteer" (zbyszek, 15:35:04)

Metadata Update from @zbyszek:
- Issue untagged with: meeting
- Issue assigned to bcotton

4 years ago

Metadata Update from @zbyszek:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

4 years ago

Metadata Update from @bcotton:
- Issue untagged with: F32
- Issue set to the milestone: Fedora 32

3 years ago

Login to comment on this ticket.

Metadata