Description of problem: Initrd entry in grub.conf is not created during installation process. Version-Release number of selected component (if applicable): 22.20.2-1.fc22 How reproducible: Every Time Steps to Reproduce: 1. Boot Fedora 22 Alpha Live Image [http://download.fedoraproject.org/pub/fedora/linux/releases/test/22_Alpha/Workstation/x86_64/iso/Fedora-Live-Workstation-x86_64-22_Alpha-3.iso] 2. Select manual partitioning 3. Select BTRFS partitioning scheme 4. Add swap 2G 5. Add /root 18G 6. Add /home 7. Proceed to installation 8. Add root password [FRP^qTznPOJ8&o4D] 9. Add admin user [bluestealth/FRP^qTznPOJ8&o4D] 10. reboot Actual results: Kernel Panic: Unable to Mount Root Filesystem on Unknown Block Expected results: Boot into Fedora 22 Additional info:
Created attachment 1000107 [details] Kickstart
Created attachment 1000108 [details] Installer Generated Grub.conf
Created attachment 1000109 [details] grub2-mkconfig Generated Grub.conf
Created attachment 1000110 [details] Anaconda Logs
From the logs it appears that the grub2-mkconfig was run before dracut created the initramfs. Mar 10 15:08:46 localhost anaconda[2301]: bootloader.py: used boot args: rhgb quiet Mar 10 15:08:46 localhost program[2301]: Running... grub2-set-default 0 Mar 10 15:08:46 localhost program[2301]: Running... grub2-mkconfig -o /boot/grub2/grub.cfg Mar 10 15:08:48 localhost kernel: JFS: nTxBlock = 8192, nTxLock = 65536 Mar 10 15:08:48 localhost logger[19036]: os-prober: debug: /dev/sda1: is active swap Mar 10 15:08:48 localhost logger[19036]: os-prober: debug: btrfs volume uuid=b05e7aa9-9f11-4e08-90d2-f9ed8c778be0 partition=/dev/sda2 Mar 10 15:08:48 localhost logger[19036]: os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on btrfs /dev/sda2 Mar 10 15:08:48 localhost logger[19036]: 50mounted-tests: debug: begin btrfs processing for b05e7aa9-9f11-4e08-90d2-f9ed8c778be0 Mar 10 15:08:48 localhost logger[19036]: 50mounted-tests: debug: btrfs volume b05e7aa9-9f11-4e08-90d2-f9ed8c778be0 mounted Mar 10 15:08:48 localhost logger[19036]: 50mounted-tests: debug: begin btrfs processing for b05e7aa9-9f11-4e08-90d2-f9ed8c778be0 subvol=root Mar 10 15:08:48 localhost logger[19036]: 50mounted-tests: debug: begin btrfs processing for b05e7aa9-9f11-4e08-90d2-f9ed8c778be0 subvol=home Mar 10 15:08:48 localhost logger[19036]: 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90linux-distro Mar 10 15:08:48 localhost program[2301]: Generating grub configuration file ... Mar 10 15:08:48 localhost program[2301]: Found linux image: /boot/vmlinuz-4.0.0-0.rc1.git0.1.fc22.x86_64 Mar 10 15:08:48 localhost program[2301]: Found linux image: /boot/vmlinuz-0-rescue-f46c43d9c85e47538a0898451bd52803 Mar 10 15:08:48 localhost program[2301]: Found initrd image: /boot/initramfs-0-rescue-f46c43d9c85e47538a0898451bd52803.img Mar 10 15:08:48 localhost program[2301]: done Mar 10 15:08:48 localhost anaconda[2301]: Installing boot loader Mar 10 15:08:48 localhost anaconda[2301]: Performing post-installation setup tasks Mar 10 15:08:48 localhost program[2301]: Running... umount /run/install/source Mar 10 15:08:48 localhost anaconda[2301]: Performing post-installation setup tasks ---------------------------------------------------------------------------- Mar 10 15:08:53 localhost.localdomain anaconda[2301]: Generating initramfs Mar 10 15:08:53 localhost.localdomain packaging[2301]: recreating initrd for 4.0.0-0.rc1.git0.1.fc22.x86_64 Mar 10 15:08:53 localhost.localdomain program[2301]: Running... new-kernel-pkg --mkinitrd --dracut --depmod --update 4.0.0-0.rc1.git0.1.fc22.x86_64
Created attachment 1000213 [details] Move location of writeBootLoader
On the one hand, this is bug 864198. On the other hand, the installer is producing an invalid installation that has no chance of booting. If Anaconda changes its behavior to call grub2-mkconfig later, the problem is fixed at install time. But then due to the grubby bug, subsequent kernel updates never get a menu entry, which is a potential security risk. What's needed is for grubby to incorporate the patches supplied by Gene Czarcinski some time ago. Anaconda 19/20 proscribed /boot being on a Btrfs subvolume in order to meet release criteria. I don't know why this was changed for Fedora 21, but the bug is there now too, not just on 22.
Proposed as a Blocker for 22-beta by Fedora user chrismurphy using the blocker tracking app because: A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention... AND No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional.
Discussed at Fedora Blocker Review Meeting 2015-03-16 [0]: AcceptedBlocker Beta - This bug is a clear violation of the Beta criterion[1]: "When using the custom partitioning flow, the installer must be able to: Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes AND Reject or disallow invalid disk and volume configurations without crashing." [0] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-16/f22-blocker-review.2015-03-16-16.01.log.txt [1] https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Custom_partitioning
We really don't support /boot on btrfs yet. This needs to be turned back off. Also related to bug 1094489.
(In reply to bcl from comment #10) > We really don't support /boot on btrfs yet. It's a dual bug. Anaconda currently depends on grubby to fix a problem that's the direct result of anaconda calling grub2-mkconfig early enough that often an initramfs doesn't exist yet. This problem happen on all file systems, not just Btrfs. It's just that grubby doesn't mask this problem on Btrfs. The correct thing happens if grub2-mkconfig is called just a bit later. The correct thing happens on all other distros now supporting /boot on Btrfs because they don't use grubby anymore. So, we're kinda behind on this.
This bug is not reproducible on netinstalls, it only happens with live installs. What's happening is, Anaconda rsyncs everything on lives, excluding the initramfs, and then grub2-mkconfig is called before new-kernel-pkg is called to make the initramfs; so no matter the filesystems, the grub.cfg lacks an initrd line for the primary boot entry. Once new-kernel-pkg is run, it runs grubby which fixes the missing initrd line, except on Btrfs. On netinstalls, the kernel RPM package is installed, which causes an initramfs to be created, and grub2-mkconfig runs after this, which is why the problem doesn't happen.
anaconda-22.20.6-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/anaconda-22.20.6-1.fc22
(In reply to Fedora Update System from comment #13) > anaconda-22.20.6-1.fc22 has been submitted as an update for Fedora 22. > https://admin.fedoraproject.org/updates/anaconda-22.20.6-1.fc22 This fixed the problem for me.
(In reply to Fedora Update System from comment #13) > anaconda-22.20.6-1.fc22 has been submitted as an update for Fedora 22. > https://admin.fedoraproject.org/updates/anaconda-22.20.6-1.fc22 This also fixed the problem for me.
Fixed. Bug 864198 is still a problem so kernel updates do not get new GRUB entries.
Package anaconda-22.20.6-1.fc22, python-blivet-1.0.5-1.fc22, libblockdev-0.7-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-22.20.6-1.fc22 python-blivet-1.0.5-1.fc22 libblockdev-0.7-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-4351/libblockdev-0.7-1.fc22,python-blivet-1.0.5-1.fc22,anaconda-22.20.6-1.fc22 then log in and leave karma (feedback).
anaconda-22.20.6-1.fc22, python-blivet-1.0.5-1.fc22, libblockdev-0.7-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
I just ran into the very same problem with anaconda-22.20.11-1.fc22, but on an ext3 filesystem. I talked to Vojtech Trefny and Martin Kollman and we figured out that on F22 it is probably necessary to call writeBootLoader() even for non-BTRFS filesystem. We took this patch [0] and changed boot_on_btrfs to be always True, which solved the problem. [0] https://github.com/rhinstaller/anaconda/commit/0fc01e834082f20896728f330faea8e0b200a159
You are likely hitting a different problem, bug 1215839 which was fixed by a grub2 update yesterday.