Bug 152158 - RAID1 setup with one working disk / one failed disk actively prevented by anaconda
RAID1 setup with one working disk / one failed disk actively prevented by ana...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-25 09:24 EST by Graham Leggett
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 16:17:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Graham Leggett 2005-03-25 09:24:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050130 Fedora/1.7.5-3

Description of problem:
If an attempt is made to set up a RAID1 mirrored partition with only one drive present (the second "missing" drive is marked as a "failed-disk" until such time as it can be installed) anaconda actively stops you from proceeding with the install, claiming that two drives are necessary to continue.

This claim is incorrect, as it is quite possible to configure RAID manually with one "failed-disk". To fix this bug, the fatal error dialog should be changed to a warning dialog, and the user allowed to continue.

To further complicate matters, the Fedora install process is incapable of detecting Fedora installations where only one half of a RAID1 mirror is present. This renders it impossible to either install or upgrade a Fedora system in a degraded system state, turning a difficult to upgrade system into an impossible to upgrade system. (Upgrading the one half of the RAID1 mirror only means that the other half of the mirror is available for disaster recovery, and considering the high number of bugs and actively prevented use cases in the upgrade process, this backup drive is critical).

These alternate use cases may not seem critical to the majority of cases, however when things go wrong, actively preventing the user from being able to fix problems turns a one hour job into a one day job, drastically increasing the cost of ownership for Redhat based systems.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
xxx

Additional info:
Comment 1 Jeremy Katz 2005-03-28 14:01:22 EST
Upgrades and installs require a fully functioning system.  And on a RAID system,
that means we need all RAID members to be present and working.  Otherwise, there
are some very strange failure cases that could cause larger problems.
Comment 2 Graham Leggett 2005-03-28 15:07:02 EST
I have just had a very stern word with my system for breaking and requiring an
upgrade to fix it, and I also just roundly chastised my hardware supplier for
not being open for business and ready to deliver the replacement drive and other
parts at 2am on friday morning.

"Upgrade" can be defined as "moving a software system from broken hardware to
new fixed or less broken hardware". Anaconda's insistence that all platforms are
"perfect" before an upgrade will work means simply that a Redhat system is not
recoverable in case of failure. Our solution was to scrap the old system
entirely and reinstall it from scratch, as there was no way whatsoever that the
old system would boot up on new hardware.

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