Bug 547560
| Summary: | error message "disk sda not found" misleading if disk contains BIOS RAID data | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christian Krause <chkr> | ||||||
| Component: | anaconda | Assignee: | Hans de Goede <hdegoede> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | hdegoede, vanmeeuwen+fedora | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-12-16 10:30:17 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 378384 [details]
kickstart log file
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. (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. 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. (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 *** |
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