mdraid and hpa upgrade issues
tonynelson at georgeanelson.com
Fri May 25 01:54:25 UTC 2007
At 3:58 PM -0400 5/24/07, Jarod Wilson wrote:
>Tony Nelson wrote:
>> At 2:55 PM -0400 5/24/07, Jarod Wilson wrote:
>>> Jarod Wilson wrote:
>>>> Okay, fc6 mdraid to f7 upgrading via anaconda works for me now.
>>>>> Once that's done, I'll see what I can do to see if the kernel option
>>>>> libata.ignore_hpa can be used to help those who don't really wanna
>>>>> nuke their entire system to move from FC6 to F7.
>>>> Starting in on this right now...
>>> Got the problem reproducing, but...
>>> Unknown boot option 'libata.ignore_hpa=1': ignoring
>>> Talked to davej, module parameters can't be passed on the command line
>>> just yet. So anyone with an FC6 system that uses part of the host
>>> protected area is currently not able to upgrade to F7 using anaconda
>>> (FC6 to F7 can be done with some modprobe.conf magic and upgrading via
>>> yum though).
>>> davej is going to poke some folks who were working on a patch to allow
>>> module parameters to be passed on the kernel command line.
>> Well, this keeps me from upgrading to F7!
>Not entirely. You can put the following into /etc/modprobe.conf:
>options libata libata.ignore_hpa=1
>Then upgrade via yum. Sub-optimal for those who prefer to upgrade via
>anaconda, but its an option.
I might do that.
>> How serious a problem results from doing an installer upgrade from FCx to
>> F7, no repartitioning? Is it going to cause massive data loss for
>> unsuspecting users, or does the Anaconda notice and stop the process?
>The partition table on device sdX was unreadable. To create new
>partitions it must be initialized, causing the loss of ALL DATA on this
>This operation will override any previous installation choices about
>which drives to ignore.
>Would you like to initialize this drive, erasing ALL DATA
>No(selected by default) Yes
This is good enough, though an unwelcome surprise for someone who would
have just downloaded 4 GiB of data. Since the kernel automatically
temporarily disables the HPA it might be very common.
>> Would a respin be needed to get the installer to work for them (me)
>> (assuming they recovered from the first upgrade attempt)?
>At this point in time, its way too late in the game to get a fix into
>anaconda, so yes, either a respin or possibly an updates.img as Jesse
>suggested would be the only way to get anaconda-based upgrades working
>in this situation.
What I thought.
>The initial thought is that we'll have to patch both anaconda and
>modprobe to be able to recognize and apply kernel module options passed
>on the kernel command line. I'll be filing bugs against both
>module-init-tools and anaconda shortly. Never say never, but getting a
>fix in for the F7 release is highly, highly, highly unlikely.
What I thought. I see by the later posts that a solution may have been found.
>Ah, just noticed the email in this thread from Bruno... Could be some
>way to deep-six the hpa area within FC6 before upgrading... (and
>personal experience would suggest this can be done somehow -- I had a
>drive that used to have the hpa issue and now doesn't -- but I know not
>the magic incantation).
It's apparantly fairly simple; it's what the kernel normally does with a
flag set to say "permanent" rather than "temporary".
TonyN.:' <mailto:tonynelson at georgeanelson.com>
More information about the fedora-devel-list