Bug 787461 - system halts at first reboot after install
system halts at first reboot after install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
:
: 789218 (view as bug list)
Depends On:
Blocks: F17Beta/F17BetaBlocker
  Show dependency treegraph
 
Reported: 2012-02-05 04:39 EST by Hongqing Yang
Modified: 2013-02-26 17:41 EST (History)
11 users (show)

See Also:
Fixed In Version: anaconda-17.11-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-10 00:13:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda logs (250.00 KB, application/x-tar)
2012-02-05 04:39 EST, Hongqing Yang
no flags Details
audit log (9.24 KB, text/plain)
2012-02-05 04:41 EST, Hongqing Yang
no flags Details
syslog (66.83 KB, text/plain)
2012-02-07 21:36 EST, Hongqing Yang
no flags Details
anaconda log (18.96 KB, text/plain)
2012-02-07 21:36 EST, Hongqing Yang
no flags Details
program log (34.53 KB, text/plain)
2012-02-07 21:37 EST, Hongqing Yang
no flags Details
storage log (92.92 KB, text/plain)
2012-02-07 21:38 EST, Hongqing Yang
no flags Details
don't eject the dvd from anaconda (4.09 KB, patch)
2012-02-17 19:29 EST, Brian Lane
no flags Details | Diff
kickstart file (352 bytes, text/plain)
2012-02-22 04:12 EST, Hongqing Yang
no flags Details

  None (edit)
Description Hongqing Yang 2012-02-05 04:39:11 EST
Created attachment 559448 [details]
anaconda logs

Description of problem:

system halts at first reboot after install with text
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. install system with text mode
2. reboot system after all packages are installed
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Hongqing Yang 2012-02-05 04:41:58 EST
Created attachment 559449 [details]
audit log
Comment 2 Andre Robatino 2012-02-05 22:33:51 EST
This happens with the 17 Alpha TC1 DVD, either i386 or x86_64, either text-based or GUI minimal install. Although the system can't be rebooted, it can be hard powered off and then booted again and the install appears to be successful (once the DVD is removed).

A more serious issue is bug 787539. If one does a text reinstall on top of the original text install, there is a traceback at the very end. This prevents the installation from completing at least some of the time.
Comment 3 Chris Lumens 2012-02-07 10:22:56 EST
Please attach log files as individual, uncompressed attachments.  Doing anything else prevents us from easily searching bugzilla in the future.  Thanks.
Comment 4 Hongqing Yang 2012-02-07 21:35:12 EST
noted
Comment 5 Hongqing Yang 2012-02-07 21:36:11 EST
Created attachment 560107 [details]
syslog
Comment 6 Hongqing Yang 2012-02-07 21:36:35 EST
Created attachment 560108 [details]
anaconda log
Comment 7 Hongqing Yang 2012-02-07 21:37:27 EST
Created attachment 560109 [details]
program log
Comment 8 Hongqing Yang 2012-02-07 21:38:27 EST
Created attachment 560110 [details]
storage log
Comment 9 Brian Lane 2012-02-08 19:10:32 EST
Is the virt using a virtio disk or ata? tflink has seen a similar problem when using virtio disks.
Comment 10 Andre Robatino 2012-02-08 19:13:48 EST
For me, it's using virt-manager's default virtio.
Comment 11 Andre Robatino 2012-02-09 22:42:31 EST
Same problem in 17 Alpha TC2. In addition, after hard powering off and then booting after my first install in a KVM guest (using the default virtio), I get

Booting from Hard Disk...
GRUB loading.
Welcome to GRUB!

error: ELF header smaller than expected.
Entering rescue mode...
grub rescue>

I also saw this issue in bug 787539 which involves doing a reinstall on top of an existing install.
Comment 12 Hongqing Yang 2012-02-10 00:44:57 EST
This also happens with F17 Alpha TC2 with VNC installation.
Comment 13 Andre Robatino 2012-02-10 16:44:12 EST
The bootloader corruption in comment 11 can be repaired by

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/vda

