Created attachment 995593 [details]
File: anaconda-tb

Created attachment 995594 [details]
File: anaconda.log

Created attachment 995595 [details]
File: environ

Created attachment 995596 [details]
File: lsblk_output

Created attachment 995597 [details]
File: nmcli_dev_list

Created attachment 995598 [details]
File: os_info

Created attachment 995599 [details]
File: program.log

Created attachment 995600 [details]
File: storage.log

Created attachment 995601 [details]
File: syslog

Created attachment 995602 [details]
File: ifcfg.log

Created attachment 995603 [details]
File: packaging.log

The problem is here:

13:31:55,056 INFO program: Running... mdadm --examine --export /dev/mapper/mpathe1
13:31:55,067 INFO program: mdadm: No md superblock detected on /dev/mapper/mpathe1.
13:31:55,067 DEBUG program: Return code: 1

Please give specifics how you created the partition.

We should handle the mdexamine failure more elegantly, certainly.

But, if there is a good reason why mdexamine fails...then it is impossible to handle the format and ultimately to model the array device.

Hello Anne.

I did so many re-installs that it is hard to recall all the details. But I believe I just switched to the shell and created two primary partitions on the mentioned devices using fdisk. The tests were done on IBM Power7R2 with dual-port SAS drives (that's why they're reachable as multipath devices).
Unfortunately I don't remember whether there was a software RAID that I had to clean prior making the partitions. The thing is that anaconda is often unable to clean existing RAID stuff and doing manual tasks from console is the only way how to make a free space.

Please, let me know whether this info is sufficient.

Thanks,
Jaromir.

The call to mdraid.mdexamine has moved to handleUdevMDMemberFormat().

If mdexamine fails then we have no information about the array device of which this device is a member. Also, we probably should not count it as an array member even if udev says so, if it has no superblock. So, cleanup around this problem could be awfully tricky.

Reassigning...

In general, if you make a mess of your system by improperly removing old metadata, you will have problems. Based on comment 14 I think this is a problem of poor system administration or just one of the hazards of doing QA on the installer. There are too many real problems for my team to be spending time chasing self-inflicted ones like this.

Hello David.

What do you mean with "improperly removing old metadata"? Is mdadm --zero-superblock proper or improper? I always do it when removing raid partitions manually. I'm not doing QA, I just need to install Fedora often and this is what I experienced. If the installer allows people to rescan, it should be able to handle all situations or at least explain what's wrong with the drive instead of crashing. Especially when you need to use a hardware that was previously used by a different user and the harddrives can contain any kind of unspecified mess. I'm really not trying to test all corner scenarios. These are all common use-cases.

Regards,
Jaromir.

