Bug 865776 - kernel pair boot with inst.repo=nfs: hangs on reboot
kernel pair boot with inst.repo=nfs: hangs on reboot
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
Reported: 2012-10-12 08:28 EDT by Kamil Páral
Modified: 2013-01-09 21:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-23 10:20:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
VM setup instructions (92.72 KB, image/png)
2012-10-12 08:28 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-10-12 08:28:40 EDT
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
Comment 1 Kamil Páral 2012-10-12 08:32:58 EDT
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. "


NFSISO support is tracked in bug 853508.
Comment 2 Adam Williamson 2012-10-17 12:53:18 EDT
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.
Comment 3 Kamil Páral 2012-10-18 04:38:41 EDT
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.
Comment 4 Jesse Keating 2012-10-19 14:12:44 EDT
I can't reproduce with anaconda-18.18.  Can you re-test with TC5 when it becomes available?
Comment 5 Kamil Páral 2012-10-22 09:21:24 EDT
Great, this seems to be fixed with anaconda 18.19. I did two installations, no hang.
Comment 6 Kamil Páral 2012-10-23 10:20:45 EDT
Verified and stable, closing.

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