*** This bug is a duplicate of bug 191119 ***
https://bugs.launchpad.net/bugs/191119
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.
--
Non-selected Raid Array Corruption from Installer
https://bugs.launchpad.net/bugs/568183
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
