Bug 533739

Summary: Partial initialization of Intel BIOS RAID arrays by the live CD could lead to data corruption
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: livecd-toolsAssignee: Jeremy Katz <katzj>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: rawhideCC: dcantrell, hdegoede, jlaska, katzj, notting, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-10 01:08:47 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:
Bug Depends On:    
Bug Blocks: 473303    
Attachments:
Description Flags
PATCH: add noiswmd to livecd kernel cmdline none

Description Adam Williamson 2009-11-08 20:50:04 UTC 
Explanation from hansg:

"Unfortunately I've not given enough thought to the livecd case when it comes to the new way of handling isw BIOS RAID by using mdraid (something which was very heavily pushed by Intel).

The problem is that rc.sysinit does not bring up ISW RAID sets anymore through dmraid (they are filtered out of the sets detected by dmraid as they should be using mdraid).

For new installations, an /etc/mdadm.conf gets written by anaconda which makes the generic mdadm invocation in rc.sysinit bring them up.

This however won't work for the livecd case, so people will see their raw disks there instead."

<adamw> hasng: what will actually happen in the live installer, if you have a) a working Intel BIOS RAID and and b) a broken one

<hansg> adamw, data corruption in Intel BIOS RAID mirrors

<hansg> adamw, I have no idea what will happen in the live installer when using the live installer as is with Intel BIOS RAID, merely booting the livecd could be enough for data corruption (worse case scenario, not very likely)

<hansg> adamw, writing to the systems disks as mounted under /media will definitely cause data corruption, I've seen befoee what happens when writing to only one disk of a mirror with an ext3 filesystem and then later trying to mount it again as a mirror. Let me summarize it by saying that the kernel ext3 code is not 100% fail proof to corruptfs data and the kernel went boom

The proposed fix is to add the 'noiswmd' kernel parameter to the live CD boot. This will stop these arrays being handled by mdraid and they will be handled by dmraid instead, as they were before. Jesse points out that this will make the behaviour of the live CD and traditional installer different, which sucks, but is better than potential data corruption.

The parameter is a complete no-op unless the system actually has an Intel BIOS RAID set, and if it does have one only reverts to known-okay F11 behaviour. Given that low impact I would be in favour of taking the fix in RC4 re-spin.
Comment 1 Hans de Goede 2009-11-08 21:02:55 UTC 
Created attachment 368081 [details]
PATCH: add noiswmd to livecd kernel cmdline
Comment 2 Jeremy Katz 2009-11-09 02:44:45 UTC 
You should be able to do this entirely from within the spin config with
  bootloader --append='noiswraid'
rather than explicitly adding it in livecd-creator.  This has the added advantage of when it *DOES* work, you just have to remove the paramter from the config file rather than putting yet more internal system knowledge in livecd-creator and making it even more version specific.
Comment 3 Adam Williamson 2009-11-09 03:21:25 UTC 
great tip, about four hours too late for the rc4 compose :( sorry, we're doing everything at crazy-release-crunch speed as we need to have some vague kind of testing in time for the go/no-go tomorrow, so we did it with something v. similar to hans' patch, rc4 is already up now.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Jeremy Katz 2009-11-09 03:40:17 UTC 
(In reply to comment #3)
> great tip, about four hours too late for the rc4 compose :( sorry, we're doing
> everything at crazy-release-crunch speed as we need to have some vague kind of
> testing in time for the go/no-go tomorrow, so we did it with something v.
> similar to hans' patch, rc4 is already up now.

You do release that crazy-release-crunch-speed is the quickest way to actually introduce errors and new problems, right?
Comment 5 Adam Williamson 2009-11-09 04:00:53 UTC 
yes, but in order to actually get meaningful testing of the proposed build before the go/no-go meeting, it had to be built quickly. this isn't a topic for bugzilla, though.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Jesse Keating 2009-11-10 01:08:47 UTC 
This change got made and the live images were re-spun with this updated livecd-tools.  Closing this.

It is not however "fixed" in F13 rawhide, so that will still have to be fixed there, hopefully really fixed and not just stuffed back to dmraid functionality.