so we can control it in our own incremental assembly specific rule file
- Don't build the static package, we don't install it, also remove the
glibc-static buildreq
we are supposed to
- Add a rule to run incremental assembly on containers in case there are
multiple volumes in a container and we only started some of them in the
initramfs
- Make -If work with imsm arrays. We had too restrictive of a test in
sysfs_unique_holder.
- Make incremental assembly of containers act like incremental assembly of
regular devices (aka, --run is needed to start a degraded array)
we are supposed to
- Add a rule to run incremental assembly on containers in case there are
multiple volumes in a container and we only started some of them in the
initramfs
- Make -If work with imsm arrays. We had too restrictive of a test in
sysfs_unique_holder.
- Make incremental assembly of containers act like incremental assembly of
regular devices (aka, --run is needed to start a degraded array)
we are supposed to
- Add a rule to run incremental assembly on containers in case there are
multiple volumes in a container and we only started some of them in the
initramfs
- Make -If work with imsm arrays. We had too restrictive of a test in
sysfs_unique_holder.
(bz557053)
- Don't report any mismatch_cnt issues on raid1 devices as there are
legitimate reasons why the count may not be 0 and we are getting enough
false positives that it renders the check useless (bz554217, bz547128)
(bz557053)
- Don't report any mismatch_cnt issues on raid1 devices as there are
legitimate reasons why the count may not be 0 and we are getting enough
false positives that it renders the check useless (bz554217, bz547128)
- Update a couple internal patches
- Drop a patch in that was in Neil's tree for 3.0.3 that we had pulled for
immediate use to resolve a bug
- Drop the endian patch because it no longer applied cleanly and all
attempts to reproduce the original problem as reported in bz510605
failed, even up to and including downloading the specific package that
was reported as failing in that bug and trying to reproduce with it on
both ppc and ppc64 hardware and with both ppc and ppc64 versions on the
64bit hardware. Without a reproducer, it is impossible to determine if
a rehashed patch to apply to this code would actually solve the
problem, so remove the patch entirely since the original problem, as
reported, was an easy to detect DOA issue where installing to a raid
array was bound to fail on reboot and so we should be able to quickly
and definitively tell if the problem resurfaces.
- Update the mdmonitor init script for LSB compliance (bz527957)
- Link from mdadm.static man page to mdadm man page (bz529314)
- Fix a problem in the raid-check script (bz523000)
- Fix the intel superblock handler so we can test on non-scsi block devices
- Update a couple internal patches
- Drop a patch in that was in Neil's tree for 3.0.3 that we had pulled for
immediate use to resolve a bug
- Drop the endian patch because it no longer applied cleanly and all
attempts to reproduce the original problem as reported in bz510605
failed, even up to and including downloading the specific package that
was reported as failing in that bug and trying to reproduce with it on
both ppc and ppc64 hardware and with both ppc and ppc64 versions on the
64bit hardware. Without a reproducer, it is impossible to determine if
a rehashed patch to apply to this code would actually solve the
problem, so remove the patch entirely since the original problem, as
reported, was an easy to detect DOA issue where installing to a raid
array was bound to fail on reboot and so we should be able to quickly
and definitively tell if the problem resurfaces.
- Update the mdmonitor init script for LSB compliance (bz527957)
- Link from mdadm.static man page to mdadm man page (bz529314)
- Fix a problem in the raid-check script (bz523000)
- Fix the intel superblock handler so we can test on non-scsi block devices
