Bug 1443662
Summary: | installation problems with repos accessed via NFS | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | René Genz <liebundartig> | ||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 28 | CC: | anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, liebundartig, mattdm, mkolman, robatino, vanmeeuwen+fedora, vponcova | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | RejectedBlocker | ||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2019-05-28 19:46:41 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: | |||||||
Attachments: |
|
Description
René Genz
2017-04-19 16:20:45 UTC
for the 'additional info' paragraph: I accidentally cut the '--opts=nfsvers=3' from the end of the line 'nfs server ...' retested with Fedora 26 Beta using: Fedora-Workstation-netinst-x86_64-26_Beta-1.4.iso "problem 1" is fixed and was apparently caused by me. In the 'NFS mount options:" input box instead of writing: --opts=nfsvers=3 I should have written: nfsvers=3 This works as well. "problem" 2 is still present. Maybe this is a related bug 1444335? Unattended installation using NFS repo is not possible. To me this violates: - http://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria#Remote_package_sources (too late for that) and - http://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#Package_and_installer_sources I will propose "problem 2" as a blocker bug starting at: https://qa.fedoraproject.org/blockerbugs Proposed as a Blocker for 26-final by Fedora user sobek using the blocker tracking app because: Unattended kickstart installation with accessing repos by NFS is not possible. The installer loads the kickstart file but cannot download files from the repos. To me this violates: http://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria#Remote_package_sources "When using the dedicated installer images, the installer must be able to use HTTP, FTP and NFS repositories as package sources." We are past 26-beta. Hence using 'f26-final' as milestone and violation is: http://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#Package_and_installer_sources "The installer must be able to use all supported local and remote package and installer sources." Discussed at 2017-06-19 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-19/f26-blocker-review.2017-06-19-16.00.html . We agreed that we could do with some more information and independent re-testing of this to be sure. René, could you clarify exactly what your configuration is and exactly what is not working now? Could you attach the specific kickstart that does not work for you, and expand a bit on the claim that using NFS interactively with the text installer does not work? Is there some reason why you need to specify 'nfsvers=3' at all when doing the GUI install? Does the install work if you do not specify it at all? Thanks. Created attachment 1289362 [details] kickstart file After some more testing the summary from my point of view is: 1st problem (covered by 1443662): Installation is not working if you do an unattended kickstart-based installation using static IP address configuration and NFS-based repo. 2nd problem (covered by 1444335): In an unattended kickstart-based installation using static IP address configuration and HTTP-based repo in the %post section you cannot mount NFSv3 shares. mount.nfs tries only NFSv4.2 ; you have to use 'nfsvers=3' mount option to force mounting of NFSv3, but it fails with 'mount.nfs: mount(2): No such device'. Now answering your questions for this bug. > René, could you clarify exactly what your configuration is and exactly what is not working now? With `rsync` I am downloading Fedora repo 'http://.../releases/24/Everything/x86_64/os/' to a local server, SERVER1. SERVER1 offers the repo via a NFSv3 share. For testing purpose, in addition SERVER2 mounts the NFSv3 share and offers it via HTTP. My Fedora clients download packages during installation of Fedora from the NFSv3 share of SERVER1. If NFS does not work for some reason I can use HTTP. I am using a virtual machine to test Fedora 26 installation. I start the VM and load the file: Fedora-Workstation-netinst-x86_64-26_Beta-1.4.iso I perform unattended kickstart-based TUI installation like this: - after loading the ISO select 'Install Fedora 26' and press tab key - delete with backspace till only 'vmlinuz initrd=initrd.img ' is present - type 'ks=http://<IPv4 address>/kickstart/anaconda-ks.cfg' - press enter > Could you attach the specific kickstart that does not work for you, and expand a bit on the claim that using NFS interactively with the text installer does not work? I am sorry for causing confusion. For me the installation is not working if you do an unattended kickstart-based installation using static IP address configuration and NFS-based repo. The combination is important. Installation will work if you modify the above like: -DHCP and NFS-based repo -static IP and HTTP-based repo -DHCP and HTTP-based repo When the installation does not work it looks like this in the tmux window: ---8<--- Starting installer, one moment... anaconda 26.21.9-1 ... * ... * ... * ... * ... ---8<--- The text 'Starting automated install' does not appear like it should. The attached kickstart file helps to reproduce both problems. It has been redacted. Placeholders are: SERVERNAME1 SERVERNAME2 NAMECLIENT1 IPv4ADDRESS1 IPv4ADDRESS2 IPv4ADDRESS3 NAMECLIENT1 ROOTPWCRYPTED > Is there some reason why you need to specify 'nfsvers=3' at all when doing the GUI install? Does the install work if you do not specify it at all? It was a habit from previous Fedora installation environments. It is not necessary with Fedora 26 Beta in GUI, TUI, and unattended kickstart installation for the repo. Leaving the NFS mount options blank works fine. So I'm working on reproducing this. So far I have not; I used a kickstart based on Rene's, but shortened, the salient bits being: network --bootproto static --ip 192.168.1.55 --netmask 255.255.255.0 nfs --server 192.168.1.5 --dir /mnt/temp and it worked fine. However, the NFS server I'm using is a Fedora 26 box, and so obviously is an NFSv4 server. I'll try and set up an NFSv3-only server, somehow, and test again. Nope, just tried with my NFS server configured to only serve v3 (via /etc/nfs.conf) and still cannot reproduce this. 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 . We agreed to delay decision on this again pending attempts to reproduce it independently and fully identify the circumstances under which the bug happens. I'm -1 to this as a blocker. Installation over NFS is important, but it seems to be only happening in a narrow case and Adam can demonstrate it working in a similar situation -- and René, you have a workaround with by changing to either DHCP or HTTP, right? (What happens if you use your DHCP server to allocate fixed addresses?) Discussed at 2017-06-29 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-29/f26-blocker-review.2017-06-29-16.00.html . Rejected as a blocker: the information we have so far indicates this is some kind of corner case, not a general problem that's likely to affect many people, and the reporter has several workarounds they can use. Matthew, I agree. It seems like I am hitting a special code path. Today, I found a workaround: - use NFSv3-based repos with static IPs for OS installation and - wait 17 to 20 minutes till 'Starting automated install' is shown and installation starts With this workaround mounting NFSv3 shares in %post works! The delay is due to 'e2fsck'. But there is no hard disk or CPU activity. The delay occurs only with the above combination. For all other combinations 'e2fsck' is done within a second. I did not find the workaround earlier, because I killed the installations after 5 to 10 minutes. For reference the other combination's results and why I cannot use them. HTTP-based repos and (static IPs OR DHCP) for OS installation starts installation without delay. But it breaks NFSv3 share mounting in %post. This is a requirement for me. The '--noIPv6' option for static IPs makes no difference. I have not tested '--noIPv6' option with DHCP. NFS-based repos and DHCP-served dynamic IPs for OS installation start installation without delay. Mounting NFSv3 shares in %post works. But our policy is to assign locally static IPs for Fedora-computers, no DHCP server involved. I have not tested '--noIPv6' option with DHCP. I tested DHCP-served static IP with HTTP-based repos for OS installation. It starts without delay. Mounting NFSv3 shares in %post works. I have not tested '--noIPv6' option with DHCP. Unfortunately, the specified DHCP-served static IP is not used. A DHCP-served dynamic IP is used. Maybe I am doing something wrong. If you are interested, I can try again. However, I would rather get my F26 installation setup into shape. :) I tested Fedora 28 with Fedora-Workstation-netinst-x86_64-28-20180302.n.0.iso and packages from current date of posting with automated kickstart installation on a virtual machine. My 2x2 test matrix consists of: IPv4 set to : static <> DHCP repository for installation served via : NFS <> HTTP Result: - mounting NFSv3 share in %post works for all use cases - use cases DHCP/NFS, DHCP/HTTP, and static/HTTP have no delay before start of installation - use case static/NFS' delay before start of installation has been reduced from 17 to 4 minutes During the delay you can switch to the 'program-log' pane with Alt+Tab; in it's last line you can read: <time> INF program: Running [6] e2fsck -V ... After 4 minutes have passed these lines are appended: <time> INF program: stdout[6]: <time> INF program: stderr[6]: e2fsck 1.43.8 (1-Jan-2018) Using EXT2FS Library version 1.43.8, 1-Jan-2018 <time> INF program: ...done [6] (exit code: 0) This is when in the 'main' pane the installation starts. With Fedora-Workstation-netinst-x86_64-28-20180315.n.0.iso and Fedora-Workstation-netinst-x86_64-28-20180316.n.1.iso the problem of "failing to mount NFSv3 shares in %post with static IP and NFSv3 repo in kickstart file" is happening again. I have not tested the other cases. Executing the command in %post (NFSSERVER, NFSSHARE, MOUNTPOINT, IPV4-1, IPv4-2 are dummies): mount -v -t nfs -o nolock ${NFSSERVER}:${NFSSHARE} "${MOUNTPOINT}" fails and creates the output: Running the command without results in output: mount.nfs: mount(2): Protocol not supported mount.nfs: mount(2): Protocol not supported mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported mount.nfs: timeout set for Sat Mar 17 21:33:38 2018 mount.nfs: trying text-based options 'nolock,vers=4.2,addr=${IPv4-1},clientaddr=${IPv4-2}' mount.nfs: trying text-based options 'nolock,vers=4,minorversion=1,addr=${IPv4-1},clientaddr=${IPv4-2}' mount.nfs: trying text-based options 'nolock,vers=4,addr=${IPv4-1},clientaddr=${IPv4-2}' The workaround is to use the 'nfsvers=3' option: mount -v -t nfs -o nolock,nfsvers=3 ${NFSSERVER}:${NFSSHARE} "${MOUNTPOINT}" the output is: mount.nfs: trying ${IPv4-1} prog 100003 vers 3 prot TCP port 2049 mount.nfs: trying ${IPv4-1} prog 100005 vers 3 prot UDP port 635 mount.nfs: timeout set for Sat Mar 17 22:12:24 2018 mount.nfs: trying text-based options 'nolock,nfsvers=3,addr=${IPv4-1}' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: prog 100005, trying vers=3, prot=17 This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |