Created attachment 670582 [details]
File: anaconda-tb

Created attachment 670583 [details]
File: anaconda.log

Created attachment 670584 [details]
File: environ

Created attachment 670585 [details]
File: ifcfg.log

Created attachment 670586 [details]
File: messages

Created attachment 670587 [details]
File: program.log

Created attachment 670588 [details]
File: storage.log

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.

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.

Hm, I think this might be live-specific.  I've not been able to reproduce on a regular install.

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

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.

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

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.

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 ...

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

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]#

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

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

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 ...

... 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 :-((

... 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)

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!

Customizing HDD partions, during installtion process

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

Crashed when trying to partition disk.

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

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

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.

Created attachment 688162 [details]
anaconda_18.37.11_traceback.txt

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

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.

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

(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?

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!

Any testing of fedora 19 alpha or beta (beta not yet released) with these setups would be greatly appreciated.

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.

Issue can be reproduced with Fedora 19 Alpha installation as well.

> "No disks detected."

Nothing available under "Specialized & Network Disks" either.

Updated bug summary to reflect root cause.

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

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

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.

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

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

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

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

Created attachment 763533 [details]
/tmp/anaconda.log

Created attachment 763534 [details]
/tmp/anaconda-tb-0lJNKU

Created attachment 763535 [details]
/tmp/anaconda-tb-NMA6lm

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

*** Bug 977552 has been marked as a duplicate of this bug. ***

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

(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).

Confirming on Thinkpad T530

Created attachment 769556 [details]
No disks found - storage.log

As requested in comment 39

Created attachment 769557 [details]
No disks found - program.log

As requested in comment 39

(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.

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

(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.

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

Created attachment 769985 [details]
mdadm -E /dev/sda

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.

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)

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

Intel Matrix Storage Manager (IMSM) metadata format (used by mdadm) does not support Intel Smart Response Technology caching.

Intel Smart Response isn't supported by Fedora at this point. Not much we
can do here really.

Jes

(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.

*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.

DELL Inspiron 15SE 32 gb ssd cache same issue.

Tested Fedora 19 and 20 alphas.

(In reply to David Faulstich from comment #66)
Did this computer come out of the box configured this way (with ISRT enabled)?

@Chris, all Dell machines with an SSD cache come configured with ISRT enabled as the OEM windows installs use them.

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.

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.

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.

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