Similar problem as below exists if one upgrades from FC6 to F7 via yum... You
wind up with an unbootable system if you were stupid enough to nuke your old FC6
kernel somehow. Ideally, modprobe would be able to accept module options off the
kernel command line, so that adding 'libata.ignore_hpa=1' could be passed in at
boot time to get the system up and running.
+++ This bug was initially created as a clone of Bug #241288 +++
Description of problem:
Systems installed back in the FC6 and earlier days can have partitions that
extend into the host protected area of hard drives. The new libata drivers in F7
(and later) actually respect the HPA, resulting in being unable to upgrade
systems to F7 without some trickery.
The only options at the moment appear to be:
1) add 'options libata libata.ignore_hpa=1' to modprobe.conf under FC6 and
upgrade via yum
2) use setmax under FC6 to destroy the hpa
Ideally, users should be able to pass in the ignore_hpa option at install time,
or we could try reloading libata with that option if we encounter disks with
partitions extending into the hpa.
Install FC6 on a drive with a host protected area. Make sure one of the
partitions extends into that area. Try upgrading to F7.
 http://www.win.tue.nl/~aeb/linux/setmax.c and for a bit of info on usage,
I disagree with module-init-tools parsing the command line. This is (perhaps)
something for udevd to be doing, but ideally neither.
Closing as a WONTFIX - but please pass on to Harold if you want to persue the
udev route (you need something that's actually going to be able to do something
with that kernel command line and is running, rather than simple
module-init-tools utilities that aren't ever intended to parse that).
This has been upstream for a while.