Created attachment 940538 [details]
File: anaconda-tb

Created attachment 940539 [details]
File: anaconda.log

Created attachment 940540 [details]
File: environ

Created attachment 940541 [details]
File: journalctl

Created attachment 940542 [details]
File: lsblk_output

Created attachment 940543 [details]
File: nmcli_dev_list

Created attachment 940544 [details]
File: os_info

Created attachment 940545 [details]
File: program.log

Created attachment 940546 [details]
File: storage.log

Created attachment 940547 [details]
File: ifcfg.log

Also, I have used fedora for a few years however this is my first bug report so please advice if there is any more information that I can provide to assist. In case the logs do not easily provide this:

This is on an Asus Rog G750-JH Laptop, This laptop has 2 PCI-E SSD's in a raid 0 with a sata hdd as a secondary drive. It seams to crash as it is "probing" installation media. 

After submitting this repot I have removed the secondary sata drive to test if that was the cause and the issue still persisted so I am guessing, without being a programer, that this may be related to the raid config.

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

From the anaconda-tb file:
> Local variables in innermost frame:
> name: None
> cls: <class 'blivet.devices.MDRaidArrayDevice'>

So we have an MDRaidArrayDevice with no name (given by udev probably). mulhern, any idea what could be going on here? Could it be another instance of the "UUID format" issue?

In my case, I have a standalone SSD (unused by this install) and an MD SATA raid.

There is definitely no issue on the F20 anaconda.

I can not say. There is no telltale poorly formatted UUID anywhere, unlike in bz#1147087. However, absence of evidence is not evidence of absence. dlehman might know more...there is a lot of name finding that occurs in handleUdevMDMemberFormat() that he worked w/ recently.

I'd say there is a good chance that this is caused by UUID formatting.

We suspect that this problem may be due to an inconsistency between the way mdadm formats UUIDs and the way the rest of the world does.

I've posted an updates.img at:
http://mulhern.fedorapeople.org/1145783.img. It contains a fix for the bug (we think),
and some extra logging code as well.

Can you run the install again with this image applied, let us know how it goes, and also upload logs for that run as well?

Please let me know if you have any questions.

Thanks!

- mulhern

It seems like I'm getting the same error. All I have to do is place the updates.img in the /tmp right? (Also tried with boot: linux0 updates=http://...) Which log files do I need to post?

Created attachment 943254 [details]
The contents of the anaconda error handler after applying the updates.img

Here is the output of the error handler when anaconda crashes.

Hi Jeremy,

The updates.img was not applied...I can tell by lack of additional error output in anaconda-tb. I always use inst.updates at boot.

Re: Comment #19.

Good Morning all,

I will run this when I get home from work today. 

Thank you,
Joe

Does this need to be applied to a specific iso? But I may be having different problems. Right now I can't seem to even get the text installer to run - it's always launching the default live desktop no matter what options I select - even through the boot menu.

I got a different result - sort of. I now appear to get two ABRT reports, seconds apart, and the backtrace of the second one lists:

base.py:159:_thread_input:EOFError: EOF when reading a line

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, 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/tui/simpleline/base.py", line 159, in _thread_input
    data = raw_input()
EOFError: EOF when reading a line

Local variables in innermost frame:
queue: <Queue.Queue instance at 0x7f3e936c91b8>
hidden: False
prompt: u"  Please make your choice from above ['q' to quit | 'c' to continue |\n  'r' to refresh]: "
self: <pyanaconda.ui.tui.simpleline.base.App object at 0x7f3e936b7b10>

I think the updates.img is being applied now. I'm getting the same result both using a URL to the above file as well as off a second USB. Unfortunately, I no longer even get to the anaconda error report, and the anaconda.log in /tmp looks equally unhelpful. It mentions the logging level is debug. It starts AnaInputThread1 which then immediately stops and the log ends. As for the ABRT reports, I get one that looks like the original error followed quickly by one with the above backtrace. Is there another file I should look for?

