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[1] 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. How reproducible: Install FC6 on a drive with a host protected area. Make sure one of the partitions extends into that area. Try upgrading to F7. Additional info: [1] http://www.win.tue.nl/~aeb/linux/setmax.c and for a bit of info on usage, http://www.niiconsulting.com/checkmate/2006/09/hiding-data-with-hpahost-protected-area-in-linux/
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). Jon.
This has been upstream for a while.