Bug 1463297 - Server install fails on armhfp - "/boot file system cannot be of type xfs"
Server install fails on armhfp - "/boot file system cannot be of type xfs"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
26
armhfp Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Vendula Poncova
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeException
:
Depends On:
Blocks: F26FinalFreezeException
  Show dependency treegraph
 
Reported: 2017-06-20 10:19 EDT by Paul Whalen
Modified: 2017-06-30 19:52 EDT (History)
10 users (show)

See Also:
Fixed In Version: anaconda-26.21.10-1.fc26
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-27 23:52:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
server kickstart (1.10 KB, application/x-fluid)
2017-06-20 10:22 EDT, Paul Whalen
no flags Details
server kickstart (1.10 KB, text/plain)
2017-06-20 10:23 EDT, Paul Whalen
no flags Details
Updates image (3.85 KB, application/x-gzip)
2017-06-23 04:19 EDT, Vendula Poncova
no flags Details

  None (edit)
Description Paul Whalen 2017-06-20 10:19:31 EDT
Description of problem:
Attempt installation of Server with a kickstart using autopart lvm, fails with "/boot file system cannot be of type xfs"

Version-Release number of selected component (if applicable):
Started as of Fedora-26-20170619.n.0

How reproducible:
Everytime

Steps to Reproduce:
1. Attempt server kickstart install with autopart lvm


Actual results:

Starting installer, one moment...
anaconda 26.21.9-1 for Fedora 26 (pre-release) started.
 * installation log files are stored in /tmp during the installation
 * shell is available on TTY2
 * if the graphical installation interface fails to start, try again with the
   inst.text bootoption to start text installation
 * when reporting a bug add logs from /tmp as separate text/plain attachments
15:46:43 Not asking for VNC because of an automated install
15:46:43 Not asking for VNC because text mode was explicitly asked for in kickstart
Starting automated install.............................................
Generating updated storage configuration
storage configuration failed: autopart failed:
/boot file system cannot be of type xfs.
================================================================================

================================================================================
Installation

 1) [x] Language settings                 2) [x] Time settings
        (English (United States))                (US/Eastern timezone)
 3) [x] Installation source               4) [x] Software selection
        (https://kojipkgs.fedoraproject          (Custom software selected)
        .org/compose/branched//Fedora-2   6) [x] Network configuration
        6-20170619.n.0/compose/Server/a          (Wired (eth0) connected)
        rmhfp/os/)
 5) [!] Installation Destination
        (Kickstart insufficient)

Please make a selection from the above ['b' to begin installation, 'h' to help,
'q' to quit, 'r' to refresh]:


Expected results:

Successful install. 

Additional info:

Kickstart working with Fedora-26-20170618.n.0.
Comment 1 Paul Whalen 2017-06-20 10:22 EDT
Created attachment 1289660 [details]
server kickstart
Comment 2 Paul Whalen 2017-06-20 10:23 EDT
Created attachment 1289661 [details]
server kickstart
Comment 3 Paul Whalen 2017-06-21 11:21:00 EDT
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.
Comment 4 Paul Whalen 2017-06-22 15:17:45 EDT
Nominating a blocker for final violating alpha criteria:

"The installer must be able to complete an installation to a single disk using automatic partitioning."
Comment 5 Stephen Gallagher 2017-06-22 15:24:56 EDT
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.
Comment 6 Stephen Gallagher 2017-06-22 15:25:31 EDT
+1 Final Blocker
Comment 7 Stephen Gallagher 2017-06-22 15:29:21 EDT
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)
Comment 8 Martin Kolman 2017-06-22 18:39:41 EDT
(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
Comment 9 Vendula Poncova 2017-06-23 04:19 EDT
Created attachment 1290930 [details]
Updates image

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

Thanks,
Vendula
Comment 10 Stephen Gallagher 2017-06-23 08:38:11 EDT
(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.)
Comment 11 Martin Kolman 2017-06-23 12:38:54 EDT
(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?
Comment 12 Stephen Gallagher 2017-06-23 12:41:10 EDT
(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?
Comment 13 Paul Whalen 2017-06-23 13:35:35 EDT
(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.
Comment 14 Vendula Poncova 2017-06-26 04:13:38 EDT
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1114
Comment 15 Fedora Update System 2017-06-26 11:19:10 EDT
anaconda-26.21.10-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3aec86381a
Comment 16 Adam Williamson 2017-06-26 20:48:03 EDT
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.
Comment 17 Fedora Update System 2017-06-27 02:25:54 EDT
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
Comment 18 Fedora Update System 2017-06-27 23:52:02 EDT
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.
Comment 19 Martin Kolman 2017-06-30 19:52:46 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.