I should mention I'm using the recent Beta TC1 iso. I'm not sure if that would make a difference.

I should mention, the updates.img I see downloaded to the /tmp directory when using a URL in the inst.updates= is smaller than the one I download myself. I would guess it's not able to process the whole img for some reason, but I don't know why. I'm going to try again on the official alpha release just to see what happens.

I don't think we support running a text-mode install from live media. I can't think of a reason to do such a thing.

Note that for repeated runs it may be easier to just run liveinst from a terminal, like this:

liveinst --updates=http://path/to/updates.img

Created attachment 943543 [details]
Anaconda error log 21 alpha 1 - applying updates.img #1

After some trial and error, I got the img to apply and made some progress. Whereas before anaconda crashed before even selecting language, I can now make it slightly past that point before a new error is triggered.

Attaching the contents of the anaconda error report.

(In reply to Jeremy Rimpo from comment #29)
> Created attachment 943543 [details]
> Anaconda error log 21 alpha 1 - applying updates.img #1
> 
> After some trial and error, I got the img to apply and made some progress.
> Whereas before anaconda crashed before even selecting language, I can now
> make it slightly past that point before a new error is triggered.
> 
> Attaching the contents of the anaconda error report.
Interesting::
Traceback (most recent call first):
  File "/tmp/updates/blivet/devices.py", line 2347, in _addParent
    raise ValueError("member has wrong format")
...


Local variables in innermost frame:
member: existing 1863.03 GiB mdcontainer imsm0 (20)

This may or may not be related to the newer error, but it may help debug in the off chance. My RAID drive is an Intel Software Raid of two 1TB drives (as you most likely already noticed) which is further partitioned into one large data portion (I think 1.6 TB) as NTFS and the rest is used by Fedora as a mix of Ext4 as root and and LVM2 as home data. Using MBR partitioning.

Correction, there's a Ext4 boot partition, and the LVM is a mix of root, home, and swap partitions.

Proposing as a 21 Beta blocker, criterion "The installer must be able to detect and install to hardware or firmware RAID storage devices." - I've reproduced both bugs here with Intel firmware RAID. TC2 (with blivet 0.61.3) hits the first crash (has no attribute 'startswith'). If I apply an updates.img with the changes in blivet 0.61.4 it hits the "member has wrong format" crash. This is all from the Server DVD, no liveinst / text mode shenanigans.

Looks like Anne wanted to split the second crash out as #1150147. If so, this one should be marked as ON_QA because this specific crash (the 'startswith' one) is fixed in blivet 0.61.4 .

(In reply to Adam Williamson (Red Hat) from comment #34)
> Looks like Anne wanted to split the second crash out as #1150147. If so,
> this one should be marked as ON_QA because this specific crash (the
> 'startswith' one) is fixed in blivet 0.61.4 .

Agreed, I'm marking as modified, because AFAIK the originally reported bug is fixed.

Discussed at 2014-10-15 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-15/f21-blocker-review.2014-10-15-16.04.log.txt . Accepted as a blocker per criterion cited in c#33.

0.61.4 is now pending stable and this is verified fixed in it, so let's just close it out and keep the blocker list clean. We have #1150147 to work the second crash (should be fixed in 0.61.5 / TC4).

I recreated this bug with CentOS 7.4 (Anaconda 21.48.22.121-1, Blivet 0.61.15.65) with a backtrace of:

  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in 
run
    threading.Thread.run(self, *args, **kwargs)

  File "/usr/lib64/python2.7/threading.py", line 765, in run
    self.__target(*self.__args, **self.__kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 190, in storageInitialize
    storage.reset()

  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 495, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2239, in populate
    self._populate()

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2306, in _populate
    self.addUdevDevice(dev)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1277, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1988, in handleUdevDeviceFormat
    self.handleUdevMDMemberFormat(info, device)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1729, in handleUdevMDMemberFormat
    exists=True)

  File "/usr/lib/python2.7/site-packages/blivet/devices/md.py", line 106, in __init__
    sysfsPath=sysfsPath)

  File "/usr/lib/python2.7/site-packages/blivet/devices/container.py", line 61, in __init__
    super(ContainerDevice, self).__init__(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/devices/storage.py", line 146, in __init__
    Device.__init__(self, name, parents=parents)

  File "/usr/lib/python2.7/site-packages/blivet/devices/device.py", line 83, in __init__
    if not self.isNameValid(name):

  File "/usr/lib/python2.7/site-packages/blivet/devices/storage.py", line 854, in isNameValid
    if name.startswith("cciss/"):

AttributeError: 'NoneType' object has no attribute 'startswith'

In StorageDevice.__init__ right before Device.__init__ is called I added 
print("name: " + str(name))
print("uuid: " + str(uuid))

The result I got right before the AttributeError was raised as:
name: None
uuid: 462b445e-a58a-2956-10fd-3b49b91e9582

I then located that UUID using 'mdadm -E /dev/sdb' which shows:
/dev/sdb:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.1.00
    Orig Family : ec19e999
         Family : ec19e999
     Generation : 001f8f5a
     Attributes : All supported
           UUID : 462b445e:a58a2956:10fd3b49:b91e9582
       Checksum : 59648136 correct
    MPB Sectors : 1
          Disks : 2
   RAID Devices : 1

  Disk01 Serial : 6VMQHQ9X
          State : active
             Id : 00000001
    Usable Size : 976767240 (465.76 GiB 500.10 GB)

[Primary Mirror]:
           UUID : df2b8b10:cf3885e4:0474f472:0e6a4a22
     RAID Level : 1
        Members : 2
          Slots : [UU]
    Failed disk : none
      This Slot : 1
    Sector Size : 512
     Array Size : 976766976 (465.76 GiB 500.10 GB)
   Per Dev Size : 976767240 (465.76 GiB 500.10 GB)
  Sector Offset : 0
    Num Stripes : 3815496
     Chunk Size : 64 KiB
       Reserved : 0
  Migrate State : idle
      Map State : normal
    Dirty State : clean
     RWH Policy : off

  Disk00 Serial : 6VM6XGBA
          State : active
             Id : 00000000
    Usable Size : 976767240 (465.76 GiB 500.10 GB)

As a work around for this bug, I ended up running:
mdadm --zero-superblock /dev/sdb

As a side note, when I recreated the bug, the Anaconda kickstart included the following:

zerombr
clearpart --all --initlabel --drives=sda,sdb

You may want to consider extending the Anaconda clearpart support to attempt doing a mdadm --zero-superblock against the specified drives to reduce the chance of this issue in the future.

Hello,

This issue is fixed for a long time. If you are experiencing it now please file a new bug and attach your logs to the new bug.

Thank you,
Jirka

Going carefully through the history of the bug, it seems like there is a race condition with the superclass constructor initialization ordering which can pass through uninitialized values (such as passing a type of None for the name instead of a string).  The verified fix seems to be nothing more than get the user to re-run Anaconda enough times until the race condition isn't triggered.  There is also no additional exception handling around Device.__init__ to try to provide meaningful data back for when the problem happens again and confirm if the bug was really related to uuid formatting.

If the same exact event of Device.__init__() getting a name of None and passing it to isNameValid() just to generate an uncaught exception when attempting to treat None as a string is considered to be "fixed," then I will just consider this crash to be the intended result.  There is no point in opening a new bug for something already considered fixed.  I already did my part in notifying Red Hat that the issue still exists.

I'm sorry, I didn't take into account that RHEL 7 is based off Fedora 19.  You are right this is an old bug which has been fixed.  The issue can't be recreated in Fedora 26.

I will only open a new bug if I can generate an issue with RHEL 8beta (whenever that becomes available).

For anyone running across this ticket because of issues with RHEL 7 when use of Intel Raid isn't intended, I recommend again the workaround of issues the following against each drive:

mdadm --zero-superblock /dev/sda

Thanks