Bug 865776 - kernel pair boot with inst.repo=nfs: hangs on reboot
Summary: kernel pair boot with inst.repo=nfs: hangs on reboot
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F18Blocker, F18FinalBlocker
TreeView+ depends on / blocked
Reported: 2012-10-12 12:28 UTC by Kamil Páral
Modified: 2013-01-10 02:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-10-23 14:20:45 UTC

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

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 824191 None None None Never
Red Hat Bugzilla 853508 None None None Never

Internal Links: 824191 853508

Description Kamil Páral 2012-10-12 12:28:40 UTC
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 12:32:58 UTC
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 16:53:18 UTC
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 08:38:41 UTC
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 18:12:44 UTC
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 13:21:24 UTC
Great, this seems to be fixed with anaconda 18.19. I did two installations, no hang.

Comment 6 Kamil Páral 2012-10-23 14:20:45 UTC
Verified and stable, closing.

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