Bug 1199517
Summary: | Upgrade from Fedora 20 to 21 fails to boot, /root on BCACHE not found | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Juha Luoma <jsluoma> | ||||
Component: | fedup-dracut | Assignee: | Will Woods <wwoods> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 21 | CC: | llowrey, tflink, wwoods | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-11-11 15:30:01 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Juha Luoma
2015-03-06 14:41:15 UTC
lsinitrd /boot/initramfs-3.18.7-100.fc20.x86_64.img ... dracut modules: bash i18n network ifcfg drm plymouth bcache dm kernel-modules lvm fcoe fcoe-uefi resume rootfs-block terminfo udev-rules biosdevname systemd usrmount base fs-lib shutdown uefi-lib ======================================================================== but lsinitrd /boot/initramfs-fedup.img ... dracut modules: bash modsign mlx4 rdma i18n network ifcfg drm plymouth system-upgrade-fedora btrfs crypt dm dmraid kernel-modules lvm mdraid multipath system-upgrade fcoe fcoe-uefi iscsi nfs resume rootfs-block terminfo udev-rules ostree systemd usrmount base fs-lib shutdown uefi-lib ======================================================================== So is the issue that bcache dracut module is missing from initramfs-fedup.img? I encountered this doing the exact same thing. The bcache module was loaded but neither the cache device nor the backing device were registered to bcache. I had to manually do: echo /dev/Flash/Cache > /sys/fs/bcache/register echo /dev/md1 > /sys/fs/bcache/register then: lvm pvscan lvm vgchange -ay There is a script that is put in the regular initramfs that performs these actions. It appears that fedup does not put this script in its initramfs. Thanks for the hint! In my system this worked: Immediately when shell at tty2 was available I issued these commands: modprobe bcache echo /dev/sdb2 > /sys/fs/bcache/register echo /dev/sda2 > /sys/fs/bcache/register Then upgrade ran through normally. Hrm. bcache isn't in the default dracut package - that module is only there if you install bcache-tools. Which is why it's not in the generic initramfs generated by dracut... ..but fedup tries to pick up anything that's in your initramfs that's not in the generic initramfs. Could you attach full `lsinitrd` output? (Preferably from a F21 system.) Created attachment 1002438 [details]
lsinitrd of initramfs-3.18.9-200.fc21.x86_64.img
This lsinitrd of initramfs-3.18.9-200.fc21.x86_64.img is from my system now running F21.
Quick question: How did you install a system with root on bcache if the installer doesn't support bcache? I did use some instructions for how to test bcache when bcache support was initially introduced to Fedora. Don't have the link available right now, but it involved some manual steps after initial installation. So, there's a general problem here: You're using a root device that's unsupported by the installer or (generic) dracut. This means your system needs some 3rd-party code to boot.. but the upgrade image doesn't have that code in it. This is a long-standing problem with upgrades. It's not new in fedup - the old installer-based upgrades wouldn't handle this either. I've opened this issue about that general problem: https://github.com/rhinstaller/fedup/issues/62 As for this specific problem with bcache: I *would* say that the bcache module should go into upstream dracut - and bug 1003207 indicates that some versions of dracut *did* have builtin bcache support - but it seems that it was removed (and moved to bcache-tools) in dracut-034 (i.e. sometime before F20). So.. unless someone convinces the dracut/bcache maintainers to put bcache support back into the generic dracut package, you're kind of stuck. For now, if anyone else hits this bug, they're going to have to use the workaround described in comment #2. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Upgrade of the affected system from 21 directly to 23 using "dnf system-upgrade download --releasever 23" worked just fine. Okay then - since Fedora 20 is EOL, I can't really fix anything there, but the workaround from comment #2 should still let you get to F21. (F20 users could also try a live yum/dnf upgrade, as described here: https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager) If you've got F21 or higher, dnf-plugin-system-upgrade should work just fine.(confirmed in comment #10 - thanks for the feedback!) At this point, both F21 and fedup are (about to be) EOL, so I'm closing this bug accordingly. |