Red Hat Bugzilla – Bug 1012646
anaconda creates grub.cfg lacking an initrd entry, kernel panics on reboot
Last modified: 2014-05-22 20:11:52 EDT
Description of problem: An installation of Fedora 20 alpha completes without errors, but on reboot immediately kernel panics. Upon inspection, the grub.cfg has two suspicious missing items. a.) The linuxefi line uses root=/dev/sda7 instead of root=UUID. b.) The grub.cfg is missing initrdefi lines Starting over and repeating the install process, after successful completion I collect the anaconda grub.cfg, and manually create a new one within the install environment by chroot /mnt/sysimage and then running grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg to overwrite the anaconda one. The system then boots. I don't know why the manually run grub2-mkconfig command produces a grub.cfg with root=UUID and with initrdefi line; while the anaconda one does not. Perhaps the initramfs has not yet been generated at the time the grub2-mkconfig command was executed? Version-Release number of selected component (if applicable): anaconda 20.20-1 How reproducible: Always. Steps to Reproduce: 1. Boot EFI Mac with Fedora 20 Desktop alpha (RC4/final) 2. Manual partitioning comprised of: /boot/efi, swap, and a single Btrfs volume with root, boot, home subvolumes. 3. Begin installation, reboot upon successful completion. Actual results: kernel panic Expected results: Boot to Gnome shell. Additional info:
Created attachment 803550 [details] anaconda grub.cfg This is the grub.cfg produced by anaconda.
Created attachment 803551 [details] manually created grub.cfg After a successful install, but still booted in the install environment, I switch to a shell and run: chroot /mnt/sysimage grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg This is that grub.cfg.
Created attachment 803552 [details] anaconda.log
Created attachment 803553 [details] program.log
Created attachment 803554 [details] storage.state
Created attachment 803555 [details] storage.log
Proposing as beta blocker: "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so."
Based on program.log 14:17:16,371 INFO program: Running... grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg 14:17:23,121 INFO program: Generating grub.cfg ... 14:17:23,122 INFO program: Found linux image: /boot/vmlinuz-3.11.0-300.fc20.x86_64 and... 14:17:26,235 INFO program: Running... new-kernel-pkg --mkinitrd --dracut --depmod --update 3.11.0-300.fc20.x86_64 Yep. The initramfs isn't created at the time grub2-mkconfig is called. That explains the missing initrdefi line in the anaconda grub.cfg; but not why root is referenced as /dev/sda7 instead of by UUID.
14:17:10,958 INFO program: rsync: read errors mapping "/mnt/install/source/usr/lib64/libicudata.so.50.1.2": Input/output error (5) 14:17:10,958 INFO program: rsync: read errors mapping "/mnt/install/source/usr/lib64/libicudata.so.50.1.2": Input/output error (5) 14:17:10,959 INFO program: ERROR: usr/lib64/libicudata.so.50.1.2 failed verification -- update discarded. 14:17:10,960 INFO program: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.0pre1] 14:17:10,960 DEBUG program: Return code: 23 The install didn't finish. What does syslog look like? Yes, I have to improve how we catch rsync errors, some of them are meaningful, and a pile of them aren't. "failed verification -- update discarded." sounds like either bad media or a bad drive.
Good question. I don't have /tmp/syslog and didn't think to write out the systemd-journal. So I have a reproducer of these errors in the same order, and I'll attach a journal of that. It shows grub2-mkconfig being called before dracut. It also shows many SQUASHFS errors. I ran badblocks on the media, a USB stick, and there are no errors. The ISO dd'd to the media passes checksums. The option in the EFI menu to check the media fails, but that's always failed for me on Mac EFI systems.
Created attachment 803650 [details] journalctl output journalctl output after completed install. FWIW there is no longer a /tmp/syslog being created due to feature NoDefaultSyslog. It might be useful for anaconda to run journalctl to a file in /tmp in case it's needed.
Replaced install media. I no longer get SQUASHFS errors in journal, I do still get some rsync errors in program.log, but not the two i/o ones you found. The grub.cfg still lacks an initrdefi entry, and I still get a kp. I'll post new logs for this attempt.
Created attachment 803677 [details] c12, anaconda.log
Created attachment 803678 [details] c12, journalctl
Created attachment 803679 [details] c12, program.log
Created attachment 803680 [details] c12, storage.log
USB Flash sometimes fails in odd ways. The xattr errors are 'normal' since that fs doesn't support them. That's the primary reason we ignore most rsync errors -- but that's not enough. Looks like I'll need to start parsing the output for errors.
With new install media on baremetal, or on a totally separate system in a VM, I can always reproduce this bug as originally described. I think I know why, it's just a matter of which components bug this is: 1. anaconda always calls grub2-mkconfig before it calls new-kernel-pkg to create the initramfs. Therefore the grub.cfg entries all lack initrd lines. 2. new-kernel-pkg not only creates the initramfs, but it also calls grubby which edits the grub.cfg, and fixes the above problem. 3. Due to grubby bug 864198, the problem in 1 is not fixed if boot is a btrfs subvolume. In Fedora 19 I was able to put boot on Btrfs and get a working installation, so I don't know what changed. Bug 864198 merely prevented kernel updates from updating grub.cfg. But now since it causes installations to effectively be broken on reboot, I'm thinking the blocker goes against grubby. Alternative, the installer would need to disallow boot on Btrfs, which would be sad.
Discussed this in the 2013-10-02 Blocker Review Meeting [1]. This has been voted a RejectedBlocker. This is a problem but the actual bug is in grubby, not anaconda and in this case, anaconda is behaving as expected. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/
Note that the bug for grubby is https://bugzilla.redhat.com/show_bug.cgi?id=864198 . Is there any purpose to this bug remaining open any longer, or should we close it as a dupe of that one?
Other than the possibility there's been an unintended change to anaconda that explains this regression from F19, no.
Let's close for now then, for clarity. We can re-open if necessary. *** This bug has been marked as a duplicate of bug 864198 ***