RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1489223 - [Huawei RHELSA 7.4 Bug] Installation: Miss some hard disks during text mode ISO installation process
Summary: [Huawei RHELSA 7.4 Bug] Installation: Miss some hard disks during text mode I...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-blivet
Version: 7.4-Alt
Hardware: aarch64
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Vojtech Trefny
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1482349
TreeView+ depends on / blocked
 
Reported: 2017-09-07 02:28 UTC by Zhou Wang
Modified: 2021-09-03 14:14 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-19 03:18:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
anaconda text mode installation "Installation Destination" page (143.81 KB, image/png)
2017-09-07 02:45 UTC, Zhou Wang
no flags Details
anaconda shell lsblk log (162.77 KB, image/png)
2017-09-07 02:46 UTC, Zhou Wang
no flags Details
anaconda_log_in_tmp.tar.xz (7.40 MB, application/x-xz)
2017-09-07 11:41 UTC, Zhou Wang
no flags Details

Description Zhou Wang 2017-09-07 02:28:34 UTC
Description of problem:


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Zhou Wang 2017-09-07 02:42:00 UTC
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

Comment 3 Zhou Wang 2017-09-07 02:45:01 UTC
Created attachment 1322860 [details]
anaconda text mode installation "Installation Destination" page

Comment 4 Zhou Wang 2017-09-07 02:46:54 UTC
Created attachment 1322861 [details]
anaconda shell lsblk log

Comment 5 Martin Kolman 2017-09-07 08:33:22 UTC
Please attach also the installation logs that are located in /tmp, most importantly storage.log and anaconda.log.

Thanks in advance!

Comment 6 Zhou Wang 2017-09-07 11:41:48 UTC
Created attachment 1323065 [details]
anaconda_log_in_tmp.tar.xz

Comment 7 Zhou Wang 2017-09-07 11:43:11 UTC
(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

Comment 8 Zhou Wang 2017-09-14 07:24:12 UTC
(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

Comment 9 Martin Kolman 2017-09-14 10:50:33 UTC
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.

Comment 10 Vratislav Podzimek 2017-09-19 11:23:13 UTC
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!

Comment 11 Vratislav Podzimek 2017-09-19 11:24:12 UTC
Vojta, could you please keep an eye on this BZ? Thanks!

Comment 13 Zhou Wang 2017-09-30 01:24:05 UTC
(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?

Comment 14 Zhou Wang 2017-09-30 01:24:16 UTC
(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?

Comment 15 John Feeney 2017-10-05 19:47:42 UTC
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?

Comment 16 Zhou Wang 2017-10-12 03:17:28 UTC
(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.

Comment 17 John Feeney 2017-10-12 15:17:57 UTC
Okay so can we close this?

Comment 18 Zhou Wang 2017-10-13 01:22:05 UTC
(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.

Comment 19 Vojtech Trefny 2017-11-21 12:07:15 UTC
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.

Comment 20 Zhou Wang 2017-11-22 07:26:06 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.