(In reply to Jaromír Cápík from comment #17)
> Hello David.
> 
> What do you mean with "improperly removing old metadata"? Is mdadm
> --zero-superblock proper or improper? I always do it when removing raid
> partitions manually. I'm not doing QA, I just need to install Fedora often

That followed by 'wipefs -a' would be much better and would have avoided this bug but I see, after realizing that you removed the superblock, that this is actually more of a straightforward bug than I thought. We should not be crashing if mdadm returns a non-zero exit code when examining an md member. We should simply move on.

> and this is what I experienced. If the installer allows people to rescan, it
> should be able to handle all situations

This is not possible.

> or at least explain what's wrong
> with the drive instead of crashing. Especially when you need to use a

It is not possible to identify what is wrong with the drive in many cases. The problem could lie on the disk itself, in udev, in blkid, or in the kernel, among other places.

> hardware that was previously used by a different user and the harddrives can
> contain any kind of unspecified mess. I'm really not trying to test all
> corner scenarios. These are all common use-cases.

It is common for people to try to clear disks that contain partitions, lvm, and even more by simply running 'dd if=/dev/zero of=<disk> bs=1M count=1', which leaves metadata all over the disk and causes myriad problems down the road. Common does not equal acceptable.

> 
> Regards,
> Jaromir.

(In reply to David Lehman from comment #18)
> (In reply to Jaromír Cápík from comment #17)
> > Hello David.
> > 
> > What do you mean with "improperly removing old metadata"? Is mdadm
> > --zero-superblock proper or improper? I always do it when removing raid
> > partitions manually. I'm not doing QA, I just need to install Fedora often
> 
> That followed by 'wipefs -a' would be much better and would have avoided
> this bug but I see, after realizing that you removed the superblock, that
> this is actually more of a straightforward bug than I thought. We should not
> be crashing if mdadm returns a non-zero exit code when examining an md
> member. We should simply move on.
> 
> > and this is what I experienced. If the installer allows people to rescan, it
> > should be able to handle all situations
> 
> This is not possible.

Right :]

 
> > or at least explain what's wrong
> > with the drive instead of crashing. Especially when you need to use a
> 
> It is not possible to identify what is wrong with the drive in many cases.
> The problem could lie on the disk itself, in udev, in blkid, or in the
> kernel, among other places.

The users probably do not care where the problem lies. I admit the complexity is high here, but there must be a way out of this. In the worst case when everything fails, the installer should at least say "Sorry, there's something rotten/unexpected that we're unable to handle" and offer users to decompose all the currently active devices, then clean the drives completely and start from scratch instead of crashing and forcing the user to reboot and repeat the whole procedure again. That is quite hostile and discouraging for all sorts of users, doesn't matter whether they're experienced or not.


> > hardware that was previously used by a different user and the harddrives can
> > contain any kind of unspecified mess. I'm really not trying to test all
> > corner scenarios. These are all common use-cases.
> 
> It is common for people to try to clear disks that contain partitions, lvm,
> and even more by simply running 'dd if=/dev/zero of=<disk> bs=1M count=1',
> which leaves metadata all over the disk and causes myriad problems down the
> road. Common does not equal acceptable.

Well, like stated above, users often take the hardware over from someone and with undefined content. They should not be punished for mistakes of the previous user. I still believe we need to be able to handle a mess on the drives more gracefully.

Jaromir.

I tend to think that if someone gives you a hard drive it is reasonable to expect you to sanitize its contents before trying to use it. That is not anaconda's job.

(In reply to David Lehman from comment #20)
> I tend to think that if someone gives you a hard drive it is reasonable to
> expect you to sanitize its contents before trying to use it.

Why just harddrive? People often get the whole computer and you then need some software for cleaning the content. Why can't we do that for the user when it means much lower overhead in thinks he/she needs to do? Disc cleaning is offered by almost all Linux distributions and I fully understand and support the reasons why it's there.


> That is not anaconda's job.

Why not? If it's only about cleaning the drive, then it's a simple task. Why would we tell users to search for another software for cleaning the drive when we can do that for the user at once. The opposite would make the whole process a bit cumbersome. the user would have to download a different ISO file with Parted Magic ??? And that isn't available for all architectures. You can argue, that the user can switch to the console and clean it by hand. But that isn't very comfortable and easy way for non-skilled users.

s|thinks|things

A few examples off the top of my head illustrating that the problem is not as simple as you suggest:

1. something's really wrong here. do you want me to clear this whole disk or just the partition(s) we think are problematic? (Problem here is that you cannot meaningfully clear the entire disk unless you can successfully recognize and assemble the full stack(s) of devices on it. How do you resolve this?)
2. The problem could be thing A or thing B. Which is it?
3. I see that this device might be formatted as a thing X or a thing Y. Which one should I pay attention to and which should I clear off? Or should I just leave them both for the next installer for have problems with as well?

These are all situations that arise, generally from poor administration. The funny thing is that people don't properly administer their systems because they feel sure that the OS installer will clean up their messes for them. The only other possible explanation is sheer laziness (or carelessness, for the defensive).

https://github.com/rhinstaller/blivet/pull/430

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2168.html