Hide Forgot
Created attachment 835474 [details] rdsosreport.txt from dracut Description of problem: The newest kernel 3.11.10-301 can NOT boot. Version-Release number of selected component (if applicable): This is a F20 beta. After the successful install an update was carried out. The new kernel is vmlinuz-3.11.10-301.fc20.x86_64. This kernel is unbootable. How reproducible: Update your kernel to this version, and use LVM Steps to Reproduce: 1.Install F20 beta 2.Update with the latest packages 3.Reboot Actual results: The boot process terminated and give a prompt. It looks like, the LVM module is not loaded during boot process. Expected results: The kernel should boot. Additional info:
dracut-034-64.git20131205.fc20.1 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dracut-034-64.git20131205.fc20.1
Please update dracut to dracut-034-64.git20131205.fc20.1 and run: # dracut -f --kver 3.11.10-301.fc20.x86_64 Check, if the resulting initramfs contains the lvm thin tools: # lsinitrd --kver 3.11.10-301.fc20.x86_64 | grep thin_
Package dracut-034-64.git20131205.fc20.1: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-034-64.git20131205.fc20.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23326/dracut-034-64.git20131205.fc20.1 then log in and leave karma (feedback).
So if I'm reading this right, harald, you committed the 'optimization' to the LVM thinp stuff on 2013-12-05, put this entirely needless change in the dracut build you sent to Fedora on the *same day* (so it can hardly have been well tested) which was intended as a blocker/FE bug fix during a freeze, and then didn't put it in either the package changelog: * Thu Dec 05 2013 Harald Hoyer <harald> 034-64.git20131205 - fixed failing the boot while waiting for password input * Thu Dec 05 2013 Harald Hoyer <harald> 034-62.git20131205 - fixed PATH shortener - also install /etc/system-fips in the initramfs - nbd, do not fail in hostonly mode - add ohci-pci to the list of hardcoded modules - lvm: do not run pvscan for lvmetad - skip crypt swaps with password files - fixed i18n or the update: fixed failing the boot while waiting for password input fixed PATH shortener also install /etc/system-fips in the initramfs nbd, do not fail in hostonly mode add ohci-pci to the list of hardcoded modules lvm: do not run pvscan for lvmetad skip crypt swaps with password files fixed i18n I mean, we do our best, but it's pretty hard to account for this kind of thing. There's a reason I'm always asking for changes during freeze to be *minimal and conservative*. It's not just me being an annoying QA nerd.
Docs folks: the upshot of this, at least according to my initial testing, is simply that any LVM thinp install of F20 will not boot. thinp is mentioned as a new feature in the release notes, that needs a huge warning added to it, and anywhere else we mention thinp we need to talk about this, I guess. I'll continue testing. I would've thought using the rescue kernel would be a workaround, but that doesn't seem to be the case for whatever reason; I need to investigate that more.
Christ, I know why rescue mode doesn't work: the original change here was broken in multiple ways. - inst_multiple -o thin_dump thin_restore thin_check thin_repair + if [[ $hostonly ]] && type -P lvs &>/dev/null; then + for dev in "${!host_fs_types[@]}"; do + if [[ "$(lvs --noheadings -o segtype "$dev" 2>/dev/null)" == *thin* + inst_multiple -o thin_dump thin_restore thin_check thin_repair + fi + done + fi before the change, whether we're in 'hostonly' or 'generic' mode, we're getting the tools. not super space efficient, okay, but *safe*. after the change, we're getting the tools in hostonly mode if we pass the check, only the check is broken (that's the first bug here). But in generic mode - the mode where it's *really important* that everything always gets included - because there's no 'else' to the 'if [[ $hostonly ]]', we get nothing. so, this change broke both hostonly and generic initramfs'es. two for one! great.
commonbugs note has rescue instructions.
well, your tips didn't resolve the issue. neither whiteboard nor https://bugzilla.redhat.com/show_bug.cgi?id=1040669#c2 or https://bugzilla.redhat.com/show_bug.cgi?id=1040669#c3 :( I removed the 3.11.10-301.fc20.x86_64 kernel and the modules-extra packages then I installed the kernel-headers-3.11.10-301.fc20.x86_64 kernel-devel-3.11.10-301.fc20.x86_64 kernel-modules-extra-3.11.10-301.fc20.x86_64 kernel-3.11.10-301.fc20.x86_64 RPMs. Then the issue is solved :) [balint@lenovo ~]$ uname -r 3.11.10-301.fc20.x86_64
balint: reinstalling the kernel will cause the initramfs to be re-generated, but just running 'dracut -f' will do so too. Oh, the dracut update was only pushed to mirrors today, so the command in the commonbugs note won't necessarily actually install it right now, as it might not have made it to all the mirrors. You have to make sure you actually get the new dracut before rebuilding the initramfs. I did test the steps I recommended - booting rescue mode, chrooting into the installed system, updating dracut, running 'dracut -f', and rebooting. It worked.
I know that kernel reinstalling recreate the initramfs by dracut. I have run the rescue mode, 'dracut -f' and the other stuff but it didn't solve the boot problem. Now, after the kernel-* reinstalling the system booted properly. I don't get it. The lsinitrd command didn't say anything about lvm thinp but definitely I use it. [root@lenovo balint]# lsinitrd |more Image: /boot/initramfs-3.11.10-301.fc20.x86_64.img: 14M ======================================================================== dracut-034-64.git20131205.fc20.1 with dracut modules: I could find the lvm thinp module: bash i18n ifcfg drm plymouth dm kernel-modules lvm resume rootfs-block terminfo udev-rules biosdevname systemd usrmount base fs-lib shutdown [root@lenovo balint]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert home vg_lenovo Vwi-aotz-- 347.66g pool00 11.51 pool00 vg_lenovo twi-a-tz-- 445.51g 10.87 root vg_lenovo Vwi-aotz-- 97.86g pool00 8.58 swap vg_lenovo -wi-ao---- 3.91g
balint: if you do 'lsinitrd | grep thin' you should see a few binaries in /usr/bin in the working case; in the broken case they're missing. There isn't a separate dracut module for lvm thinp, the bit that installs the thinp tools is part of the 'lvm' module.
aaah, okay, Now it's clear. [root@lenovo bin]# lsinitrd |grep thin -rw-r--r-- 1 root root 1737 Nov 27 10:13 usr/lib/kbd/consolefonts/gr928-8x16-thin.psfu.gz -rw-r--r-- 1 root root 74279 Dec 5 14:18 usr/lib/modules/3.11.10-301.fc20.x86_64/kernel/drivers/md/dm-thin-pool.ko -r-xr-xr-x 1 root root 14616 Dec 14 07:30 usr/lib64/device-mapper/libdevmapper-event-lvm2thin.so lrwxrwxrwx 1 root root 44 Dec 14 07:30 usr/lib64/libdevmapper-event-lvm2thin.so -> device-mapper/libdevmapper-event-lvm2thin.so -rwxr-xr-x 1 root root 384648 Dec 14 07:30 usr/sbin/thin_check -rwxr-xr-x 1 root root 2184112 Dec 14 07:30 usr/sbin/thin_dump -rwxr-xr-x 1 root root 2179792 Dec 14 07:30 usr/sbin/thin_repair -rwxr-xr-x 1 root root 2179928 Dec 14 07:30 usr/sbin/thin_restore There are they. Yep, you were right. Sorry.
dracut-034-64.git20131205.fc20.1 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1024758 has been marked as a duplicate of this bug. ***