Hide Forgot
Created attachment 479345 [details] Traceback Description of problem: I just updated my kernel to kernel-2.6.32-114.0.1.el6.x86_64 and I'm not able to boot with btrfs root. 2.6.32-71.el6.x86_64 works fine for me Version-Release number of selected component (if applicable): kernel-2.6.32-114.0.1.el6.x86_64 How reproducible: Steps to Reproduce: 1. install kernel-2.6.32-114.0.1.el6.x86_64 on machine with btrfs root 2. reboot Actual results: See screenshot Expected results: Additional info: bash-4.1$ sudo btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 3ac0e1f4-4e3c-414d-bced-c14372590725 Total devices 1 FS bytes used 4.27GB devid 1 size 9.77GB used 6.64GB path /dev/dm-0 Label: none uuid: 0ab8b872-a236-4d28-82cf-bb6c8e6b6797 Total devices 1 FS bytes used 393.61MB devid 1 size 11.72GB used 3.04GB path /dev/dm-2 Btrfs Btrfs v0.19 bash-4.1$ sudo lvscan ACTIVE '/dev/rootvg/shared_home' [11.72 GiB] inherit ACTIVE '/dev/rootvg/rhel6x64_root' [9.77 GiB] inherit ACTIVE '/dev/rootvg/swap' [2.00 GiB] inherit bash-4.1$
Have tools such as dracut changed as well since the working kernel was installed? It would be interesting to grab, say, 2.6.32-72.el6.x86_64 internally, install it (with --oldpackage) and see if you have the same problem. If so, it's possibly a dracut/mkinitramfs/support tool type change that is causing this...
Updated: dracut-004-39.el6.noarch Updated: dracut-kernel-004-39.el6.noarch
Issue does not happen with kernel-2.6.32-117.el6.x86_64
Does not happen any more with newer kernels. CURRENTRELEASE?
Occured again with kernel-2.6.32-119.el6.x86_64
kernel-2.6.32-119.el6.x86_64 dracut-kernel-004-43.el6.noarch dracut-004-43.el6.noarch kernel-2.6.32-118.el6.x86_64 works fine. Do you have any idea what might be wrong?
This is weird: title Red Hat Enterprise Linux Client (2.6.32-119.el6.x86_64) root (hd0,1) kernel /vmlinuz-2.6.32-119.el6.x86_64 ro root=/dev/mapper/rootvg-rhel6x64_root rd_LVM_LV=rootvg/rhel6x64_root rd_LVM_LV=rootvg/swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet title Red Hat Enterprise Linux Client (2.6.32-118.el6.x86_64) root (hd0,1) kernel /vmlinuz-2.6.32-118.el6.x86_64 ro root=/dev/mapper/rootvg-rhel6x64_root rd_LVM_LV=rootvg/rhel6x64_root rd_LVM_LV=rootvg/swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet initrd /initramfs-2.6.32-118.el6.x86_64.img bash-4.1$ ls /boot/ | grep 119 config-2.6.32-119.el6.x86_64 symvers-2.6.32-119.el6.x86_64.gz System.map-2.6.32-119.el6.x86_64 vmlinuz-2.6.32-119.el6.x86_64 Initramfs is completely missing
We will certainly have a look, but btrfs is a tech preview item so I do not think that this failure will be a blocker. We will investigate before changing any flags. Thanks!
Josef, can you weigh in here - is this really worth pulling into 6.1? Can it wait for 6.2?
It doesn't look like a btrfs specific issue to me, it just looks like the initramfs isn't getting created properly, so its either a dracut problem or a problem with the kernel's install post script.
Sounds like we need analysis from the dracut side?
I need the output of: # lsinitrd /boot/initramfs-....img of both images Then you can add "rdinitdebug rdbreak rdshell" and remove "quiet" and can inspect /init.log. Maybe mount /boot by hand and copy over /init.log. Maybe also the output of "dmesg".
(In reply to comment #12) > I need the output of: > # lsinitrd /boot/initramfs-....img > > of both images > > Then you can add "rdinitdebug rdbreak rdshell" and remove "quiet" and can > inspect /init.log. to the kernel command line of the failing kernel... > > Maybe mount /boot by hand and copy over /init.log. > > Maybe also the output of "dmesg".
Hi Josef. Time is running out for RHEL-6.1, so if you could please add the requested information that Harald asked in comment #12 and comment #13 we'd greatly appreciate it. Thanks & regards, Phil
I think that ideally Lubos should respond to these questions, as he was the one with the original problem? Unless Josef can reproduce...
Issue does not occur any more to me. Closing as not a bug.