Created attachment 1289660 [details]
server kickstart

Created attachment 1289661 [details]
server kickstart

Affects any server install on armhfp 

================================================================================
================================================================================
Partition Scheme Options

[ ] 1) Standard Partition

[ ] 2) Btrfs

[x] 3) LVM

[ ] 4) LVM Thin Provisioning

Select a partition scheme configuration.

Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to
refresh]: c
Generating updated storage configuration
storage configuration failed: autopart failed:
/boot file system cannot be of type xfs.

Nominating a blocker for final violating alpha criteria:

"The installer must be able to complete an installation to a single disk using automatic partitioning."

It looks like this was caused by https://github.com/rhinstaller/anaconda/commit/3e7d9c892fd5b6f2b256059f142f3b2c6a9a8c35

This patch seems to have been overzealous, since it causes Anaconda to always set the boot filesystem to the same as the default for the root filesystem, but this doesn't work on all architectures.

It probably passed upstream tests because the default FS in anaconda is normally ext4 IIRC. However, the Fedora Server has an installclass that sets the defaultFS to be XFS. In previous releases, this didn't touch the default_boot_fsytpe, only the default_fstype.

+1 Final Blocker

Also, if this was an intentional change to how installClasses are supposed to work, please advise on how we should update the Fedora Server installclass at http://pkgs.fedoraproject.org/cgit/rpms/fedora-productimg-server.git/tree/fedora-server.py and I'll update it there.

