Bug 244454
Summary: | kernel upgrade hang in lvm-static (mkinitrd) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Axel Thimm <axel.thimm> | ||||||
Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> | ||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Martin Jenner <mjenner> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.0 | CC: | agk, boris | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2010-06-23 12:34:46 UTC | Type: | --- | ||||||
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
Axel Thimm
2007-06-15 19:19:02 UTC
I have the same problem on RHEL 5.3! The affected system has been carefully upgraded from 4.7 using a 5.3 DVD. All issues with .rpmsave/.rpmnew have been solved. Everything is working fine, besides the problem with kernel upgrades. Here's my process tree: 9909 | - /usr/bin/python /usr/bin/yum upgrade 10510 | - /bin/sh /var/tmp/rpm-tmp.20713 3 10512 | - /bin/bash /sbin/new-kernel-pkg --package kernel-PAE --mkinitrd --depmod --install 2.6.18-128.1.10.el5PAE 10521 | - /bin/bash --norc /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.18-128.1.10.el5PAE.img 2.6.18-128.1.10.el5PAE 10649 | - /bin/bash --norc /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.18-128.1.10.el5PAE.img 2.6.18-128.1.10.el5PAE 10650 D | - lvm.static lvs --ignorelockingfailure --noheadings -o vg_name /dev/md1 I don't know for what this lvm.static call is. /dev/md1 is used for swap only. The only LVM2 physical volume I have is on /dev/md2. /dev/md0 is directly used for /boot. All three /dev/mdX are a RAID1 of two IDE HDs. Nevertheless I found out why it is hanging! Running strace lvm.static lvs --ignorelockingfailure --noheadings -o vg_name /dev/md1 instead of strace -p PID as Axel tried gave me the whole picture: lvm.static is trying to access /dev/cdrom. This fails as there is no CD in the drive. If there is a CD in the drive, the kernel upgrade succeeds! The drive is a Panasonic slot-in IDE CD-ROM. Please fix that problem as it is really annoying and certainly a bug. This is 100% reproducible and happens everytime on my system. - lvm.static lvs --ignorelockingfailure --noheadings -o vg_name /dev/md1 (1) Why is this running lvm.static instead of lvm? (lvm.static is deprecated and nothing should be using it any more.) (2) Why is it ignoring locking failure when run as a normal process on the system? (Because sometimes in other cases does it have to be run in environments that need that argument?) (3) Why is it using 'lvs' to output a VG property? ('vgs' would suffice.) (4) Why is it asking LVM to say whether or not there is a VG called 'md1'? As /sbin/mkinitrd is a shell script I added a set -x at the top and called /sbin/mkinitrd --allow-missing -f /boot/initrd-testing.img 2.6.18-128.1.10.el5PAE It's now hanging at lvm.static lvs --ignorelockingfailure --noheadings -o vg_name /dev/Volume00/root making no progress. Please see the attached output from set -x which reveals every command that is called. Created attachment 343450 [details]
Trace produced using set -x
I could simply Ctrl-c lvm.static. To show you that it hangs at open("/dev/cdrom", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME I called strace -p lvm.static lvs --ignorelockingfailure --noheadings -o vg_name /dev/Volume00/root Please see the attached output. Note that /dev/Volume00/root is an ext3 logvol and mounted as / Created attachment 343451 [details]
strace output for lvm call
There were some changes to mkinird to cache dm devices (and not scan everything, bug #516047) so kernel update should be quick even with many DM/LVM devices. For the hang on opening /dev/cdrom - this is possibly other problem, I think it must block even other commands? like "blkid -p /dev/cdrom" or blockdev --getsz /dev/cdrom? (this is then maybe kernel problem) For now closing that, if you still see the problem with recent update, please reopen it with new logs, thanks. |