Bug 1489223

Description of problem:

Miss some hard disks during text mode ISO installation process

Version-Release number of selected component (if applicable):

Redhat7.4 Beta ISO

How reproducible:


Steps to Reproduce:
1. have 7 hard disks connected into Taishan 2280（here I just used 7 hard disks 
   to do test in Huawei Lab）
2. start ISO installation
3. can not find /dev/sdd in "Installation Destination page" in text mode 
   installation
4, alt + tab to enter the anaconda shell to check hard disks, we can find
   all 7 hard disks including /dev/sdd.

Actual results:

 can not find /dev/sdd in "Installation Destination page" in text mode 
 installation

Expected results:

 should see all hard disks in "Installation Destination page" in text mode

Additional info:

 please see the log in attached png file: anaconda_main_log.png,
                                          anaconda_lsblk_log.png

Created attachment 1322860 [details]
anaconda text mode installation "Installation Destination" page

Created attachment 1322861 [details]
anaconda shell lsblk log

Please attach also the installation logs that are located in /tmp, most importantly storage.log and anaconda.log.

Thanks in advance!

Created attachment 1323065 [details]
anaconda_log_in_tmp.tar.xz

(In reply to Martin Kolman from comment #5)
> Please attach also the installation logs that are located in /tmp, most
> importantly storage.log and anaconda.log.
> 
> Thanks in advance!

please see anaconda_log_in_tmp.tar.xz, which includes all the files in /tmp

(In reply to Martin Kolman from comment #5)
> Please attach also the installation logs that are located in /tmp, most
> importantly storage.log and anaconda.log.
> 
> Thanks in advance!

Hi Martin,

Any update about this problem?

Thanks
Zhou

Thanks for the logs!

Looking on storage.log the sdd device seems to be part of biso raid & seems to be the only such device present:

01:46:54,275 INFO blivet: scanning sdd (/sys/devices/platform/HISI0162:01/host1/port-1:0/expander-1:0/port-1:0:8/end_device-1:0:8/target1:0:3/1:0:3:0/block/sdd)...
01:46:54,277 DEBUG blivet:           DeviceTree.getDeviceByName: hidden: False ; name: sdd ; incomplete: False ;
01:46:54,279 DEBUG blivet:           DeviceTree.getDeviceByName returned None
01:46:54,280 INFO blivet: sdd is part of a biosraid
01:46:54,280 DEBUG blivet: getFormat('None') returning DeviceFormat instance with object id 101
01:46:54,282 DEBUG blivet:              DiskDevice._setFormat: sdd ; current: None ; type: None ;
01:46:54,284 DEBUG blivet:               DiskDevice.readCurrentSize: path: /dev/sdd ; sysfsPath: /sys/devices/platform/HISI0162:01/host1/port-1:0/expander-1:0/port-1:0:8/end_device-1:0:8/target1:0:3/1:0:3:0/block/sdd ; exists: True ;
01:46:54,287 DEBUG blivet: updated sdd size to 3726.02 GiB (3726.02 GiB)
01:46:54,324 INFO blivet: added disk sdd (id 100) to device tree
01:46:54,325 INFO blivet: got device: u'sdd'
01:46:54,327 DEBUG blivet:           DeviceTree.handleUdevDeviceFormat: name: sdd ;
01:46:54,340 INFO blivet: type detected on 'sdd' is 'ddf_raid_member'
01:46:54,343 DEBUG blivet:             DMRaidMember.__init__: device: /dev/sdd ; serial: PN1334PEJ8VHVS ; uuid: LSI__ ; exists: True ; label: None ;
01:46:54,343 DEBUG blivet: getFormat('ddf_raid_member') returning DMRaidMember instance with object id 103
01:46:54,345 DEBUG blivet:             DiskDevice._setFormat: sdd ; current: None ; type: dmraidmember ;
01:46:54,345 INFO blivet: got format: existing dmraidmember
01:46:54,347 DEBUG blivet:            DeviceTree.handleUdevDMRaidMemberFormat: type: dmraidmember ; name: sdd ;
01:46:54,755 WARN blivet: dmraid member sdd does not appear to belong to any array

So my guess is sdd being bios raid but not being part of any array could be the reason it does not show up in the UI.

In any case, reassigning to the blivet (the storage library used by Anaconda) for further triage.

Exactly, it looks like there is some old metadata on the device. Is there a chance to try to reproduce the issue after running 'wipefs -a' on all the disks? Thanks!

Vojta, could you please keep an eye on this BZ? Thanks!

(In reply to Vratislav Podzimek from comment #11)
> Vojta, could you please keep an eye on this BZ? Thanks!

Hi Vojta, any update about this bug?

(In reply to Vratislav Podzimek from comment #11)
> Vojta, could you please keep an eye on this BZ? Thanks!

Hi Vojta, any update about this bug?

Zhou Wang,

I believe you were asked to do something in Comment #10

 > Exactly, it looks like there is some old metadata on the device. Is there a
 > chance to try to reproduce the issue after running 'wipefs -a' on all the 
 > disks? Thanks!

Have you done that?

(In reply to John Feeney from comment #15)
> Zhou Wang,
> 
> I believe you were asked to do something in Comment #10
> 
>  > Exactly, it looks like there is some old metadata on the device. Is there
> a
>  > chance to try to reproduce the issue after running 'wipefs -a' on all the 
>  > disks? Thanks!
> 
> Have you done that?

Sorry for late. I run wipefs -a /dev/sdd (we miss /dev/sdd before). Then I tried to install ISO, /dev/sdd can be found now.

Okay so can we close this?

(In reply to John Feeney from comment #17)
> Okay so can we close this?

I don't know. If this is the expectation of blivet, we can close this bug.

However, once we meet a hard disk with old metadata, we should firstly manually
run "wipefs", then we can see the hard disk.

Yes, I guess we can close this now. If blivet sees a disk like that we have no way how to tell if it is just some "old" metadata or if it the disk is actually part of some unknown/unsupported firmware RAID (or something like that). So yes, this is an expected behavior.

(In reply to Vojtech Trefny from comment #19)
> Yes, I guess we can close this now. If blivet sees a disk like that we have
> no way how to tell if it is just some "old" metadata or if it the disk is
> actually part of some unknown/unsupported firmware RAID (or something like
> that). So yes, this is an expected behavior.

OK