Bug 2004822 - Update to kernel 5.14 makes disks disapear/system unbootable on Xen-server
Summary: Update to kernel 5.14 makes disks disapear/system unbootable on Xen-server
Keywords:
Status: CLOSED DUPLICATE of bug 2010058
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-16 06:39 UTC by Dennis Glindhart
Modified: 2021-10-29 21:33 UTC (History)
19 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-10-29 21:33:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
After timeout reached (43.54 KB, image/png)
2021-09-16 06:39 UTC, Dennis Glindhart
no flags Details

Description Dennis Glindhart 2021-09-16 06:39:03 UTC
Created attachment 1823527 [details]
After timeout reached

1. Please describe the problem:

Updating to a kernel 5.14 (from Koji) makes system unbootable when running on top of Xen-server.

This seems like a general kernel 5.14 bug, not specific to Fedora as same problem occurs on openSuSE/Tumbleweed with 5.14 kernel. (Crossposted here: https://bugzilla.opensuse.org/show_bug.cgi?id=1190326)

On Fedora during boot it hangs after "Reached target Basic System" and times out waiting for /dev/disk/by-uuid/xxxx

It seems like kernel cannot identify the disks at all (working fine on 5.13)

After entering the recovery-mode, following is observed:

- lsblk shows only the CD-rom drive
- ls /dev/disk/ only has by-path and by-id. by-uuid directory is gone.

2. What is the Version-Release number of the kernel:

kernel-core-5.14.3-300.fc34 (Downloaded as pr. https://fedoraproject.org/wiki/Test_Day:2021-09-12_Kernel_5.14_Test_Week)

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

5.13 working fine. All versions of 5.14.x seems to be at fault. Tested up to (and including) 5.14.3


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

On stable Fedora 34, install a 5.14 kernel from Koji (https://fedoraproject.org/wiki/Test_Day:2021-09-12_Kernel_5.14_Test_Week) while running on top of a Xen-based hypervisor.

Can be reproducedwith both clean BTRFS and XFS/LVM install, so not specific to BTRFS filesystem

Reproduced on two seperate XCP-ng 8.2 (xen-based) Hypervisors.

From hypervisors:
# yum info qemu
Installed Packages
Name        : qemu
Arch        : x86_64
Epoch       : 2
Version     : 2.10.2
Release     : 4.5.3.xcpng8.2
Size        : 19 M
Repo        : installed
From repo   : install
Summary     : qemu-dm device model
License     : GPL
Description : This package contains Qemu.

# uname -a
Linux hostname 4.19.0+1 #1 SMP Wed Dec 16 12:16:11 CET 2020 x86_64 x86_64 x86_64 GNU/Linux


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
N/A

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 David Baron 2021-10-04 19:41:11 UTC
Bug 2010058 appears to be the same bug.

(Manually applying the upstream fix (found via https://bugzilla.redhat.com/show_bug.cgi?id=2010058 linked above) in https://github.com/dracutdevs/dracut/commit/b292ce72 to /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh and then reinstalling the 5.14 kernel fixed the similar problem I was having.)

Comment 2 Dennis Glindhart 2021-10-29 21:33:21 UTC
Seems #2010058 gained momentum - Closing this as duplicate.

*** This bug has been marked as a duplicate of bug 2010058 ***


Note You need to log in before you can comment on or make changes to this bug.