Created attachment 1306341 [details]
File: anaconda-tb

Created attachment 1306342 [details]
File: anaconda.log

Created attachment 1306343 [details]
File: environ

Created attachment 1306344 [details]
File: journalctl

Created attachment 1306345 [details]
File: lsblk_output

Created attachment 1306346 [details]
File: nmcli_dev_list

Created attachment 1306347 [details]
File: os_info

Created attachment 1306348 [details]
File: program.log

Created attachment 1306349 [details]
File: storage.log

Created attachment 1306350 [details]
File: ifcfg.log

Similar problem has been detected:

The error message appear immediately after loading Fedora installer from the live disk (either optical or usb) once the language selection screen is showed and it happens only when RAID (NVIDIA fakeRAID) volume is present in the PC.
The problem seems restricted to Anaconda as the RAID volume is recognized and I can normally write and read files in the RAID volume Windows partition from Fedora live OS.

Motherboard: nForce 790i Ultra with 2 WD HDD configured in RAID 0

addons:         com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-26-1-5 rd.live.image quiet
hashmarkername: anaconda
kernel:         4.11.8-300.fc26.x86_64
other involved packages: system-python-libs-3.6.1-8.fc26.x86_64
package:        anaconda-core-26.21.11-1.fc26.x86_64
packaging.log:  
product:        Fedora
reason:         pyanaconda.payload.PayloadInstallError: Unable to find osimg for /dev/mapper/live-base
release:        Fedora release 26 (Twenty Six)
version:        26

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

This looks like storage specific. 

Changing component to blivet. 
Could blivet developers please verify is they are able to work with this "NVIDIA fakeRAID"?

From the duped, 1476076:
> Jiri Konecny 2017-07-31 03:15:43 EDT
>
> Hello Axel,
>
> Could you please describe how did you created your Live USB flash drive. What > tools / commands you used and if it is a default Fedora Workstation iso? 
> Also ideally test this issue with another USB flash drive?
>
> Thank you

This  happened with 3 live images in 2 different USB drives. I got Fedora through the fedora media creation tool from https://getfedora.org/en/workstation/download/, on another attempt I got fedora through the direct download present in the page, and a third attempt with Fedora LXDE, although I don't have the link to it.

FWIW, this seems not to be something overly Fedora specific; I tried installing a few versions of Ubuntu, and Debian and they all failed when bringing up the partitioning dialog (I think ubuntu uses gparted for that).

I couldn't work around this issue, so I got another disk drive - and disconnected the first one - and was able to work. There was an old bug, reported in Fedora 22, which seems to be related - that person used the same workaround successfully.

I had this exact same problem with a Dell T20 with the standard HDD installed and a 120 GB SanDisk SSD installed. Crashes as soon as I click the installer with the error message "unable to find osimg for /dev/mapper/live-base" and something about the python 3.6 library.

Unplugging the second HDD made it possible to continue the installation without an error.

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

This doesn't look like specific issue for just NVIDIA raid.

This is error from logs in first comment here:

GLib.GError: g-bd-dm-error-quark: Failed to activate the RAID set 'nvidia_aehfcccf' (3)


However the duplicate bug 1484948 has this in logs:

GLib.GError: g-bd-dm-error-quark: Failed to activate the RAID set 'pdc_eaeajhadc' (3)


I'm not sure what "pdc" is however I guess it would have "nvidia_" prefix if this would be NVIDIA raid specific.

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

Hi, guys,

there are 2 soft raid adapters in my motherboard by Gigabyte, one is Sil3132 (I put it in as external card) and another one is GigaRaid (jMicron) built-in. As I  experienced the same problem as above I decided to setup Fedora 26 in another pc. I succeeded. After that I just took this hdd back into my first pc and booted from it with no problem to desktop.

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

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

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

These firmware/bios RAID arrays should generally work. We just have to straighten out how we handle them between blivet and libblockdev. Right now, blivet calls a libblockdev function to activate the array. The array is already active, which is probably why libblockdev throws an exception. We have to decide which behavior should be changed, after which the change itself will be fairly straightforward.

This may not be an ideal situation for most, but when running on a live usb I reformatted the hard drive. This solved the problem, and I've now successfully installed Fedora 27.

