DANGER!!! Problems with 10.04 installer (RAID devices *will* get corrupted)
alvin at thompsonlogic.com
Thu Apr 22 15:31:43 UTC 2010
On 04/22/2010 03:38 AM, Andrew Farris wrote:
>> Oh I understand that the installer is messing up stuff but people here
>> are saying that nah, it's a borky fakeraid controller you have because
>> of the #191119 link.
> I still don't buy the 'it's a fakeRAID controller problem'
> explanation... it feels too much like a cop-out answer when its fairly
> obvious (to me anyway) that the problem doesn't lie in the raid
> controller, but the installer, regardless of any 'oh this controller
> isn't open' issues.
> Also, as far as I understand the issue, even if the controller driver
> implements some sort of proprietary BS in order to control the array on
> windows, and doesn't on linux, the windows installer is STILL smart
> enough to not write changes to the raid array, if you tell it not to
> write the changes. It's also still smart enough to actually tell that
> it's a RAID array during installation, before this 'proprietary driver'
> has been loaded, making the issue moot for most usage cases (I say most
> because I'm aware that it's sometimes necessary to load a custom raid
> driver before starting the installation).
> All other issues aside, the issue here seems (to me at least) be an
> issue with the installer detecting what these partitions 'used to be'
> rather than 'what they are' and therefore is mis-handling them...and
> this is un-undeniably a fault in the installer... and possibly the
> partitioning tools for leaving this information intact in the first
> place (Why is this even done? If somebody can tell me, I'd be most
Finally! At least there is hope for some people here. The one
nit-picky issue I have with what you said is that it would have to be
the responsibility of mdadm (or the RAID controller) to wipe the
previous file system when adding devices to the array. This isn't
practical because (a) it doesn't know about file systems, (b) it can't
know about future file systems, and (c) the installer can't assume that
the array controller did it anyway.
The best solution is for the array controller to simply leave its
'brand' on the device on the array so others know the device is
currently being used in an array, and not to touch it. This is already
implemented in the form of a 'RAID superblock', which the installer ignores.
> The reason I believe this 'leftover' partition data is root cause is
> because a friend of mine had an eerily similar issue, except that he had
> some drives in a RAID array, and decided to dump the RAID in favor of
> rsync backups instead. His issues began after reinstalling, because
> after wiping the partitions, and setting them up as 2 separate disks
> (removing all references to them being a soft-RAID device) upon booting
> into his new install, the boot failed because Ubuntu was still trying
> treat the drives as a RAID device. His solution was basically to
> manually edit bits in the partition table and removing the old entry
> indicating that the disk was in a RAID array... even though he got it
> fixed, this step was completely unnecessary, and was clearly not an
> issue with the RAID controller, but a fault in the installer's handling
> of RAID.
Actually, your friend's problem sounds like he forget to remove the RAID
superblock when he no longer wanted to use the drives in an array. If
he's using software RAID, he can do that with the "mdadm
More information about the ubuntu-users