| Summary: | Partitions not detected (leading to md array data loss) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andy Burns <fedora> |
| Component: | udev | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | harald, jonathan, kay |
| 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: | 2011-09-21 20:11:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Andy Burns
2011-09-17 11:05:07 UTC
Attempting to manually force partitions to be created does not seem to help [root@xen ~]# kpartx -av /dev/sdc add map sdc1 (253:14): 0 1465144002 linear /dev/sdc 63 [root@xen ~]# kpartx -av /dev/sdh add map sdh1 (253:15): 0 1465144002 linear /dev/sdh 63 [root@xen ~]# kpartx -av /dev/sdi add map sdi1 (253:16): 0 1465144002 linear /dev/sdi 63 [root@xen ~]# kpartx -av /dev/sdj add map sdj1 (253:17): 0 1465144002 linear /dev/sdj 63 [root@xen ~]# kpartx -av /dev/sdk add map sdk1 (253:18): 0 1465144002 linear /dev/sdk 63 [root@xen ~]# kpartx -av /dev/sdl add map sdl1 (253:19): 0 1465144002 linear /dev/sdl 63 [root@xen ~]# kpartx -av /dev/sdm add map sdm1 (253:20): 0 1465144002 linear /dev/sdm 63 [root@xen ~]# kpartx -av /dev/sdn add map sdn1 (253:21): 0 1465144002 linear /dev/sdn 63 # ls /dev/sd[a-n]1 /dev/sda1 /dev/sdb1 /dev/sdk1 /dev/sdm1 the sdc1/sdh1/sdj1/sdl1/sdn1 partitions are still missing If dracut detects raid signatures on the bare drive, it will remove the partitions. What is the output of: # udevadm info --query=all --name=/dev/sdc (In reply to comment #2) > If dracut detects raid signatures on the bare drive, it will remove the > partitions > > What is the output of: > > # udevadm info --query=all --name=/dev/sdc The machine is "reluctant" to power-on at the moment, it may take me a day or two to get it booted and paste results ... thanks ... OK, machine booting again (removed faulty DVB-S2 card) # udevadm info --query=all --name=/dev/sdc P: /devices/pci0000:00/0000:00:1c.0/0000:05:00.0/0000:07:01.0/host9/target9:0:0/9:0:0:0/block/sdc N: sdc S: disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1EQ317024 S: disk/by-id/scsi-SATA_SAMSUNG_HD753LJS13UJ1EQ317024 S: disk/by-path/pci-0000:07:01.0-scsi-0:0:0:0 S: disk/by-id/wwn-0x50000f000b130742 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:05:00.0/0000:07:01.0/host9/target9:0:0/9:0:0:0/block/sdc E: MAJOR=8 E: MINOR=32 E: DEVNAME=/dev/sdc E: DEVTYPE=disk E: SUBSYSTEM=block E: ID_ATA=1 E: ID_TYPE=disk E: ID_BUS=ata E: ID_MODEL=SAMSUNG_HD753LJ E: ID_MODEL_ENC=SAMSUNG\x20HD753LJ\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_REVISION=1AA01190 E: ID_SERIAL=SAMSUNG_HD753LJ_S13UJ1EQ317024 E: ID_SERIAL_SHORT=S13UJ1EQ317024 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=168 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=168 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_FEATURE_SET_AAM=1 E: ID_ATA_FEATURE_SET_AAM_ENABLED=0 E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=254 E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=0 E: ID_ATA_FEATURE_SET_PUIS=1 E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0 E: ID_ATA_FEATURE_SET_APM=1 E: ID_ATA_FEATURE_SET_APM_ENABLED=0 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_WWN=0x50000f000b130742 E: ID_WWN_WITH_EXTENSION=0x50000f000b130742 E: ID_SCSI_COMPAT=SATA_SAMSUNG_HD753LJS13UJ1EQ317024 E: ID_PATH=pci-0000:07:01.0-scsi-0:0:0:0 E: ID_PATH_TAG=pci-0000_07_01_0-scsi-0_0_0_0 E: ID_FS_VERSION=0.90.0 E: ID_FS_UUID=858169d2-7470-43a4-9a1b-2f671e7a0443 E: ID_FS_UUID_ENC=858169d2-7470-43a4-9a1b-2f671e7a0443 E: ID_FS_TYPE=linux_raid_member E: ID_FS_USAGE=raid E: UDISKS_PRESENTATION_NOPOLICY=0 E: MD_LEVEL=raid5 E: MD_DEVICES=6 E: MD_UUID=858169d2:747043a4:9a1b2f67:1e7a0443 E: MD_UPDATE_TIME=1212317991 E: MD_EVENTS=3 E: UDISKS_ATA_SMART_IS_AVAILABLE=1 E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1EQ317024 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD753LJS13UJ1EQ317024 /dev/disk/by-path/pci-0000:07:01.0-scsi-0:0:0:0 /dev/disk/by-id/wwn-0x50000f000b130742 E: TAGS=:systemd: (In reply to comment #4) > OK, machine booting again (removed faulty DVB-S2 card) > > # udevadm info --query=all --name=/dev/sdc > .... > E: ID_FS_TYPE=linux_raid_member > E: ID_FS_USAGE=raid Ok... you clearly have an ?old? raid signature on /dev/sdc. You should get rid of it. something like: # mdadm --zero-superblock /dev/sdc should do the job. You might want to check the other drives, too. OK, thinking about the history of these disks, many years ago I did create an array of 6 disks on them (I couldn't honestly remember at this point whether this would be on the raw disks, or on partitions) I then purchased 2 additional disks and a separate 8-channel PCIX SATA controller, attached all 8 disks to it, and recreated it as an 8 disk array (definitely using partitions). Are you saying it's feasible that sufficient evidence (the original metadata) remains from the former 6 raw disk array, that udev sees it first and takes it as gospel, ignoring the later 8 partition based array? If, so this starts to fit with advice I've received on the "see also" BZ#730835, to delete and recreate the missing partitions, recreate the array with metadata as v1.0 instead of v0.9, and use --assume-clean to prevent mdadm regenerating parity. Keeping fingers crossed that the contents are still there ... Thanks. OK, I did mdadm --zero-superblock on each of the 6 drives which previously had md-on-rawdisks, rebooted and mdadm correctly assembled the 8-member array using md-on-partitions, the LVM contents look happy. so the old superblock on the raw drive was "masking" the newer one in the partition. I think I will take the suggestion elewhere to upgrade to metadata1.0 though. Thanks very much :-) |