(using /dev/vda for a KVM guest). After doing that, the installed system seems normal.
Comment 14 Hongqing Yang 2012-02-16 00:36:41 EST
reproduced with F17 Alpha RC2
Error shows on the terminal:
systemd-shutdow[1]:segfault at 7f67d6ab87d7 ip 00007f67d6ab87d7 sp 0007fffb1fbdc18 error 14
Comment 15 Hongqing Yang 2012-02-16 01:49:16 EST
(In reply to comment #11)
> Same problem in 17 Alpha TC2. In addition, after hard powering off and then
> booting after my first install in a KVM guest (using the default virtio), I get
> 
> Booting from Hard Disk...
> GRUB loading.
> Welcome to GRUB!
> 
> error: ELF header smaller than expected.
> Entering rescue mode...
> grub rescue>
> 
> I also saw this issue in bug 787539 which involves doing a reinstall on top of
> an existing install.

This is hit in F17 Alpha RC2 with vnc installation
Comment 16 Adam Williamson 2012-02-17 12:48:59 EST
Shouldn't this be proposed as a blocker, criterion "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles" ?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Adam Williamson 2012-02-17 12:55:53 EST
Discussed at 2012-02-17 blocker review meeting (we proposed it as a blocker in-meeting). Seems a tiny bit confused with a couple of different issues (something with systemd, and bootloader corruption) but enough people look to be experiencing serious problems to consider this a blocker. Please, everyone, investigate your cases and try to pin down what's actually failing.
Comment 18 Adam Williamson 2012-02-17 13:16:39 EST
Just tried a minimal graphical install inside a KVM, from RC2 DVD. When I hit 'reboot' at the end of install the VM stopped responding to input (couldn't get to a console) and sat chewing up 100% CPU time for five minutes, at which point I gave up and force-powered-off. On booting up again from the hard disk, I get grub fail:

Welcome to GRUB!

error: file not found.
Entering rescue mode...
grub rescue> _
Comment 19 Adam Williamson 2012-02-17 13:28:22 EST
after fixing grub2 per comment #13, system booted okay. note that it paints the login prompt, then shows some extra systemd boot messages - 'started sendmail mail transport client', 'started ssh server keys generation.', 'starting openssh server daemon...', 'started openssh server daemon' - but the login prompt is active and works if you just type root and then the root password.
Comment 20 Adam Williamson 2012-02-17 13:33:26 EST
interestingly, /var/log/anaconda/* on the installed system are zero-length.
Comment 21 Adam Williamson 2012-02-17 13:46:03 EST
Doing a text mode install, I see the systemd-shutdow[1] segfault.

I'm not sure but that the reboot-fail and the grub-corruption issues are separate, though. grub installation should be complete well before the system attempts to power down.
Comment 22 Adam Williamson 2012-02-17 14:30:03 EST
CC Lennart for the systemd segfault.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Adam Williamson 2012-02-17 14:54:01 EST
interestingly, if at the last stage of a graphical install you switch to the single available console - ctrl-alt-f2 - and try to type anything, the prompt immediately disappears and your command is not handled.

ctrl-alt-del also appears to have no effect.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Adam Williamson 2012-02-17 14:57:22 EST
I just completed another test install - graphical install with full (not minimal) package set. I did not hit the 'reboot' button but tried to switch to ctrl-alt-f2 and type 'reboot'. As described in c#23, this failed. But after forcing shut down and then booting up again, the installed system booted successfully - there was no grub error - and the anaconda logs are not 0-length.
Comment 25 Brian Lane 2012-02-17 17:55:25 EST
*** Bug 789218 has been marked as a duplicate of this bug. ***
Comment 26 Brian Lane 2012-02-17 19:29:19 EST
Created attachment 564018 [details]
don't eject the dvd from anaconda

The problem here is that we are running from the squashfs.img on the install media. If we eject it we have just yanked the rug from under the running system.

This patch removes eject from Anaconda. We still need to figure out a way to handle eject on shutdown outside of it.
Comment 27 Brian Lane 2012-02-20 12:27:22 EST
Here's an updates image to test with: http://bcl.fedorapeople.org/updates/787461.img
Comment 28 Tim Flink 2012-02-20 14:09:32 EST
I used http://bcl.fedorapeople.org/updates/787461.img with the F17 Alpha RC2 DVD iso and after doing a graphical install inside a VM, the reboot button did reboot the VM.
Comment 29 John Reiser 2012-02-20 14:21:33 EST
(In reply to comment #27)
> http://bcl.fedorapeople.org/updates/787461.img

Works for me: does not eject DVD (Fedora 17 Alpha RC2 x86_64), commands may be
invoked from VT2 after Package Install finishes, <Reboot> button performs a
reboot.

The UI at the end could be improved: after all packages have completed (1203 of
1203) there is a 3-minute pause with no apparent action, then 2 minutes of Boot
Loader installing, before the appearance of "Congratulations! You are Done". 
Also, the DVD tray seems to be locked, because pushing the Eject button does
not open the tray, even after all video goes away.
Comment 30 Adam Williamson 2012-02-20 14:38:38 EST
reiser: as stated in comment #26 - this patch just kills the eject mechanism in anaconda, so yeah, now you can't eject. this is better than a *broken* eject mechanism, though :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 31 Andre Robatino 2012-02-20 18:12:56 EST
Works for me. Also, the anaconda logs appear normal. Bug 787539 also appears fixed. As for not ejecting, that has happened in some past releases as well (even Final).
Comment 32 Brian Lane 2012-02-20 19:06:39 EST
Newer version of the patch has been applied, eject is back to working as long as the image is built with lorax-17.6 or later.
Comment 33 Fedora Update System 2012-02-20 19:14:44 EST
anaconda-17.10-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.10-1.fc17
Comment 34 Andre Robatino 2012-02-21 12:14:10 EST
Works fine in 17 Alpha RC3, doing non-networked DVD minimal installs for both i386 and x86_64.
Comment 35 Fedora Update System 2012-02-21 13:22:42 EST
anaconda-17.11-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.11-1.fc17
Comment 36 Fedora Update System 2012-02-21 22:53:55 EST
Package anaconda-17.11-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.11-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-2185/anaconda-17.11-1.fc17
then log in and leave karma (feedback).
Comment 37 Hongqing Yang 2012-02-22 00:11:23 EST
This is fixed with anaconda-17.11-1.fc17
Comment 38 Hongqing Yang 2012-02-22 04:12:16 EST
Created attachment 564872 [details]
kickstart file
Comment 39 Fedora Update System 2012-02-28 06:01:05 EST
anaconda-17.11-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Hongqing Yang 2012-03-07 03:07:44 EST
reproduced with F17 Beta TC1 with kickstart installation. After forced it off, it still cannot boot into the system.
Comment 41 Brian Lane 2012-03-08 17:30:05 EST
(In reply to comment #40)
> reproduced with F17 Beta TC1 with kickstart installation. After forced it off,
> it still cannot boot into the system.

I don't think your kickstart is complete enough to use for testing. I tried it with Beta TC1 DVD and it installed and rebooted, but the reboot didn't finish. I removed the %package section and did a minimal install and it installs and reboots just fine.
Comment 42 Hongqing Yang 2012-03-08 22:45:15 EST
(In reply to comment #41)
> (In reply to comment #40)
> > reproduced with F17 Beta TC1 with kickstart installation. After forced it off,
> > it still cannot boot into the system.
> 
> I don't think your kickstart is complete enough to use for testing. I tried it
> with Beta TC1 DVD and it installed and rebooted, but the reboot didn't finish.
> I removed the %package section and did a minimal install and it installs and
> reboots just fine.

(In reply to comment #41)
> (In reply to comment #40)
> > reproduced with F17 Beta TC1 with kickstart installation. After forced it off,
> > it still cannot boot into the system.
> 
> I don't think your kickstart is complete enough to use for testing. I tried it
> with Beta TC1 DVD and it installed and rebooted, but the reboot didn't finish.
> I removed the %package section and did a minimal install and it installs and
> reboots just fine.

I just tested, it really can reboot after remove the the packages, but it the kick start file works well with F16.
Comment 43 Adam Williamson 2012-03-10 00:13:19 EST
Hongqing, your bug here is clearly very different from the initial report. I'm re-closing this one: can you please report yours as a new bug, with the kickstart attached and an explanation that it results in a booting system with F16 but not with F17? It may be that we need to adjust comps, I guess. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 44 Chris Lumens 2012-04-10 16:55:52 EDT
*** Bug 810553 has been marked as a duplicate of this bug. ***
Comment 45 Erik Logtenberg 2013-02-26 11:54:44 EST
I am still seeing this bug when installing a Fedora 17 netinstall iso with virt-install using a kickstart file.

I'm not sure how I can figure out what the anaconda version in the netinstall iso is, exactly. I mounted the LiveOS/rootfs.img image that's inside the LiveOS/squashfs.img image that's inside the Fedora-17-x86_64-netinst.iso image (inception anyone?)
But unfortunately I don't know how to ask anaconda for its version number, neither can rpm tell me, since /var/lib/rpm is empty.

So I'm not sure if it is the exact same bug that has in fact been fixed, or another bug with the same result, but bottom line is:

Installing Fedora 17 netinstall iso with virt-install using a kickstart file works fine; the vm will however shutdown after install instead of rebooting, even though I specified "reboot" in the kickstart file. After manually starting the vm, everything appears to have installed just fine.

So shutting down instead of rebooting is the thing that goes wrong. Please advice.
Comment 46 Adam Williamson 2013-02-26 17:41:19 EST
That's a different bug. It might already be filed or you might need to file it, but it is not this bug.

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