Bug 787461

Created attachment 559449 [details]
audit log

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.

Please attach log files as individual, uncompressed attachments.  Doing anything else prevents us from easily searching bugzilla in the future.  Thanks.

noted

Created attachment 560107 [details]
syslog

Created attachment 560108 [details]
anaconda log

Created attachment 560109 [details]
program log

Created attachment 560110 [details]
storage log

Is the virt using a virtio disk or ata? tflink has seen a similar problem when using virtio disks.

For me, it's using virt-manager's default virtio.

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 also happens with F17 Alpha TC2 with VNC installation.

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.

reproduced with F17 Alpha RC2
Error shows on the terminal:
systemd-shutdow[1]:segfault at 7f67d6ab87d7 ip 00007f67d6ab87d7 sp 0007fffb1fbdc18 error 14

(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

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

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.

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> _

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.

interestingly, /var/log/anaconda/* on the installed system are zero-length.

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.

CC Lennart for the systemd segfault.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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

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.

*** Bug 789218 has been marked as a duplicate of this bug. ***

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.

Here's an updates image to test with: http://bcl.fedorapeople.org/updates/787461.img

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.

(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.

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

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).

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.

anaconda-17.10-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.10-1.fc17

Works fine in 17 Alpha RC3, doing non-networked DVD minimal installs for both i386 and x86_64.

anaconda-17.11-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.11-1.fc17

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).

This is fixed with anaconda-17.11-1.fc17

Created attachment 564872 [details]
kickstart file

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.

reproduced with F17 Beta TC1 with kickstart installation. After forced it off, it still cannot boot into the system.

(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.

(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.

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

*** Bug 810553 has been marked as a duplicate of this bug. ***

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.

That's a different bug. It might already be filed or you might need to file it, but it is not this bug.