I'd mucked around with things, and ended up braking an old Ubuntu install so that it would only load the grub menu.
Then I had issues trying to reinstall ubuntu, with my mouse and keyboard no longer being recognized, so I figured I'd try Fedora.
Having already borked much of the contents of the drive, I didn't mind wiping it to fix the issue and install Fedora.

Similar problem has been detected:

Tried to run "Install to Hard Drive" off the Live image, got crash just after start.

addons:         com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-27-1-6 rd.live.image rd.live.check quiet
hashmarkername: anaconda
kernel:         4.13.9-300.fc27.x86_64
other involved packages: python3-libs-3.6.2-13.fc27.x86_64
package:        anaconda-core-27.20.4-4.fc27.x86_64
packaging.log:  
product:        Fedora
reason:         pyanaconda.payload.PayloadInstallError: Unable to find osimg for /dev/mapper/live-base
release:        Fedora release 27 (Twenty Seven)
version:        27

Created attachment 1392051 [details]
dmraid fix update image

Included update image should fix the problem. Can you please try it?

It doesn't require to reinstall the system. Getting past language selection screen will suffice.

(In reply to Jan from comment #27)
> Created attachment 1392051 [details]
> dmraid fix update image
> 
> Included update image should fix the problem. Can you please try it?
> 
> It doesn't require to reinstall the system. Getting past language selection
> screen will suffice.

Can I apply this update at runtime? How should I apply it?

First you need to get the image (dmraid_fix.img) to some medium accessible from the installation configuration menu. USB key, spare drive or http server.

For http:
Just copy the image on some location so it is possible to download it from the browser.

For USB/disk:
Format disk to contain empty ext2 partition and copy the image directly into it.
Remember device/partition name (e.g. /dev/sdb1)

Next you have to go into installation boot menu and add the parameter there.
Generally you should press 'Tab' or 'e' at the first menu you can see to be able to edit line looking similar to this:

"vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora..."

To this line append (without the quotes):
"updates=http://server_name_or_ip/path/to/image/dmraid_fix.img" (if you used http)
"updates=hd:sdb1:/dmraid_fix.img" (if you used disk or USB)

...and hit Enter.
This should start the installation using this image.

Generally - if you can get to graphical part, image is there. If it hangs before graphics, something is wrong and it should be visible in output.

Let me know how it went. :)

Right now had the same problem on thinkpad x220.
After dd if=/dev/zero of=/dev/sda bs=1M count=1 problem is gone.
There are was gentoo installation on the hdd before 'dd':
/dev/sda1 boot
/dev/sda2 swap
/dev/sda3 /
/dev/sda4 /home

(In reply to Jan from comment #29)
> First you need to get the image (dmraid_fix.img) to some medium accessible
> from the installation configuration menu. USB key, spare drive or http
> server.
> 
> For http:
> Just copy the image on some location so it is possible to download it from
> the browser.
> 
> For USB/disk:
> Format disk to contain empty ext2 partition and copy the image directly into
> it.
> Remember device/partition name (e.g. /dev/sdb1)
> 
> Next you have to go into installation boot menu and add the parameter there.
> Generally you should press 'Tab' or 'e' at the first menu you can see to be
> able to edit line looking similar to this:
> 
> "vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora..."
> 
> To this line append (without the quotes):
> "updates=http://server_name_or_ip/path/to/image/dmraid_fix.img" (if you used
> http)
> "updates=hd:sdb1:/dmraid_fix.img" (if you used disk or USB)
> 
> ...and hit Enter.
> This should start the installation using this image.
> 
> Generally - if you can get to graphical part, image is there. If it hangs
> before graphics, something is wrong and it should be visible in output.
> 
> Let me know how it went. :)

Sorry for the delay, graphical interface load fine but is there another way to check if the update had been correctly applied?
I've formatted a USB drive with a Linux (0x83) partition, Ext2 (version 1.0) filesystem and "liveuser" as owner, the device was /dev/sdb1 so I've attached "updates=hd:sdb1:/dmraid_fix.img" to kernel parameters but the problem persist, still can't pass language selection, it just crush once it appears.

