Created attachment 625953 [details] VM setup instructions Description of problem: This might be very similar to bug 824191, but Radek Vykydal claims it was resolved, so I'm reporting a new bug. If I boot vmlinuz+initrd in a VM (this is equivalent to PXE boot) and use "inst.repo=nfs:" boot option, the system fails to reboot after the installation. Hard reboot is needed. I appended "console=ttyS0 graphical" to boot options to see kernel messages. This is all I see in the console after hitting Reboot button: > [terminated] Once I saw this, but I think that's just a race issue and the [terminated] line should be last: > [terminated] > [ OK ] Started Show Plymouth Reboot Screen. I believe the [terminated] line doesn't come from kernel, but from tmux, the fancy terminal splitter anaconda uses on system console. Once tmux is killed, no other messages are written to the console. That is of course very inconvenient, because we need to see all the messages to find out why it doesn't reboot. Unfortunately Martin Sivak says there is no way to avoid using tmux on the system console. Please note that this problem doesn't appear if you boot from netinst instead of vmlinuz+initrd. Clearly, similarly to bug 824191, there is some problem when unmounting network-attached root filesystem. Version-Release number of selected component (if applicable): F18 Beta TC3 (DVD x86_64 loop mounted as nfs repo, kernel+initrd used for boot) anaconda 18.14 How reproducible: seems always (3 of 3 attempts) Steps to Reproduce: 1. see attachment how to set up your VM 2. loop mount DVD, share over NFS 3. run VM, connect using "virsh console VM_NAME" 4. perform installation (minimal is enough), hit Reboot
Proposing as Beta blocker: " The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options" "It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run. " https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria NFSISO support is tracked in bug 853508.
Discussed at 2012-10-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-17/f18beta-blocker-review-4.2012-10-17-16.00.log.txt . We noted that this issue bears a clear resemblance to https://bugzilla.redhat.com/show_bug.cgi?id=824191 , which we rejected as a Final blocker for Fedora 17 (though that was in some respects a time-pressured decision). On the understanding that the installed system does in fact work (it only requires a manual hard reboot to get to the installed system), and that we don't know this bug affects anything other than the combination of PXE and NFS, it is rejected as a Beta blocker. The criteria essentially mean that installation should succeed, they don't strictly require the post-install reboot to work. If this installed system does not in fact work, or this affects PXE with all repository types, please re-propose this as a blocker and it will be re-considered.
Re-proposing as a Final blocker. Rationale: PXE+nfs is used for automated installations - if it requires hard reboot afterwards, the whole functionality is essentially useless. Also I consider the ability to reboot as a vital part of the installation process.
I can't reproduce with anaconda-18.18. Can you re-test with TC5 when it becomes available?
Great, this seems to be fixed with anaconda 18.19. I did two installations, no hang.
Verified and stable, closing.