(That said, I really think we should be able to trust that storage.default_boot_fstype is correct, mostly so I don't have to keep updating this if other things change in the future)

(In reply to Stephen Gallagher from comment #7)
> Also, if this was an intentional change to how installClasses are supposed
> to work, please advise on how we should update the Fedora Server
> installclass at
> http://pkgs.fedoraproject.org/cgit/rpms/fedora-productimg-server.git/tree/
> fedora-server.py and I'll update it there.
> 
> (That said, I really think we should be able to trust that
> storage.default_boot_fstype is correct, mostly so I don't have to keep
> updating this if other things change in the future)
This might be a bit off-topic for this bug - but is there still some reason for having the Fedora Server install class as a separate entity living in it's own repository outside of the Anaconda source code ? 

IIRC back when the Fedora Server install class was created we only had the Fedora & RHEL install classes and it was not clear if other install classes should be part of the Aanconda source code.

But things changed since then and we now have an install class for CentOS and even for Scientific Linux as part of the Anaconda source code[0][0]. So I don't really see a reason for having the Fedora server install class hosted separately myself.

And having the code in a single repository should certainly help avoid or debug issues like this one - as you can easily see all the install classes do & what default they have set. And if any changes are needed in the install class - just send a PR. :)

[0] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/installclasses/centos.py
[1] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/installclasses/scientific.py

Created attachment 1290930 [details]
Updates image

Hi Paul, 
could you please test the attached updates image?

Thanks,
Vendula

(In reply to Martin Kolman from comment #8)
> (In reply to Stephen Gallagher from comment #7)
> > Also, if this was an intentional change to how installClasses are supposed
> > to work, please advise on how we should update the Fedora Server
> > installclass at
> > http://pkgs.fedoraproject.org/cgit/rpms/fedora-productimg-server.git/tree/
> > fedora-server.py and I'll update it there.
> > 
> > (That said, I really think we should be able to trust that
> > storage.default_boot_fstype is correct, mostly so I don't have to keep
> > updating this if other things change in the future)
> This might be a bit off-topic for this bug - but is there still some reason
> for having the Fedora Server install class as a separate entity living in
> it's own repository outside of the Anaconda source code ? 
> 
> IIRC back when the Fedora Server install class was created we only had the
> Fedora & RHEL install classes and it was not clear if other install classes
> should be part of the Aanconda source code.
> 
> But things changed since then and we now have an install class for CentOS
> and even for Scientific Linux as part of the Anaconda source code[0][0]. So
> I don't really see a reason for having the Fedora server install class
> hosted separately myself.
> 
> And having the code in a single repository should certainly help avoid or
> debug issues like this one - as you can easily see all the install classes
> do & what default they have set. And if any changes are needed in the
> install class - just send a PR. :)


How do those get applied? The reasoning behind having these in separate packages was to make it possible to produce Fedora Server composes simply by telling lorax to include the fedora-productimg-server package (which included the branding information as well as the installClass package).

If there's a better way to handle the installClass now, I'm willing to look into it, but I need to know how we would apply it in composes.

(Note: fedora-productimg-workstation *also* provides an installClass that specifies which of the available environment groups should be the default, since the Workstation netinstall satisfies several. If we go this route, we'll need to update that as well.)

(In reply to Stephen Gallagher from comment #10)
> (In reply to Martin Kolman from comment #8)
> > (In reply to Stephen Gallagher from comment #7)
> > > Also, if this was an intentional change to how installClasses are supposed
> > > to work, please advise on how we should update the Fedora Server
> > > installclass at
> > > http://pkgs.fedoraproject.org/cgit/rpms/fedora-productimg-server.git/tree/
> > > fedora-server.py and I'll update it there.
> > > 
> > > (That said, I really think we should be able to trust that
> > > storage.default_boot_fstype is correct, mostly so I don't have to keep
> > > updating this if other things change in the future)
> > This might be a bit off-topic for this bug - but is there still some reason
> > for having the Fedora Server install class as a separate entity living in
> > it's own repository outside of the Anaconda source code ? 
> > 
> > IIRC back when the Fedora Server install class was created we only had the
> > Fedora & RHEL install classes and it was not clear if other install classes
> > should be part of the Aanconda source code.
> > 
> > But things changed since then and we now have an install class for CentOS
> > and even for Scientific Linux as part of the Anaconda source code[0][0]. So
> > I don't really see a reason for having the Fedora server install class
> > hosted separately myself.
> > 
> > And having the code in a single repository should certainly help avoid or
> > debug issues like this one - as you can easily see all the install classes
> > do & what default they have set. And if any changes are needed in the
> > install class - just send a PR. :)
> 
> 
> How do those get applied? The reasoning behind having these in separate
> packages was to make it possible to produce Fedora Server composes simply by
> telling lorax to include the fedora-productimg-server package (which
> included the branding information as well as the installClass package).
Yeah, that's indeed pretty straightforward & simple.
> 
> If there's a better way to handle the installClass now, I'm willing to look
> into it, but I need to know how we would apply it in composes.
We have an RFE to set which install class should be used from kickstart:
https://bugzilla.redhat.com/show_bug.cgi?id=1412159

I guess that can be used to select the Fedora Server install class from the
Fedora Server compose kickstart.

> 
> (Note: fedora-productimg-workstation *also* provides an installClass that
> specifies which of the available environment groups should be the default,
> since the Workstation netinstall satisfies several. If we go this route,
> we'll need to update that as well.)
Should that just work out of the box when the Server install class is used instead
of the Workstation install class?

(In reply to Martin Kolman from comment #11)
> We have an RFE to set which install class should be used from kickstart:
> https://bugzilla.redhat.com/show_bug.cgi?id=1412159
> 
> I guess that can be used to select the Fedora Server install class from the
> Fedora Server compose kickstart.
> 

OK, when that lands, we can look at migrating these in, I suppose. That doesn't address the current bug, though.

> > 
> > (Note: fedora-productimg-workstation *also* provides an installClass that
> > specifies which of the available environment groups should be the default,
> > since the Workstation netinstall satisfies several. If we go this route,
> > we'll need to update that as well.)
> Should that just work out of the box when the Server install class is used
> instead
> of the Workstation install class?

I don't understand what you're asking. Could you be more specific?

(In reply to Vendula Poncova from comment #9)
> Created attachment 1290930 [details]
> Updates image
> 
> Hi Paul, 
> could you please test the attached updates image?
> 
> Thanks,
> Vendula

Success, back to the expected ext4 /boot, xfs root.

Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1114

anaconda-26.21.10-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3aec86381a

Discussed at 2017-06-26 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-26/f26-blocker-review.2017-06-26-16.03.html . Rejected as a blocker, as this does not actually affect any release-blocking medium: no Server media are release-blocking for ARM, per https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking . However, it is accepted as an FE issue, as obviously Server installs failing on ARM is a bad thing and cannot be fixed with a post-release update.

anaconda-26.21.10-1.fc26, anaconda-user-help-26.1-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3aec86381a

anaconda-26.21.10-1.fc26, anaconda-user-help-26.1-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Stephen Gallagher from comment #12)
> (In reply to Martin Kolman from comment #11)
> > We have an RFE to set which install class should be used from kickstart:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1412159
> > 
> > I guess that can be used to select the Fedora Server install class from the
> > Fedora Server compose kickstart.
> > 
> 
> OK, when that lands, we can look at migrating these in, I suppose. That
> doesn't address the current bug, though.

Sure! BTW, I've created a separate RFE bug for the install class migration: https://bugzilla.redhat.com/show_bug.cgi?id=1466967