This bug was fixed in the package linux - 2.6.37-12.26
---
linux (2.6.37-12.26) natty; urgency=low
[ Andy Whitcroft ]
* rebase to v2.6.37-rc8
* [Config] armel -- reenable omap flavour
* [Config] disable CONFIG_MACH_OMAP3517EVM to fix FTBS on armel omap
* [Config] disable CO
It seems that the desired functionality has hit mainline (v2.6.35 and
later), that HPA will start enabled but will be unlocked should the
partitions require it:
commit d8d9129ea28e2177749627c82962feb26e8d11e9
Author: Tejun Heo
Date: Sat May 15 20:09:34 2010 +0200
libata: implement on
sudo bash -c 'echo options libata ignore_hpa=0 >
/etc/modprobe.d/libata.conf' should do the trick.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/380138
Title:
Do NOT disable HPA by default -> leads
Any known workaround for 10.04? This is so annoying. I have P35-DS4 with
two HDD in RAID1, with ALL important data on it. Forunately, Windows 7
is installed on separate physical SSD disk, but previously many system
files (TEMP, hiberfile, pagefile) were on RAID. It caused numerous
surprising errors
With Ubuntu 9.04 (and vicinity), to solve the problem of raid
corruption, I was simply adding to the boot string (F6):
libata.ignore_hpa=0
With Ubuntu 10.04 (and now with 10.10) this parameter doesn't work
anymore and every time I restart the PC from Ubuntu, I always have the
raid corrupted; so I
It appears that upstream has implemented a change where the HPA is
automatically unlocked if needed to access partitions described in the
partition table, rendering the original patch obsolete. Can we please
get this dropped now?
--
Do NOT disable HPA by default -> leads to data loss
https://bug
All I done was...
1- Disable backup bios to disk in gigabyte bios if enabled
2- Disable HPA with HDAT2 (disk must be in sata mode not raid)
3- Back to raid mode and recreate raid
5- Particioning raid with other OS. (Lucid has a bug particioning raid
disk, I used fedora 13 live usb)
6- Now inst
I have next configuration:
Gigabyte P35-DS4 Bios F14c
2 x Seagate 320 GB RAID 0 Intel Matrix Storage:
Dual Boot XP + Windows 7
1 x Seagate 160 GB
Ubuntu 10.04
When I boot to Ubuntu and reboot, first member Raid fail (it says Non-Raid
Disk) and i cannot boot to Windows partitions.
I need
So Andy, it has been some time now, how is this coming? Think we can
stop diverging from upstream on this with maverick?
--
Do NOT disable HPA by default -> leads to data loss
https://bugs.launchpad.net/bugs/380138
You received this bug notification because you are a member of Ubuntu
Bugs, which
Yes, you're right and HPA disabled in firmware is useful as long as you
don't move the HDD to another machine, but I supposed that as long as you
stay things the same, this solution is far simpler than messing up with
libata.
Just my 2 cents.
On Wed, Apr 7, 2010 at 2:08 PM, Phillip Susi wrote:
You don't need that HDAT2 tool, hdparm can set HPA permanently (or
disable it when set to full size). By default it is a temp. change like
what is done with that disabling now, but
hdparm -N /dev/sdX
shows HPA
hdparm -N xxx /dev/sdX
sets HPA to xxx temp. or
hdparm -N xxxp /dev/sdX
for permane
On 4/7/2010 12:14 PM, EagleDM wrote:
> I do not agree.
>
> If you use the program HDAT2, boot from that and DISABLE HPA, the
> program will disable it on the Firmware Level.
>
> At least in my case, with a Velociraptor RAID0 Array, both HPA's on both
> disks were permanently disabled, I no longer
I do not agree.
If you use the program HDAT2, boot from that and DISABLE HPA, the
program will disable it on the Firmware Level.
At least in my case, with a Velociraptor RAID0 Array, both HPA's on both
disks were permanently disabled, I no longer have problems with Ubuntu
since I disabled it.
--
The HPA is not removed from the drive, just temporarily disabled, so it
will return after a hard power cycle. This does have the undesired
result however, of breaking windows if you warm boot. You would think
that the reboot would reset the drive, but alas...
--
Do NOT disable HPA by default ->
HPA ignore by default is a DISGRACE decision, basically what it does, is
if you are already using DMRAID for MatrixRAID, NVRAID, etc, etc, it
simply destroys the hpa information on boot, and this cannot be fixed.
After tedious testing I found out that, once a single boot is made with
HPA ignoring
The patch in question ended up in the kernel as part of the move of all
configuration options out of modprobe.d/options to better support a
portable udev/kernel configuration. In discussions with those who
remeber the history the main issue is that probabally this option should
never have been ena
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Andy Whitcroft (apw)
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
--
Do NOT disable HPA by default -> leads to data loss
https://bugs.launchpad.net/bu
This report is referring to the commit below:
commit abc55974c570b037c04d33b32f269cd9e9f11bee
Author: Scott James Remnant
Date: Tue Mar 3 14:20:01 2009 +
UBUNTU: SAUCE: libata: Ignore HPA by default.
This was previously changed by using an "options" line in a modprobe.d
** Visibility changed to: Public
** This bug is no longer flagged as a security vulnerability
--
Do NOT disable HPA by default -> leads to data loss
https://bugs.launchpad.net/bugs/380138
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
19 matches
Mail list logo
