Cannot reproduce at will. But I've been running lshw between reboots lately on this system and comparing. With *no* change in inventory, sometimes it reports the block device... scsi@1:0.0.0,1 /dev/sdb1 volume 50GiB Linux raid autodetect partition ...and sometimes it doesn't... scsi@1:0.0.0,1 volume 50GiB Linux raid autodetect partition The disk is still there. I have two with identical geometry and partitioning. Both have md mirrors of partitions--not of raw block device. RAID is consistent/healthy. Here's more detail in the form of a patchlet hunk showing the three lines changed: *-disk:1 description: ATA Disk product: WDC WD3202ABYS-0 vendor: Western Digital physical id: 1 bus info: scsi@1:0.0.0 logical name: /dev/sdb version: 02.0 serial: xxx size: 298GiB (320GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=00084d83 - *-volume:0 + *-volume:0 UNCLAIMED description: Linux raid autodetect partition physical id: 1 bus info: scsi@1:0.0.0,1 - logical name: /dev/sdb1 capacity: 50GiB capabilities: primary multi *-volume:1 description: EXT3 volume vendor: Linux physical id: 2 bus info: scsi@1:0.0.0,2 logical name: /dev/sdb2 version: 1.0 serial: xxx size: 199MiB capacity: 200MiB capabilities: primary bootable multi journaled extended_attributes recover ext3 ext2 initialized - configuration: created=2010-08-24 22:50:51 filesystem=ext3 modified=2010-08-26 08:57:43 mounted=2010-08-26 08:57:43 state=clean + configuration: created=2010-08-24 22:50:51 filesystem=ext3 modified=2010-08-27 08:15:02 mounted=2010-08-27 08:15:02 state=clean *-volume:2 description: Linux LVM Physical Volume partition physical id: 3 bus info: scsi@1:0.0.0,3 logical name: /dev/sdb3 serial: xxx size: 247GiB capacity: 247GiB capabilities: primary multi lvm2 I cannot reproduce at will, but between reboots it still seems to shift periodically between the two views above. Also, it appears to be erroneously reporting sdb2 as EXT3 volume. It's actually a Linux raid autodetect partition; same as sdb1. Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 6528 52432896 fd Linux raid autodetect /dev/sda2 * 6528 6554 204800 fd Linux raid autodetect /dev/sda3 6554 38914 259932160 8e Linux LVM Disk /dev/sdb: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 6528 52432896 fd Linux raid autodetect /dev/sdb2 * 6528 6554 204800 fd Linux raid autodetect /dev/sdb3 6554 38914 259932160 8e Linux LVM Note the setup is indeed a bit unusual in that the disks are partitioned: - sd{a,b}1 is an md mirror with an ext3 filesystem - sd{a,b}2 is an md mirror with an LVM PV (and some ext4 filesystems) - sd{a,b}3 are plain ol' LVM PVs (with a few more filesystems)
Thanks for you report, I have sent your bugreport upstream: http://ezix.org/project/ticket/529
Hi Curtis, could you try this update and check if things are better: https://admin.fedoraproject.org/updates/lshw-B.02.15-1.fc13
I still have the original test platform where this was occurring. However, it was upgraded to B.02.14-5, so I first rebooted and tested with this build a few times. With B.02.14-5, it didn't report inconsistent results anymore. But it consistently reported one mdraid partition as UNCLAIMED, even though it has a valid block device name in the kernel: And now after upgrading to B.02.15-1, I get similar results: *-disk:0 description: ATA Disk product: WDC WD3202ABYS-0 vendor: Western Digital physical id: 0 bus info: scsi@0:0.0.0 logical name: /dev/sda version: 02.0 serial: ... size: 298GiB (320GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=0006d010 *-volume:0 UNCLAIMED description: Linux raid autodetect partition physical id: 1 bus info: scsi@0:0.0.0,1 capacity: 45GiB capabilities: primary multi *-volume:1 description: EXT3 volume vendor: Linux physical id: 2 bus info: scsi@0:0.0.0,2 logical name: /dev/sda2 version: 1.0 serial: ... Notice, in addition to the "volume:0 UNCLAIMED" above, it's also missing the "logical name: /dev/sda1" line that I would expect. And whereas, the pair mate still looks normal. Which is different to lshw as it isn't UNCLAIMED and has a logical name: *-disk:1 description: ATA Disk product: WDC WD3202ABYS-0 vendor: Western Digital physical id: 1 bus info: scsi@1:0.0.0 logical name: /dev/sdb version: 02.0 serial: ... size: 298GiB (320GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=00085ccf *-volume:0 description: Linux raid autodetect partition physical id: 1 bus info: scsi@1:0.0.0,1 logical name: /dev/sdb1 capacity: 45GiB capabilities: primary multi *-volume:1 description: EXT3 volume vendor: Linux physical id: 2 bus info: scsi@1:0.0.0,2 logical name: /dev/sdb2 version: 1.0 serial: ...
Same symptom on F-14 with B.02.15-1.fc14 on exact same platform. Both md partitions are recognized and active. However one usually shows up as UNCLAIMED instead of logical name /dev/sda1. And today, once only, it realized that one partition is actually claimed by the kernel. First, here's the brief -businfo output as a diff: @@ -66,7 +66,7 @@ scsi@0:0.0.0,2 /dev/sda2 volume 200MiB EXT3 volume scsi@0:0.0.0,3 /dev/sda3 volume 252GiB Linux LVM Physical Volume partition scsi@1:0.0.0 /dev/sdb disk 320GB WDC WD3202ABYS-0 -scsi@1:0.0.0,1 volume 45GiB Linux raid autodetect partition +scsi@1:0.0.0,1 /dev/sdb1 volume 45GiB Linux raid autodetect partition scsi@1:0.0.0,2 /dev/sdb2 volume 200MiB EXT3 volume scsi@1:0.0.0,3 /dev/sdb3 volume 252GiB Linux LVM Physical Volume partition pci@0000:00:1f.3 bus 82801JI (ICH10 Family) SMBus Controller And here's the more verbose output hunk, also as a diff: @@ -1366,10 +1366,11 @@ size: 298GiB (320GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=000888fe - *-volume:0 UNCLAIMED + *-volume:0 description: Linux raid autodetect partition physical id: 1 bus info: scsi@1:0.0.0,1 + logical name: /dev/sdb1 capacity: 45GiB capabilities: primary multi *-volume:1
Idea... Maybe it's not intermittent. I'm testing a build system. And constantly rebuilding the underlying mdraid. I just noticed the md superblocks also changed with the odd lshw symptom above. Does lshw look at the md superblock to decide what block devices are claimed by the kernel? In both scenarios above, the md raid1 mirror was consistent. But in one, the superblock reported status "active" and during the other it reported status "clean". So maybe lshw isn't properly deducing one of those scenarios?
Hm, can you post output from cat /proc/mounts cat /proc/mdstat
rootfs / rootfs rw 0 0 /proc /proc proc rw,relatime 0 0 /sys /sys sysfs rw,relatime 0 0 udev /dev devtmpfs rw,relatime,size=3049500k,nr_inodes=762375,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,relatime 0 0 /dev/mapper/vg_sys-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0 /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 /dev/md0 /boot ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0 /dev/mapper/vg_dat-lv_home /home ext4 rw,relatime,barrier=1,stripe=32,data=ordered 0 0 /dev/mapper/vg_dat-lv_opt /opt ext4 rw,relatime,barrier=1,stripe=32,data=ordered 0 0 /dev/mapper/vg_sys-lv_local /usr/local ext4 rw,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_sys-lv_var /var ext4 rw,relatime,commit=15,barrier=1,data=ordered 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 Personalities : [raid1] md1 : active raid1 sda1[0] sdb1[1] 47188924 blocks super 1.1 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk md0 : active raid1 sda2[0] sdb2[1] 204788 blocks super 1.0 [2/2] [UU] unused devices: <none>
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 WONTFIX if it remains open with a Fedora 'version' of '13'. 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 prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.