Bug 1463297
| Summary: | Server install fails on armhfp - "/boot file system cannot be of type xfs" | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> | ||||||||
| Component: | anaconda | Assignee: | Vendula Poncova <vponcova> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 26 | CC: | anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, mkolman, pwhalen, robatino, sgallagh, vanmeeuwen+fedora, vponcova | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | armhfp | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | RejectedBlocker AcceptedFreezeException | ||||||||||
| 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-28 03:52:02 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1349189 | ||||||||||
| Attachments: |
|
||||||||||
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 |
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.