(In reply to Stefano Dosso from comment #31)
The updates image is basically archive with directory structure that is then copied over the installation provided one. Unpacked files are also placed in /tmp/updates where you can verify their presence.

To do it: Press Ctrl-Alt-F2 after you get to the graphical part of the installation (the crash message doesn't matter). You should see the prompt. Check if the directory /tmp/updates/blivet exists. If it does the updates image is loaded. (Ctrl-Alt-F6 to get back to graphical)

Appreciate your help.

I'm getting the same error but a totally different root cause I think.
for some reason my /dev/sda2 (msr partition) is being identified as an ext4 partition but it's not.  I've used diskpart in windows to deltee and recreate the partition but blkid and disks and parted all insist that it's an ext4 partition.

The installer appears to be scanning it and erroring out beacuse it can't access the partition. I haven't captured the log file but will do so when I get a chance.  Is that a totally different bugzilla report or does it fit with this one?

Similar problem has been detected:

tried to install on a fresh dell laptop with AMD A6 APU

addons:         com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-27-1-6 rd.live.image quiet
hashmarkername: anaconda
kernel:         4.13.9-300.fc27.x86_64
other involved packages: python3-libs-3.6.2-13.fc27.x86_64
package:        anaconda-core-27.20.4-4.fc27.x86_64
packaging.log:  
product:        Fedora
reason:         pyanaconda.payload.PayloadInstallError: Unable to find osimg for /dev/mapper/live-base
release:        Fedora release 27 (Twenty Seven)
version:        27

The last update is mine. Dell seems to be coming with a default lvm partition that's particularly nasty.

I used parted to delete all partitions and then reboot (have to reboot).
And then anaconda was able to pick up the empty disks

Similar problem has been detected:

Searched for a language in the search bar.

addons:         com_redhat_kdump
blivet-gui-utils.log: 
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-27-1-6 rd.live.image quiet
hashmarkername: anaconda
kernel:         4.13.9-300.fc27.x86_64
other involved packages: python3-libs-3.6.2-13.fc27.x86_64
package:        anaconda-core-27.20.4-4.fc27.x86_64
packaging.log:  
product:        Fedora
reason:         pyanaconda.payload.PayloadInstallError: Unable to find osimg for /dev/mapper/live-base
release:        Fedora release 27 (Twenty Seven)
version:        27

Similar problem has been detected:

Once clicking on "Install to Hard Drive" the welcome/language selection screen comes on in anaconda, but the popup "An unkown error has occurred" twice, one is unclickable but the other allows this bug report to happen

addons:         com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-27-1-6 rd.live.image rd.live.check quiet
hashmarkername: anaconda
kernel:         4.13.9-300.fc27.x86_64
other involved packages: python3-libs-3.6.2-13.fc27.x86_64
package:        anaconda-core-27.20.4-4.fc27.x86_64
packaging.log:  
product:        Fedora
reason:         pyanaconda.payload.PayloadInstallError: Unable to find osimg for /dev/mapper/live-base
release:        Fedora release 27 (Twenty Seven)
version:        27

ps, my previous comment: not running nvidia anything, I suspect the reason is that the disk is encrypted (I plan on wiping it)

(In reply to Jan from comment #32)
> (In reply to Stefano Dosso from comment #31)
> The updates image is basically archive with directory structure that is then
> copied over the installation provided one. Unpacked files are also placed in
> /tmp/updates where you can verify their presence.
> 
> To do it: Press Ctrl-Alt-F2 after you get to the graphical part of the
> installation (the crash message doesn't matter). You should see the prompt.
> Check if the directory /tmp/updates/blivet exists. If it does the updates
> image is loaded. (Ctrl-Alt-F6 to get back to graphical)
> 
> Appreciate your help.

I've tried several times to load the update image from USB drive but it didn't work as there wasn't any trace of the update on the /tmp folder.
Then I tried to download the image from a http server and it finally applied the update as the directory /tmp/updates/blivet containing unpacked files had been created but the problem still persist, can't get past the language selection menu.

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

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

(In reply to Jan from comment #27)
> Created attachment 1392051 [details]
> dmraid fix update image
> 
> Included update image should fix the problem. Can you please try it?
> 
> It doesn't require to reinstall the system. Getting past language selection
> screen will suffice.

I got a very similar problem to the one described here. In my case it is with an embedded promise hostraid controller.

Testing your image makes the installer not immediately abort anymore. So that is good.
Unfortunately, it also leads to the raid disks not being shown in the installer anymore.

I'll attach the storage log for you to have a look. Interestingly, the same problem also happens with Fedora 28.

Created attachment 1449820 [details]
storage.log after applying dmraid_fix.img

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

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

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.