https://bugzilla.novell.com/show_bug.cgi?id=299267#c2 --- Comment #2 from Joe Harmon 2007-08-10 08:53:17 MST --- Created an attachment (id=156813) --> (https://bugzilla.novell.com/attachment.cgi?id=156813) second error -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c4 --- Comment #4 from Joe Harmon 2007-08-10 08:53:55 MST --- Created an attachment (id=156815) --> (https://bugzilla.novell.com/attachment.cgi?id=156815) hardware information -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |fehr@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c7 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #7 from Thomas Fehr 2007-08-13 04:10:07 MST --- The partition table on your disk was invalid. Your disk has 14589 cylinders but your last partition ended on cylinder 14593. This makes parted display the error message "Can't have a partition outside the disk" and refuse to display partitions for that disk. In this case YaST2 falls back to information from /proc/partitions but is unable to modify partitions except deleting the partition table. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c9 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #9 from Thomas Fehr 2007-08-27 02:40:17 MST --- Please open a different bug report for a different problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c11 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |jharmon@novell.com --- Comment #11 from Thomas Fehr 2007-08-27 08:40:53 MST --- If it really is the same error could only be verified with y2log files. Maybe kernel driver for this disk changed in a way that it reported a different disk size with SLES10 and SL 10.3. If this would be the case the problem you observe would be always if you install on 10.3 after SLES. Could you attach y2log files of SLES10 installation that is still on the disk. So I can compare the disk size detected on SLES10 with disk size detected on SL 10.3. If possible, also y2log file of 10.3 installation would be helpful. If you do not want to do a full installation of 10.3 again. The output of "parted /dev/sda unit cyl print" on SL 10.3 (e.g. from rescue system) should be sufficient. If parted still says "Can't have a partition outside the disk" this is really the same problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c13 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |jharmon@novell.com --- Comment #13 from Thomas Fehr 2007-08-28 05:35:57 MST --- This is the y2log of 10.3 installation and parted still reports /usr/sbin/parted -s /dev/sda unit cyl print BIOS cylinder,head,sector geometry: 14589,255,63. Each cylinder is 8225kB. Error: Can't have a partition outside the disk! So it is just the same problem as in the original logs. But since you did exactly the same as in original report there is no surprise in this. As long as you have a partition layout that is not supported by parted you will not be able to repartition the disk unless you create a complete new partition table. If possible could you attach the content of /var/log/YaST2 of SLES10 install on the disk. Alternatively you could provide me with ssh root access to the machine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c15 --- Comment #15 from Thomas Fehr 2007-08-28 11:40:21 MST --- Often installation proposals suggest reusing existing partitions. If this is the case, SLES10 code does not create your partition layout but simply reuses existing partitions. The older parted version on SLES10 was apparently less strict when checking for inconsistencies. So the problem with your inconsistent partition table could very well be present since before SLES10 installation. This is the reason why I want to look at y2log file of SLES10 install. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c17 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fehr@novell.com AssignedTo|fehr@novell.com |kernel-maintainers@forge.provo.novell.com Status|REOPENED |NEW Component|Installation |Kernel QAContact|jsrain@novell.com |qa@suse.de --- Comment #17 from Thomas Fehr 2007-08-28 12:05:30 MST --- Thanks for the log files. It indeed seems that the disk size recognized by SLES10 is larger than the disk size recognized by SL 10.3. Content of /proc/partitions for SLES10: 3 0 117220824 hda" Content of /proc/partitions for SL 10.3: 8 0 117187500 sda This could be potentially fatal since it not only makes parted unable to modify such a partition table (it bails out with "Can't have a partition outside the disk") but might also lead to filesystem corruption, metadata corruption with mdraid and other nasty problem. The driver used in SLES10 was "piix" while the driver in SL10.3 is ata_piix. There is not much one can do in userland to fix that. Reassigning to kernel maintainers. It needs to be avoided under all circumstances that disks shrink in size when updating from older releases to SL 10.3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c19 --- Comment #19 from Tejun Heo 2007-08-28 18:08:52 MST --- HPA unlock support is now included in libata but it isn't enabled by default for the following reasons. * compatibility with older libata * BIOSen got more involved with system operation (ACPI and stuff) and may expect HPA to be in certain state. * Not as necessary as before. HPA used to be used to limit disk size to work around dumb BIOSen or OSes making HPA unlocking much more important but it isn't the case anymore. The magic parameter is libata.ignore_hpa. If set to 1, libata will unlock the HPA area, which I don't think we should do by default. Here are possible alternatives. * Make a boot menu to enable HPA unlocking and instruct the user about it if partition table doesn't make sense so that the user can restart. * (More complex) HPA can be unlocked from the userland. If partition table reaches over the end of the device, unlock HPA on all HDDs, detach all by echoing to sysfs delete node and request rescan in order by echoing to /sys/class/scsi_host/hostX/scan. When rescan is complete, the system is running with HPA unlocked devices. Retry partitioning. In both cases, the installer should remember that HPA needs unlocking and adds 'libata.ignore_hpa=1' to menu.lst during installation. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c21 --- Comment #21 from Tejun Heo 2007-08-29 05:51:10 MST --- It's a policy decision and both directions have pros and cons. In the long term, I think we should move away from unlocking HPA area by default. It isn't necessary for normal operation anymore and the spec specifically states that HPA is reserved for BIOS (firmware) and not to be meddled with by OS. As I wrote before, some ACPI implementation might depend on it too. But you're also right that maintaining compatibility with older distributions is very important. I think the best we can do here is implementing auto fallback mechanism so that we can move forward while maintaining backward compatibility where necessary. I can implement SET_MAX snoop in the driver such that userland can unlock HPA without worrying about device detach and rescan. 1. check partition table, if it extends beyond the current limit and unlocking HPA will make the partition table valid, issue SET_MAX 2. libata snoops SET_MAX and on completion resizes the device accordingly. 3. userland continues. Basically, there will be an executable which unlocks HPA iff the existing partition table requires it. It can probably be called from udev after each libata device detection. This will work for both during and after installation and drives with mixed HPA locked/unlocked status should work fine too. How does it sound? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c23 --- Comment #23 from Thomas Fehr 2007-08-29 06:24:12 MST --- Another idea, could you provide me with a binary that can be called with a disk device as parameter and returns the reliable information if this device need HPA to be unlocked to be compatible to previous releases. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c25 --- Comment #25 from Christoph Thiel 2007-08-30 10:42:37 MST --- Alright, Tejun, are you going to change the default for the upcoming Beta3 then? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c27 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|fehr@novell.com |snwint@novell.com --- Comment #27 from Thomas Fehr 2007-09-03 04:00:36 MST --- This is not my decision. If we do it by kernel parameter we need to keep this kernel parameter virtually forever (unless upstream changes default). The kernel parameters are handled by linuxrc. I already talked to Steffen Winterfeld about this last week and he was not very keen on having a kernel parameter for every system with ATA disks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c29 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint@novell.com Status|NEEDINFO |ASSIGNED Info Provider|snwint@novell.com | --- Comment #29 from Steffen Winterfeldt 2007-09-03 06:13:15 MST --- Adding a kernel parameter will mean to modify all our bootloader scripts to get the update case right. Also, I fear it will be difficult to get rid of the option later on. And, a kernel parameter will not solve the vanilla kernel example, as the user would have to add the option there as well. My suggestion would be to turn HPA off as default in our kernel as that is what most user would expect (given that we are doing the ide -> libata driver transition with this release) and sort out a better solution after 10.3 (maybe based on a user land tool letting users turn HPA on/off per disk). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c31 Tejun Heo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hare@novell.com --- Comment #31 from Tejun Heo 2007-09-03 10:12:58 MST --- [cc'ing Hannes... Hmmm... Which email address do I use to cc Neil Brown?] Hmmm... It seems that most other distros aren't defaulting to unlocking HPA. Apparently, no one has paid much attention to it. I think it would be very nice if we can keep consistent behaviors with other distros. Also, I realized that HPA-locked -> unlocked transition can be dangerous for on-disk formats which put their metadata at the end of device and use device size to access it. Do some of md/dm fall in this category? PS. I won't be able to get online for a few days from now on. I'll get back to this issue as soon as I get back. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c33 --- Comment #33 from Thomas Fehr 2007-09-04 03:57:33 MST --- md stores its metadata at the end of a partition, not the disk. So it should be unaffected by a growing disk. dmraid metadata is at the end of the disk but the metadata is put there by the BIOS of special raid controllers (aka as fake-raid). I doubt these controllers support hpa lock/unlock in addition to BIOS raid so this should not be a problem. Currently I see no problem with a growing disk (except maybe GPT disk label, but AFAIK it inly spits out a warning if disk size is largere that metadata size). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=299267#c36 Tejun Heo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #36 from Tejun Heo 2007-09-06 21:16:49 MST --- Committing patch and resolving as FIXED. Please test when RC1 comes out. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.