Bug 890881 - mdadm doesn't support Intel Smart Response RAID configuration
Summary: mdadm doesn't support Intel Smart Response RAID configuration
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:92d2f9b2f593669103b05262dcc...
: 977552 (view as bug list)
Depends On: 1040362
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-30 22:58 UTC by schaefi
Modified: 2017-06-06 15:47 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-16 20:17:46 UTC
Type: ---


Attachments (Terms of Use)
File: anaconda-tb (367.24 KB, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: anaconda.log (6.90 KB, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: environ (870 bytes, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: ifcfg.log (377 bytes, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: messages (189.57 KB, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: program.log (45.91 KB, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
File: storage.log (122.62 KB, text/plain)
2012-12-30 22:59 UTC, schaefi
no flags Details
anaconda_18.37.11_traceback.txt (1.59 MB, text/plain)
2013-01-26 20:20 UTC, Michal Ambroz
no flags Details
/tmp/anaconda.log (12.02 KB, text/x-log)
2013-06-20 17:14 UTC, Bradley
no flags Details
/tmp/anaconda-tb-0lJNKU (783.27 KB, text/plain)
2013-06-20 17:14 UTC, Bradley
no flags Details
/tmp/anaconda-tb-NMA6lm (560.27 KB, text/plain)
2013-06-20 17:15 UTC, Bradley
no flags Details
No disks found - storage.log (169.75 KB, text/x-log)
2013-07-06 11:28 UTC, Arun Babu Neelicattu
no flags Details
No disks found - program.log (16.53 KB, text/x-log)
2013-07-06 11:30 UTC, Arun Babu Neelicattu
no flags Details
storage.log after dmraid -ay (77.75 KB, text/x-log)
2013-07-06 14:16 UTC, Arun Babu Neelicattu
no flags Details
mdadm -E /dev/sda (965 bytes, text/plain)
2013-07-07 13:25 UTC, Bradley
no flags Details
mdadm -E /dev/sdb (1.35 KB, text/plain)
2013-07-07 13:30 UTC, Bradley
no flags Details

Description schaefi 2012-12-30 22:58:57 UTC
Description of problem:
started linux with Fedora 18 TC3 x86 64 Live Desktop.iso on newlz bought HP envy 6 with preinstalled Windows 8 and UEFI Secure Boot enabled.

Start installation to disk
Then set installation destination. No disk have been shown. 
Then set done. 
Then the system crashes
The following was filed automatically by anaconda:
anaconda 18.37.3 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 319, in execute
    self.bootDrive = disk_names[0]
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1480, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 398, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run
    threading.Thread.run(self, *args, **kwargs)
IndexError: list index out of range

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:UUID=8633-72AD ro rd.live.image quiet rhgb
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.6.10-4.fc18.x86_64
other involved packages: python-libs-2.7.3-13.fc18.x86_64
package:        anaconda-18.37.3-1.fc18.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 18 (Spherical Cow)
type:           libreport
version:        18

Comment 1 schaefi 2012-12-30 22:59:02 UTC
Created attachment 670582 [details]
File: anaconda-tb

Comment 2 schaefi 2012-12-30 22:59:04 UTC
Created attachment 670583 [details]
File: anaconda.log

Comment 3 schaefi 2012-12-30 22:59:06 UTC
Created attachment 670584 [details]
File: environ

Comment 4 schaefi 2012-12-30 22:59:08 UTC
Created attachment 670585 [details]
File: ifcfg.log

Comment 5 schaefi 2012-12-30 22:59:10 UTC
Created attachment 670586 [details]
File: messages

Comment 6 schaefi 2012-12-30 22:59:12 UTC
Created attachment 670587 [details]
File: program.log

Comment 7 schaefi 2012-12-30 22:59:15 UTC
Created attachment 670588 [details]
File: storage.log

Comment 8 Chris Lumens 2013-01-02 15:34:09 UTC
When you get to the screen where you choose which disks you want to be part of the installation, there are no disks available for you to select?  Or, did you not select any?  If you can be a little more specific, we can probably pretty easily fix this.

Comment 9 schaefi 2013-01-03 18:07:29 UTC
Hi Chris,

there are no disks to select. Actually I can not select anything.

I hope this is precise enough. Otherwise please let me know what info you need.

Comment 10 Chris Lumens 2013-01-04 19:26:31 UTC
Hm, I think this might be live-specific.  I've not been able to reproduce on a regular install.

Comment 11 schaefi 2013-01-10 23:04:51 UTC
Hi,

I have enterered Anaconda to generate a dual boot system with Fedora 18 and Windows 8. The system is an off/the /shelf HP envy 6 and comes preinstalled with Windows 8 in UEFI mode.

I booted from USB and entered Anaconda to install to harddisk.
I set the language, the time and the keypad.

Then I tried the next step: select disk.
The screen does not give me anz opportunitz to select anything. I can not see the actual disks.
Clicking on: Done then generates the error


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 12 schaefi 2013-01-10 23:35:06 UTC
Hi Chris,

as you see above I run with the newest version of Fedora (Fedora 18-RC4) in exactly the same problem. This is absolutely reproducible and will most probably happen to all users with new HP hardware with Windows 8 preinstalled.

The system screen to configure the disks says in the bottom line in yellow, that it does not recognize any disks and that a disk should be connected. 

Any ideas on the solution??

I am waiting desperately ...
(and I am quite astonished that this most likely will be the final release. I think this is a clear blocker because it prevents a lot of people to use Fedora).

If you need more info, then please let me know.

Comment 13 Brian Lane 2013-01-11 01:35:46 UTC
Looks like this is a bios raid:
17:38:04,208 WARN storage: failed to add member /dev/sda to md array /dev/md/imsm1: mdadd failed for /dev/sda: running mdadm --incremental --quiet /dev/sda failed

Comment 14 David Lehman 2013-01-11 23:16:24 UTC
To be clear, you are the only one to report this particular problem so far.

I can see that you have some firmware RAID configured, but the configuration is quite odd. What is the value in having firmware RAID arrays which have only a single member disk, aside from added complexity?

Regardless of the answer to the previous question, the fact is that the normal fedora boot process was unable to activate your firmware RAID, which accounts for all of your disks.

Comment 15 schaefi 2013-01-12 09:20:05 UTC
Hi Brian, Hi David,

thanks for your comments so far.

I also suspect that there is a kind of firmware RAID configured that prevents the installation. But beware: The Laptop is an out-of-the-box laptop; so this is the factory configuration for the HP-Laptops and not a special configuration of me.

I further suspect that our colleagues from Micosoft "invent" such a configuration to actualy raise the hurdle to install Linux.

Do you have any idea how to undo or uncofigure the firmware RAID without loosing Windows 8?

I am very willing to follow your recommendations or ideas ...

Comment 16 schaefi 2013-01-14 10:50:00 UTC
Hi David,

...
"To be clear, you are the only one to report this particular problem so far."
...

I am not 100% sure, but it seems that the issue has popped up with ubuntu too:
http://askubuntu.com/questions/159645/dual-boot-installation-of-ubuntu-12-04-lts-on-hp-ultrabook-envy-4-1002tx

With this additional info, perhaps you have an idea how to solve this.
A solution or some ideas are still very appreciated

Comment 17 schaefi 2013-01-14 19:52:22 UTC
Here some more info running the Fedora-18-X86_64Live-KDE.iso and investigating the disks on the console with fdisk:


[liveuser@localhost ~]$ su
[root@localhost liveuser]# fdisk -l /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x72bb8bb4

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   976766975   488383487+  ee  GPT
Partition 1 does not start on physical sector boundary.
[root@localhost liveuser]# fdisk -l /dev/sdb

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Part.


Disk /dev/sdb: 32.0 GB, 32017047552 bytes, 62533296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xe980a96b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  4294967295  2147483647+  ee  GPT
Partition 1 does not start on physical sector boundary.
[root@localhost liveuser]#

Comment 18 schaefi 2013-01-14 20:13:24 UTC
Here the description of the hardware including what I did in the very beginning using Windows 8 on the factory-delivered laptop:

Hardware:
HP ENVY 6-1160ez
-          Chip: Intel® Core™ i5-3317U (1,7 GHz, 3 MB L3-Cache)
-          RAM: 8 GB DDR3
-          Disk: 500 GB SATA (5400 U/min) + 32 GB mSATA SSD
-          Display: HD BrightView LED-Display mit einer Diagonalen von 39,6 cm (15,6") und Hintergrundbeleuchtung (1366 x 768)
-          Graphic: Intel HD Graphics 4000 (bis zu 1,65 GB)
-          Details: http://www8.hp.com/h20195/v2/GetPDF.aspx/c03548945.pdf
-          the Laptop comes with pre-installed Windows 8 and UEFI

In Windows 8 I did shrunk the paritions to make space for Linux
The original design looks as follows:
Windows 8 -> Start Menue -> Computer Management -> Disk Management

Disk 0:
Recovery Partition:     400 MB
EFI System Partition:   260 MB
Windows8 (C:) NTFS:     447 GB
Windows8 Recovery D:     17 GB
Disk 1:
Primary Partition:        8 GB

Using Windows 8 Disk Management I re-paritioned to shrink the original C: and dree up space for Linux

Disk 0:
Recovery Partition:     400 MB
EFI System Partition:   260 MB
Windows8 (C:) NTFS:      97 GB
Partition (L:) exFAT:    50 GB  (exchange partition between Windows and Linux)
Free Space              300 GB  (space for new Linux partitions)
Windows8 Recovery D:     17 GB
Disk 1:
Primary Partition:        8 GB

Comment 19 schaefi 2013-01-14 21:05:41 UTC
Here some more info running the Fedora-18-X86_64Live-KDE.iso and investigating the disks on the console with dmraid:


[root@localhost liveuser]# dmraid -r
/dev/sdb: isw, "isw_djiabcceej", GROUP, ok, 62533293 sectors, data@ 0

Comment 20 schaefi 2013-01-14 21:20:46 UTC
I then did the following using dmraid:

[root@localhost liveuser]# dmraid -r -E
Do you really want to erase "isw" ondisk metadata on /dev/sdb ? [y/n] :y

and rebooted into Windows ...

Comment 21 schaefi 2013-01-14 21:51:46 UTC
... Windows worked ok and - much to my surprise - did not complain at all. The only difference I noted was that Disk 1 (/dev/sdb) showed in Windows a 24 GB unallocated space, that has not been shown before.

I then booted again with the USB-stick with Fedora-18-X86_64Live-KDE.iso
-> start the installation
-> select time
-> select keyboard
-> select disks:
And now for the first time I can see both disks :-))

Then I continued to try to install to one of the disks and directly ran into this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=895232

Quite discouraging :-((

Comment 22 schaefi 2013-01-14 23:01:59 UTC
... I gave it another try and booted with the USB-stick with Fedora-18-X86_64Live-KDE in UEFI enabled and Secure Boot enabled.

Press <ESC> to enter the UEFI
-> F9 Boot device options
-> Select the USB-stick
-> Boot Fedora 18
-> Click: Installation to harddisk
-> Set Time
-> Set Keyboard
-> Set installation destination:
   -> select the 476.94 GB disk ATA Hitachi HTS54505
   -> select continue
   -> select partition type "standard partitions" for an old-school-installation
   -> select auto partitioning and re-adjust some of the values:
/home      60GB /dev/sda9  ext4
/boot     500MB /dev/sda8  ext4
/boot/efi 200MB /dev/sda7  EFI
/          30GB /dev/sda11 ext4
swap     7.88GB /dev/sda10 swap

-> select: start installation

This finally works! Rebooting; press <ESC> to enter UEFI; F9 Boot Device Option
then let you choose Fedora 18 to boot.

Final remarks: 
- Making a dual boot (Fedora 18 - Windows 8) is a bit of a nightmare!
- Comment 20 has been the turning point to success
- Let see what the next days brings (its 24:00 and time to go to bed)

Comment 23 Brian Lane 2013-01-15 00:42:24 UTC
Note that fdisk doesn't work with GPT. To see all the partitions you should use parted -l

I'm glad to hear you got it working!

Comment 24 Ehab El-Gedawy 2013-01-16 16:43:27 UTC
Customizing HDD partions, during installtion process

Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 25 Michal Ambroz 2013-01-26 18:06:05 UTC
Crashed when trying to partition disk.

Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 26 Michal Ambroz 2013-01-26 19:24:44 UTC
Trying to choose existing partitions to be installed with Fedora 18.
This time I change type of the ntfs partitions to b7 instead of 7 in attempt to hide them from fedora installator.


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 27 Michal Ambroz 2013-01-26 19:51:27 UTC
In fedora 18 I am not able to pass the disk partitioning stage. 
It throws me to this or https://bugzilla.redhat.com/show_bug.cgi?id=862948 bugreports.

I have probably very unusual disk partitioning:
   Device	size	Id	System
/dev/sda1	050G	07	HPFS/NTFS/exFAT - encrypted with Truecrypt
/dev/sda2	004G   	83	/boot ext3
/dev/sda3	016G  	83	Ubuntu / - LUKS encrypted ext3
/dev/sda4        		05	Extended
/dev/sda5	016G	83	Fedora / - LUKS encrypted ext3
/dev/sda6	016G	83	/home - LUKS encrypted ext3
/dev/sda7	004G	83	swap - LUKS encrypted swapfs
/dev/sda8	050G	07	HPFS/NTFS/exFAT - encrypted with Truecrypt
/dev/sda9	320G	8e	LUKS encrypted LVM volume with some more logical drives

Probably some of that crypto stuff freaks anaconda to death.

Comment 28 Michal Ambroz 2013-01-26 20:20:23 UTC
Created attachment 688162 [details]
anaconda_18.37.11_traceback.txt

Comment 29 Michal Ambroz 2013-01-26 20:59:28 UTC
Trying to pass the disk partitioning. I have tried to empty at least some space in the partition table.
But no luck.


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 30 Ehab El-Gedawy 2013-01-27 15:34:26 UTC
Booting Fedora 18 live from the disk that will be used to install fedora causing that crash!

Fedora live boot on sda1 (using grub legacy with fedora 18 kernel options), and i need to install in sda8
when moving Fedora live to separate disk ( USB stick ), every thing is ok.

Comment 31 preesha.sen 2013-02-03 16:14:49 UTC
Im trying to install Fedora18 on U410 Lenovo Laptop with Windows7 pre-installed. 
Steps to reproduce
1) Make an USB stick using LiveUSBCreator using Fedora18 Liveimage
2) Disable UEFI in BIOS, the RAID is still enabled in BIOS.
3) Boot from USB stick.
4) When LiveSystemUser gets logged in select "Install to Hard drive" option to install
fedora on harddisk.
5) Select through options, then the anaconda installer ends up at "No disks detected" error.
Note that I can still access the filesystem on the harddisk using FileExplorer tool. And running
"disk" tool shows all devices and partitions.

NOTE: We also tried putting HDD is other modes like "AHCI" and "Compatible" and still the the installer gives the
same error "No disks detected".



Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 32 David Lehman 2013-02-05 18:59:46 UTC
(In reply to comment #27)
> In fedora 18 I am not able to pass the disk partitioning stage. 

Are you planning to use an existing bootloader or have Fedora install grub and use that for your primary bootloader?

Comment 33 Milovidov Mikhail 2013-04-03 07:17:18 UTC
Thank you all for this bug post!
I also have HP Envy 6 and also had a problem with dual boot because Anaconda didn't see my hard disks. But after read Comment 20 I solve this problem!

Comment 34 David Lehman 2013-05-16 15:05:35 UTC
Any testing of fedora 19 alpha or beta (beta not yet released) with these setups would be greatly appreciated.

Comment 35 Arun Babu Neelicattu 2013-05-28 05:12:25 UTC
I can reproduce this issue on a Dell XPS 15 - L521X using F18. The problem seems to related to the raid config and/or the m-sata usage.

Will try with F19 Alpha.

Comment 36 Arun Babu Neelicattu 2013-05-28 06:02:33 UTC
Issue can be reproduced with Fedora 19 Alpha installation as well.

> "No disks detected."

Nothing available under "Specialized & Network Disks" either.

Comment 37 Arun Babu Neelicattu 2013-06-01 09:50:38 UTC
Updated bug summary to reflect root cause.

Workaround as per comment 20:
1. Erase RAID metadata using:
> dmraid -r -E
2. Reboot into installer

Comment 38 Lukáš Czerner 2013-06-04 12:38:12 UTC
Description of problem:
1. Set up the disk layout
2. Attempt to update disk layout
3. "An unknown error has occoured"

Have not tried to reproduce yet.

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:UUID=439E-C9F6 rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 39 David Lehman 2013-06-04 14:56:13 UTC
Anyone who is seeing a traceback/crash with F19, please attach all files matching /tmp/anaconda-tb-* to this bug report.

Anyone who is not seeing their disks but also not seeing a traceback/crash, please attach /tmp/storage.log, /tmp/program.log, and /tmp/syslog to this bug report.

Thanks.

Comment 40 hink 2013-06-07 19:09:10 UTC
Description of problem:
a new installation of F19beta from the live cd .
hard disk with existing patitions of a F18 : \home ; \ ; SWAP .
when i clking on haed disk during choice . 

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=/ubninit root=UUID=751A-29C6 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=/ubnkern 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 41 Ward Wouts 2013-06-11 09:12:21 UTC
Description of problem:
While trying to install FC19b from a USB stick, after selecting the destination disc.

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:UUID=8048-A4D8 rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 42 GuiXin 2013-06-13 09:31:57 UTC
Description of problem:
the bug heppened when i choose hardisk

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:LABEL=LIVE ro rd.live.image quiet rhgb
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 43 Bradley 2013-06-20 16:56:14 UTC
Description of problem:
Selected keyboard English US, America/Chicago time, and then selected my harddrive.  Then it paused for a second and crashed.

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 44 Bradley 2013-06-20 17:14:07 UTC
Created attachment 763533 [details]
/tmp/anaconda.log

Comment 45 Bradley 2013-06-20 17:14:39 UTC
Created attachment 763534 [details]
/tmp/anaconda-tb-0lJNKU

Comment 46 Bradley 2013-06-20 17:15:08 UTC
Created attachment 763535 [details]
/tmp/anaconda-tb-NMA6lm

Comment 47 Clemens Eisserer 2013-06-20 18:19:07 UTC
Description of problem:
after finished partitioning, got this exception

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=/ubninit root=UUID=0680-B55F rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=/ubnkern 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 48 Brian Lane 2013-06-25 00:55:31 UTC
*** Bug 977552 has been marked as a duplicate of this bug. ***

Comment 49 AW Coleman 2013-06-28 00:44:29 UTC
Description of problem:
Going through Install To Hard Drive from XFCE X86_64 Live Media. Used defaults, but selected review partition configuration. Crash occurred after pressing OK/Write to disk to partition scheme.

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat rw rd.live.image rd.live.overlay=LABEL=LIVE quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
packaging.log:  
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 390, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1641, in doKickstartStorage
    ksdata.bootloader.execute(storage, ksdata, instClass)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 287, in execute
    self.bootDrive = disk_names[0]
IndexError: list index out of range

Comment 50 AW Coleman 2013-06-28 00:53:08 UTC
(In reply to AW Coleman from comment #49)
After submitting bug report, returned to Live Media desktop, selected Install To Harddrive again. This time I did not select to review the partition changes and install proceeded fine.

Dell Latitude E6410 with Win7 installed on first 2 partitions (100MB and 70GB).

Comment 51 Germano Massullo 2013-06-30 21:08:05 UTC
Confirming on Thinkpad T530

Comment 52 Arun Babu Neelicattu 2013-07-06 11:28:51 UTC
Created attachment 769556 [details]
No disks found - storage.log

As requested in comment 39

Comment 53 Arun Babu Neelicattu 2013-07-06 11:30:08 UTC
Created attachment 769557 [details]
No disks found - program.log

As requested in comment 39

Comment 54 Arun Babu Neelicattu 2013-07-06 13:40:31 UTC
(In reply to David Lehman from comment #39)

@David

Digging into this a bit further it seems that the issue is related to mdadm and dmraid.

Trying to activate with dmraid fails since the nodes are not in /dev/mapper
> [root@localhost liveuser]# dmraid -ay
> RAID set "isw_bbceahdffa_WX81A13V9630" was not activated
> ERROR: device "isw_bbceahdffa_WX81A13V9630" could not be found
> RAID set "isw_dijjjabg_Volume_0000" was not activated
> RAID set "isw_dijjjabg_Volume_0001" was not activated
> ERROR: device "isw_dijjjabg_Volume_0000" could not be found
> ERROR: device "isw_dijjjabg_Volume_0001" could not be found

Stopping the arrays.
> [root@localhost liveuser]# mdadm -Ss
> mdadm: stopped /dev/md126
> mdadm: stopped /dev/md127

Trying to activate dmraid now succeeds.
> [root@localhost liveuser]# dmraid -ay
> RAID set "isw_bbceahdffa_WX81A13V9630" was activated
> device "isw_bbceahdffa_WX81A13V9630" is now registered with dmeventd for monitoring
> RAID set "isw_dijjjabg_Volume_0000" was activated
> RAID set "isw_dijjjabg_Volume_0001" was activated
> device "isw_dijjjabg_Volume_0000" is now registered with dmeventd for monitoring
> device "isw_dijjjabg_Volume_0001" is now registered with dmeventd for monitoring
> 

The disks now become correctly available via gnome-disks. Is this a regression of bug 537329 ??

However, the installer still refuses to locate the disks. Hope this helps.

Comment 55 Arun Babu Neelicattu 2013-07-06 14:16:51 UTC
Created attachment 769627 [details]
storage.log after dmraid -ay

Attaching the storage log after

> mdadm -Ss
> dmraid -ay

The following bit might be of interest:
> 19:49:41,449 DEBUG blivet:     DeviceTree.addUdevDevice: info: {'DEVLINKS': '/dev/disk/by-id/dm-name-isw_dijjjabg_Volume_0000 /dev/disk/by-id/dm-uuid-DMRAID-isw_dijjjabg_Volume_0000',
> 19:49:41,450 INFO blivet: scanning isw_dijjjabg_Volume_0000 (/devices/virtual/block/dm-3)...
> 19:49:41,450 DEBUG blivet:      DeviceTree.getDeviceByName: name: isw_dijjjabg_Volume_0000 ;
> 19:49:41,450 DEBUG blivet:      DeviceTree.getDeviceByName returned None
> 19:49:41,450 INFO blivet: isw_dijjjabg_Volume_0000 is a device-mapper device
> 19:49:41,451 DEBUG blivet:      DeviceTree.addUdevDMDevice: name: isw_dijjjabg_Volume_0000 ;
> 19:49:41,451 DEBUG blivet:       DMDevice.getDMNode: live-rw ; status: True ;
> 19:49:41,452 DEBUG blivet:       DMDevice.getDMNode: live-osimg-min ; status: True ;
> 19:49:41,452 DEBUG blivet:       DeviceTree.getDeviceByName: name: sdb ;
> 19:49:41,452 DEBUG blivet:       DeviceTree.getDeviceByName returned existing 122104MB disk sdb (2) with existing mdmember
> 19:49:41,453 DEBUG blivet:       DeviceTree.getDeviceByName: name: isw_dijjjabg_Volume_0000 ;
> 19:49:41,454 DEBUG blivet:       DeviceTree.getDeviceByName returned None
> 19:49:41,454 DEBUG blivet: lvm filter: adding isw_dijjjabg_Volume_0000 to the reject list
> 19:49:41,454 WARN blivet: ignoring dm device isw_dijjjabg_Volume_0000
> 19:49:41,454 DEBUG blivet: no device or no media present
> 19:49:41,455 DEBUG blivet:     DeviceTree.addUdevDevice: info: {'DEVLINKS': '/dev/disk/by-id/dm-name-isw_dijjjabg_Volume_0001 /dev/disk/by-id/dm-uuid-DMRAID-isw_dijjjabg_Volume_0001',
> 19:49:41,455 INFO blivet: scanning isw_dijjjabg_Volume_0001 (/devices/virtual/block/dm-4)...
> 19:49:41,456 DEBUG blivet:      DeviceTree.getDeviceByName: name: isw_dijjjabg_Volume_0001 ;
> 19:49:41,456 DEBUG blivet:      DeviceTree.getDeviceByName returned None
> 19:49:41,456 INFO blivet: isw_dijjjabg_Volume_0001 is a device-mapper device
> 19:49:41,456 DEBUG blivet:      DeviceTree.addUdevDMDevice: name: isw_dijjjabg_Volume_0001 ;
> 19:49:41,457 DEBUG blivet:       DMDevice.getDMNode: live-rw ; status: True ;
> 19:49:41,457 DEBUG blivet:       DMDevice.getDMNode: live-osimg-min ; status: True ;
> 19:49:41,458 DEBUG blivet:       DeviceTree.getDeviceByName: name: sdb ;
> 19:49:41,458 DEBUG blivet:       DeviceTree.getDeviceByName returned existing 122104MB disk sdb (2) with existing mdmember
> 19:49:41,459 DEBUG blivet:       DeviceTree.getDeviceByName: name: isw_dijjjabg_Volume_0001 ;
> 19:49:41,459 DEBUG blivet:       DeviceTree.getDeviceByName returned None
> 19:49:41,459 DEBUG blivet: lvm filter: adding isw_dijjjabg_Volume_0001 to the reject list
> 19:49:41,459 WARN blivet: ignoring dm device isw_dijjjabg_Volume_0001
> 19:49:41,459 DEBUG blivet: no device or no media present

Comment 56 Arun Babu Neelicattu 2013-07-06 15:05:24 UTC
(In reply to Arun Babu Neelicattu from comment #54)
> The disks now become correctly available via gnome-disks. Is this a
> regression of bug 537329 ??
> 
> However, the installer still refuses to locate the disks. Hope this helps.

The fix for this was to add 'noiswmd' to the boot options (bug 542022 comment 6). Now the RAID disks show up in anaconda. However, once selected they do not fetch the partition information - it shows up as a 100% free space.

Comment 57 Bradley 2013-07-07 13:23:46 UTC
I'm having the same issue on a new Dell I just bought, where I can't install F19. The system comes with /dev/sda (the hard drive) and /dev/sdb (the 32GB msata SSD), and wni8 64-bit.

/dev/sdb under windows has an 8GB partition for hibernation/fast boot, and the rest is for the SSD acceleration. (I've disabled fast boot under windows)

I think the problem is that the 'raid' format used isn't understood by the kernel.

manually running "dmraid -ay" gives errors like:

"ERROR: device "isw_bbihbdjbaf_XXXX" could not be found"

(3 times, once for FFS, once for Dev_Cache, and once with "isw_ddfecjfffc_FT56A59YJ0V2L6". The last component matches the partition names that I see in win8.)

mdadm -E shows the details of the partitions, but also adds:

mdadm(IMSM): Unsupported attributes: 2000000
Then has "Attributes : not supported"

mdadm -R /dev/mdX shows -EINVAL coming back from the RUN_ARRAY ioctl

When I kill -9 anaconda so I can stop the array with mdadm, and try to readd it, I get:

"mdadm Unsupported attributes in IMSM metadata.Arrays activation is blocked". And the mdadm source code 'documents' that bit as "MPB_ATTRIB_NVM" - "The OROM Support RST Caching of Volumes"

There's a BIOS option to use AHCI instead of "Intel Smart Response"; I haven't tried that yet.

Based on that error, reassigning to mdadm. I'll attach the mdadm-E output

Comment 58 Bradley 2013-07-07 13:25:44 UTC
Created attachment 769985 [details]
mdadm -E /dev/sda

Comment 59 Bradley 2013-07-07 13:30:00 UTC
Created attachment 769986 [details]
mdadm -E /dev/sdb

BTW, this flag isn't listed in imsm_check_attributes as one that's checked to be non-supported. I wonder if just masking that flag would 'work'.

Note that I'm not trying to get linux to support the chipset SSD-based caching; I just want to create other partitions on the regular drive for use by fedora.

Comment 60 Bradley 2013-07-07 14:14:04 UTC
If I disable the acceleration (using the windows tools), then /dev/sda appears as a normal (non-IMSM). If I also delete the cached data (a separate option in the tool), then so does /dev/sdb.

That implies that this is actually a per-disk option (rather than per-partition like bcache)

Comment 61 Jes Sorensen 2013-07-08 07:05:37 UTC
A couple of comments:

1) Please do not mix and match mdadm and dmraid - either go with one or the other. For IMSM RAID, mdadm is normally what one wants to use.

2) This is only happening with systems that has a small SSD as performance cache? I am not sure how this is meant to work, but it looks like Intel might be tricking the RAID stack into using it. Currently that is definitely not supported.

Lukasz, can you comment on #2?

Jes

Comment 62 Lukasz Dorau 2013-07-08 14:52:23 UTC
Intel Matrix Storage Manager (IMSM) metadata format (used by mdadm) does not support Intel Smart Response Technology caching.

Comment 63 Jes Sorensen 2013-08-29 11:54:53 UTC
Intel Smart Response isn't supported by Fedora at this point. Not much we
can do here really.

Jes

Comment 64 Chris Murphy 2013-09-22 18:26:26 UTC
(In reply to Bradley from comment #58)
> Created attachment 769985 [details]
> mdadm -E /dev/sda

My two cents is this is a fairly gross bug on the part of HP to ship a single disk system with imsm metadata (now Intel Rapid Storage Technology), let alone the firmware set to raid being enabled. A bug should be filed with them.

It would be useful if the installer could identify this storage state, and report that it isn't supported.

Comment 65 Chris Murphy 2013-09-22 18:36:14 UTC
*sigh* OK actually after looking at the metadata for both disks, it looks like they are using imsm metadata to support ISRT to use the ssd as a cache. If that's correct it's not an HP bug. And all the more I'd kick it back to anaconda needing to identify these increasingly common systems, and usefully inform the user that it isn't supported, and maybe even what to do about it.

Comment 66 David Faulstich 2013-09-24 22:42:00 UTC
DELL Inspiron 15SE 32 gb ssd cache same issue.

Tested Fedora 19 and 20 alphas.

Comment 67 Chris Murphy 2013-09-24 22:54:39 UTC
(In reply to David Faulstich from comment #66)
Did this computer come out of the box configured this way (with ISRT enabled)?

Comment 68 Arun Babu Neelicattu 2013-09-25 02:29:13 UTC
@Chris, all Dell machines with an SSD cache come configured with ISRT enabled as the OEM windows installs use them.

Comment 69 Chris Murphy 2013-09-25 05:41:08 UTC
Since ISRT isn't supported by linux, and mdadm recognizes the imsm metadata as being something it can't deal with, I'm going to kick it back to anaconda to see if there's a way for the installer to produce an informational message that their storage layout isn't supported.

Comment 70 John Pham 2013-11-16 18:33:49 UTC
FYI, dmraid does in fact allow activation of the ISRT raid arrays, so partitions can at least be mounted for dual-boot, and I'm doing this w/o any apparent problems (yet) on Ubuntu after patching their dmraid udev scripts. Perhaps there could be a flag to force mdadm to activate these configurations anyway? 

What ISRT appears to do is create a one-drive "RAID0" on the SSD for the data partition, with the cache proper sitting outside that I believe, and modifies GPT. another on the accelerated drive, if a RAID configuration does not already exist there. The caching appears to happen outside of that

I'd imagine one has to be careful in a dual-boot scenario to avoid writing to Windows partitions on the accelerated drive from Linux to keep data on the caching SSD valid, since the caching happens on all partitions on the accelerated drive/RAID array. Any shared data might be able to safely go onto the SSD or other drives.

Comment 71 Fedora End Of Life 2015-05-29 08:50:17 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 72 David Lehman 2015-09-16 20:17:46 UTC
There would have to be something in the data blivet already looks at to indicate this configuration. If that's the case, feel free to reopen and identify it. If not, one of you will have to provide a patch:

 https://github.com/rhinstaller/blivet/blob/master/CONTRIBUTING


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