Bug 547560 - error message "disk sda not found" misleading if disk contains BIOS RAID data
Summary: error message "disk sda not found" misleading if disk contains BIOS RAID data
Keywords:
Status: CLOSED DUPLICATE of bug 506861
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-14 23:01 UTC by Christian Krause
Modified: 2009-12-16 10:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-16 10:30:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
used kickstart config file (1.26 KB, text/plain)
2009-12-14 23:01 UTC, Christian Krause
no flags Details
kickstart log file (78.33 KB, text/plain)
2009-12-14 23:14 UTC, Christian Krause
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 499733 0 low CLOSED Anaconda ignores disks with incomplete BIOS RAID metadata -- linux nodmraid is ineffective 2021-02-22 00:41:40 UTC

Description Christian Krause 2009-12-14 23:01:54 UTC
Created attachment 378382 [details]
used kickstart config file

Description of problem:
When doing a kickstart installation with the attached kickstart file, anaconda throws an exception about a missing disk sda and aborts the installation.

Version-Release number of selected component (if applicable):
I'm not sure how to determine the exact version of anaconda, I'm using the PXE netboot images currently available in fedora/12/i386/os/images/pxeboot.

How reproducible:
100%

Steps to Reproduce:
1. start an NFS-based kickstart installation via PXE boot
  
Actual results:
- anaconda will throw an exception about missing the disk sda
- when switching to a different console with a bash prompt, /dev/sda is actually available (e.g. when using "fdisk -l /dev/sda)

Additional info:
anaconda offered to save the debug log which is also attached to the bug report

Comment 1 Christian Krause 2009-12-14 23:14:32 UTC
Created attachment 378384 [details]
kickstart log file

Comment 2 Christian Krause 2009-12-15 10:51:13 UTC
I've investigated the issue a little bit more and it seems to be similar to the following issue which was know for F11:
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_cannot_reuse_existing_RAID_arrays

After erasing the whole disk the installation worked just fine.

The original bug report #499733 was already set to CLOSED RAWHIDE, but it looks like that the problem is back.

Comment 3 Hans de Goede 2009-12-15 15:07:36 UTC
(In reply to comment #2)
> I've investigated the issue a little bit more and it seems to be similar to the
> following issue which was know for F11:
> https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_cannot_reuse_existing_RAID_arrays
> 
> After erasing the whole disk the installation worked just fine.
> 
> The original bug report #499733 was already set to CLOSED RAWHIDE, but it looks
> like that the problem is back.  

The problem was never fixed, as the problem is not inside anaconda, but with the system you are using.

When we see a disk with BIOS RAID metadata on it, we do not allow you to use the raw disk, as if the disk is part of a BIOS RAID set which for some reason we not properly detetect, using the raw disk would be BAD. This means that for disks with old / stale / invalid metadata on them they will get ignored. This is not
an anaconda bug. We need to trust the metadata on disks to see what their purpose is, and when we need to guess, we choice the safest option.

Comment 4 Christian Krause 2009-12-15 23:43:42 UTC
I fully agree that anaconda should not touch the disks with BIOS RAID metadata.

However, from a user's perspective, the error message from Anaconda is really not helpful: "can not find disk sda" (or something similar, I don't remember 100%).

Even an admin will not know, what to do in this case. An advanced admin may check on the 2nd console what's going on and just realize, that e.g. the disk reported as missing is just there.

Only by either reading the complete debug log of anaconda or by finding the F11! release notes you'll get a clue. ;-)

Would it be an option to enhance anaconda like this that it will at least tell the user, that a disk was omitted from being used for installation and if possible the reason for this? I think this would greatly enhance the user's experience and that it was even of the list of known issues for F11 it looks like that there were a couple of people who stumbled over this.

So I'm still sure that there is a usability problem here. I've changed the subject to reflect this and set the bug back to assigned.

It would be great if this usability change could be considered. If you think otherwise, I'm also OK with closing this bug.

Comment 5 Hans de Goede 2009-12-16 10:30:17 UTC
(In reply to comment #4)
> Even an admin will not know, what to do in this case. An advanced admin may
> check on the 2nd console what's going on and just realize, that e.g. the disk
> reported as missing is just there.
> 

I fully agree, and there for have a bug open for tracking printing a warning
(in the kickstart case) or popping up a warning dialog when this happens. This is not very hard to implement, but I've several other higher priorities to deal with.

I'm marking this bug as a duplicate of the bug for tracking tha adding of the warning.

*** This bug has been marked as a duplicate of bug 506861 ***


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