(copying comment from bug 568183) Thanks for the answer, but now that I think about it, I'm not sure NEW_LABEL alone would cause wholesale RAID array corruption. Correct me if I'm wrong because I'm not an expert on how parted works, but that bug with NEW_LABEL would only overwrite the RAID superblock and not the data? In which case, the RAID array would just start up in degraded mode and have to be re-synced. In my case, and in the original bug report, and in NickJ's case, the array was not degraded, but rather the data on the array was corrupted.
Even supposing the NEW_LABEL command did cause the corruption, while it may have been an upstream bug that physically wrote to the disk and caused that problem, the root of all evil is still the installer that incorrectly told parted there was a file system present on a device that's a component of the RAID array. Are you saying that parted is also responsible for detecting which file systems are present as well, and the installer only reports it? In any case it needs to be fixed, because only bad things can happen if the installer doesn't know what file systems are actually present. In any case, there needs to be basic safeguards in place which prevent the installer from writing directly to partitions with a RAID superblock, has a "RAID autodetect" partition type, or are in a logical volume. I guess you could argue that this would rather be an enhancement, in the way you could argue that a car without brakes is not a defect, but rather brakes would be a nice-to-have enhancement. -- Installer corrupts raid drive https://bugs.launchpad.net/bugs/191119 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
