2:47 p.m.
Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-may-21
Please make corrections and clarifications to the wiki page.
== Rawhide ==
* f13
* looks like Bill managed to get pungi to run on it, awesome. We now have installable
rawhide.
* just did a pungi spin using the static-repos and that seems to be going swimmingly
* latest rawhide should include mdraid fixes
* wwoods
* there's some selinux bogons in the current policy that I'm chasing.. notable
is the fact that semodule -i seems a bit broken 13:14 < wwoods> which is bad, since
that's basically how we tell people to work around *other* selinux problems
*
* iwl3945 wireless
* linville committed some fixes for it and is looking at it more today
* doesn't blowup machines any more, but needs more testing
* jeremy plans to look into it a little more
== F7 Blocker Status ==
* blocker list is down to 45 at the moment
* wwoods
* believe that mdraid is higher priority than iwl3945 because it keeps people from
being able to install/upgrade, especially people who are using RAID on IDE drives in FC6 -
i.e. people who have been with us a while. the hard-core folx we wanna keep.
* mdraid and dmraid account for.. I think 10 bugs?
* gaim/pidgin-libnotify is two more bugs
* bz 212781 the installer-hang-on-lowmem machines will need a release note if there
isn't an obvious fix
* gotta ask chip why this "symlink from /etc/alternatives/emacs to /usr/bin/emacs
is not created." bug is on the blocker
* f13 will look through blocker list
* nirik
* bz 240334 ... needs to get fluidsynth-devel
* due to extras not being built for ppc64 before the merge...
* fixing 240334 will get 2 bugs off the blocker list
* kernel update from davej
* alan posted a bunch of ata patches today that I'm going to suck up this
afternoon
* i'm sitting on a bunch of patches to fix up some more suspend regressions
* .21.2 still hasn't landed but will soon
* linville is working on wireless stuff
* magic 8 ball says "outlook promising" wrt to having a good enough kernel
for release by Thu/Fri
== Release Notes ==
* need to be built; currently building fine from cvs
* stickster will sync up with f13
* consider adding release notes to master schedule in the future or merging docs schedule
with master schedule
== Preparing RC (Release Candidate) ==
* fedora-release need to be rebuilt once we have a final name
* f13 punts naming task to notting
* release notes need to be built
== Plan to reach GA ==
* 24-MAY signed package RC1 created
* 24-MAY RC1 made torrentable
* 26-MAY RC2 planned respin for any fixes that we've been able to find necessary and
make.
* 26-MAY hand RC2 to Red Hat IS to start syncing for public availability
* 28-MAY confirm trees are GA worthy (if answer is "NO," GA date slips)
* 29-MAY begin sync to mirrors (takes 48 hours)
* 31-MAY GA
== Status of Bodhi ==
* Per lmacken he's really close.
* A few unspecified things need help
3:14 p.m.
On Tue, May 22, 2007 at 12:47:41 -0700,
John Poelstra <poelstra(a)redhat.com> wrote:
== Plan to reach GA ==
* 24-MAY signed package RC1 created
* 24-MAY RC1 made torrentable
* 26-MAY RC2 planned respin for any fixes that we've been able to find
necessary and make.
This is new. It might help to make this stand out so that people don't notice
until it is too late to give feedback between RC1 and RC2.
Are there going to be a complete set of spins that you are planning on
releasing or just selected ones?
Do you have an expectation of about what time on Thursday the torrent will
be made available?
10:07 a.m.
Bruno Wolff III wrote:
On Tue, May 22, 2007 at 12:47:41 -0700,
John Poelstra <poelstra(a)redhat.com> wrote:
> == Plan to reach GA ==
> * 24-MAY signed package RC1 created
> * 24-MAY RC1 made torrentable
> * 26-MAY RC2 planned respin for any fixes that we've been able to find
> necessary and make.
This is new. It might help to make this stand out so that people don't notice
until it is too late to give feedback between RC1 and RC2.
Are there going to be a complete set of spins that you are planning on
releasing or just selected ones?
Do you have an expectation of about what time on Thursday the torrent will
be made available?
Fedora release engineering can you provide guidance?
John
10:11 a.m.
On Wednesday 23 May 2007 11:07:04 John Poelstra wrote:
> This is new. It might help to make this stand out so that people
don't
> notice until it is too late to give feedback between RC1 and RC2.
>
> Are there going to be a complete set of spins that you are planning on
> releasing or just selected ones?
Probably just the select Fedora spin, and at least the Live ISO (non kde)
> Do you have an expectation of about what time on Thursday the
torrent
> will be made available?
Unfortunately I don't. Things are highly dynamic right now.
--
Jesse Keating
Release Engineer: Fedora
2:03 p.m.
On Wed, May 23, 2007 at 11:11:01 -0400,
Jesse Keating <jkeating(a)redhat.com> wrote:
On Wednesday 23 May 2007 11:07:04 John Poelstra wrote:
> > This is new. It might help to make this stand out so that people don't
> > notice until it is too late to give feedback between RC1 and RC2.
> >
> > Are there going to be a complete set of spins that you are planning on
> > releasing or just selected ones?
Probably just the select Fedora spin, and at least the Live ISO (non kde)
> > Do you have an expectation of about what time on Thursday the torrent
> > will be made available?
Unfortunately I don't. Things are highly dynamic right now.
OK, Thursdays aren't too good for me to keep a close eye on email, but I'll
try to check as best I can. I have a pretty good connection here at work,
and getting into the torrent early, I can probably share at out several
times more than I am taking in.
Most likely I won't get to do a test install until Friday evening in any
case.
4:12 p.m.
John Poelstra wrote:
== F7 Blocker Status ==
* blocker list is down to 45 at the moment
* wwoods
* believe that mdraid is higher priority than iwl3945 because it keeps
people from being able to install/upgrade, especially people who are
using RAID on IDE drives in FC6 - i.e. people who have been with us a
while. the hard-core folx we wanna keep.
I've got an mdraid box I'm trying to try out the latest fixes on, but
ran into an interesting issue with the host protected area on one of my
drives. The older pata drivers happily used this area for storage,
ignoring bios requests not to use it. The new libata drivers actually
respect it. As a result, one of the drives in my mdraid set was
unusable, because the partition table shows one of the partitions
extends beyond the last legal sector of the drive. Fun.
I've just reinstalled FC6 on the box, using only drives NOT impacted by
this so as to actually test the mdraid upgrade path, but it'll be
tomorrow before I get to it 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.
--
Jarod Wilson
jwilson(a)redhat.com
4:15 p.m.
Jarod Wilson wrote:
John Poelstra wrote:
> == F7 Blocker Status ==
> * blocker list is down to 45 at the moment
> * wwoods
> * believe that mdraid is higher priority than iwl3945 because it
> keeps people from being able to install/upgrade, especially people who
> are using RAID on IDE drives in FC6 - i.e. people who have been with
> us a while. the hard-core folx we wanna keep.
I've got an mdraid box I'm trying to try out the latest fixes on, but
ran into an interesting issue with the host protected area on one of my
drives. The older pata drivers happily used this area for storage,
ignoring bios requests not to use it. The new libata drivers actually
respect it. As a result, one of the drives in my mdraid set was
unusable, because the partition table shows one of the partitions
extends beyond the last legal sector of the drive. Fun.
I've just reinstalled FC6 on the box, using only drives NOT impacted by
this so as to actually test the mdraid upgrade path, but it'll be
tomorrow before I get to it now.
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...
--
Jarod Wilson
jwilson(a)redhat.com
1:55 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
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.
--
Jarod Wilson
jwilson(a)redhat.com
2:36 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
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!
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?
Would a respin be needed to get the installer to work for them (me)
(assuming they recovered from the first upgrade attempt)?
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:43 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
On Thursday 24 May 2007 15:36:16 Tony Nelson wrote:
Well, this keeps me from upgrading to F7!
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?
Would a respin be needed to get the installer to work for them (me)
(assuming they recovered from the first upgrade attempt)?
It wouldn't allow you to reuse the partition. There shouldn't be any data
loss, it would just be unable to deal with the existing disk/partition table.
An updates.img might take care of it, but it may also need a new kernel, which
would be a respin.
--
Jesse Keating
Release Engineer: Fedora
8:55 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
At 3:43 PM -0400 5/24/07, Jesse Keating wrote:
Content-Type: multipart/signed;
boundary="nextPart2761788.pS6UtIxnXi";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
On Thursday 24 May 2007 15:36:16 Tony Nelson wrote:
> Well, this keeps me from upgrading to F7!
>
> 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?
> Would a respin be needed to get the installer to work for them (me)
> (assuming they recovered from the first upgrade attempt)?
It wouldn't allow you to reuse the partition. There shouldn't be any data
loss, it would just be unable to deal with the existing disk/partition table.
An updates.img might take care of it, but it may also need a new kernel, which
would be a respin.
I am reassured. Thank you.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:49 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
On Thu, May 24, 2007 at 15:36:16 -0400,
Tony Nelson <tonynelson(a)georgeanelson.com> 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!
If you are using the HPA area, couldn't you update the disk so that the
area isn't there any more? The wikipedia entry for HPA suggests that there
is a command for getting the real size and another for updating the boundry.
So it sounds like you should be able to update this on F6 before doing the
upgrade.
8:55 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
At 2:49 PM -0500 5/24/07, Bruno Wolff III wrote:
On Thu, May 24, 2007 at 15:36:16 -0400,
Tony Nelson <tonynelson(a)georgeanelson.com> 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!
If you are using the HPA area, couldn't you update the disk so that the
area isn't there any more? The wikipedia entry for HPA suggests that there
is a command for getting the real size and another for updating the boundry.
So it sounds like you should be able to update this on F6 before doing the
upgrade.
It seems doable but would need at least two backups, as the first one will
almost certainly be put to use as the real data. And all for a measily 34
MB that is automatically discovered by the current kernels.
If a tested tool makes it into extras I'll do it with one backup!
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:58 p.m.
New subject: mdraid and hpa upgrade issues
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.
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?
Warning
The partition table on device sdX was unreadable. To create new
partitions it must be initialized, causing the loss of ALL DATA on this
drive.
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
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.
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.
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).
--
Jarod Wilson
jwilson(a)redhat.com
3:15 p.m.
New subject: mdraid and hpa upgrade issues
Jarod Wilson wrote:
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).
This link gives some data on how to use the setmax utility to nuke the
hpa area on a drive, which you could do under FC6, and subsequently, an
anaconda-based F7 upgrade should work fine:
http://www.niiconsulting.com/checkmate/2006/09/hiding-data-with-hpahost-p...
--
Jarod Wilson
jwilson(a)redhat.com
4:56 p.m.
New subject: mdraid and hpa upgrade issues
>>>> "JW" == Jarod Wilson
<jwilson(a)redhat.com> writes:
JW> This link gives some data on how to use the setmax utility to nuke
JW> the hpa area on a drive[...]
Someone should try this and then (assuming it works) we need to get
setmax into extras ASAP. I'll promise to review it quickly if someone
submits it.
- J<
5:11 p.m.
New subject: mdraid and hpa upgrade issues
Jason L Tibbitts III wrote:
>>>>> "JW" == Jarod Wilson
<jwilson(a)redhat.com> writes:
JW> This link gives some data on how to use the setmax utility to nuke
JW> the hpa area on a drive[...]
Someone should try this and then (assuming it works) we need to get
setmax into extras ASAP. I'll promise to review it quickly if someone
submits it.
Nah, not as necessary now, Jeremy hacked in support so you can pass the
necessary libata module option at install time so we can happily ignore
the hpa, and its working perfectly for me. It will need to be filed
under 'known issues' in the wiki, if it isn't already...
--
Jarod Wilson
jwilson(a)redhat.com
6:15 p.m.
New subject: mdraid and hpa upgrade issues
On Thu, May 24, 2007 at 04:15:28PM -0400, Jarod Wilson wrote:
Jarod Wilson wrote:
This link gives some data on how to use the setmax utility to nuke the
hpa area on a drive, which you could do under FC6, and subsequently, an
anaconda-based F7 upgrade should work fine:
http://www.niiconsulting.com/checkmate/2006/09/hiding-data-with-hpahost-p...
Depends on your BIOS and also jumper settings. If you have the "my bios is
dumb" clipping jumper set or your bios itself enforces an HPA for its save
area (or thinks it does ;)) notably laptops then it won't help one iota.
4:09 p.m.
New subject: mdraid and hpa upgrade issues
Jarod Wilson wrote:
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.
So like I said, never say never... Jeremy has a dirty little hack for me
to try out in a sec... Stay tuned!
--
Jarod Wilson
jwilson(a)redhat.com
6:13 p.m.
New subject: mdraid and hpa upgrade issues
On Thu, May 24, 2007 at 03:58:53PM -0400, Jarod Wilson wrote:
options libata libata.ignore_hpa=1
Then upgrade via yum. Sub-optimal for those who prefer to upgrade via
anaconda, but its an option.
>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?
From the testing done so far by our able advanced guard (aka Ubuntu
;))
we can probably safely default to ignore_hpa=1 which neatly side steps both
problems. The Nvidiot SAT bug ws probably the last real problem with it.
8:44 a.m.
New subject: mdraid and hpa upgrade issues
Alan Cox wrote:
From the testing done so far by our able advanced guard (aka Ubuntu
;))
we can probably safely default to ignore_hpa=1 which neatly side steps both
problems.
Personally, I'd rather see us respect the hpa whenever we can. Just
seems like the correct thing to do. Then again, it sounds like the only
case where its really necessary, the bios hard-codes it anyhow...
--
Jarod Wilson
jwilson(a)redhat.com
9:24 a.m.
New subject: mdraid and hpa upgrade issues
On Fri, May 25, 2007 at 09:44:09AM -0400, Jarod Wilson wrote:
Personally, I'd rather see us respect the hpa whenever we can.
Just
seems like the correct thing to do. Then again, it sounds like the only
case where its really necessary, the bios hard-codes it anyhow...
Its a real PITA to answer that. HPA is uses for
1. Hiding Windoze recovery partitions (depends on the user what is "right")
2. Clipping disks to work around old BIOSen (want to remove)
3. Hiding suspend partitions (generally want to keep it on)
4. Clipping odd sector count disks to even sizes (want to keep on)
and more..
10:11 a.m.
New subject: mdraid and hpa upgrade issues
Le Ven 25 mai 2007 16:24, Alan Cox a écrit :
On Fri, May 25, 2007 at 09:44:09AM -0400, Jarod Wilson wrote:
> Personally, I'd rather see us respect the hpa whenever we can. Just
> seems like the correct thing to do. Then again, it sounds like the
> only
> case where its really necessary, the bios hard-codes it anyhow...
Its a real PITA to answer that. HPA is uses for
1. Hiding Windoze recovery partitions (depends on the user what is
"right")
2. Clipping disks to work around old BIOSen (want to remove)
3. Hiding suspend partitions (generally want to keep it on)
4. Clipping odd sector count disks to even sizes (want to keep on)
and more..
Can't HPA be used by default for new installations, and be disabled
when the user asks to upgrade a pre-hpa fedora system ?
--
Nicolas Mailhot
11:40 a.m.
New subject: mdraid and hpa upgrade issues
Nicolas Mailhot wrote:
Le Ven 25 mai 2007 16:24, Alan Cox a écrit :
> On Fri, May 25, 2007 at 09:44:09AM -0400, Jarod Wilson wrote:
>> Personally, I'd rather see us respect the hpa whenever we can. Just
>> seems like the correct thing to do. Then again, it sounds like the
>> only
>> case where its really necessary, the bios hard-codes it anyhow...
> Its a real PITA to answer that. HPA is uses for
>
> 1. Hiding Windoze recovery partitions (depends on the user what is
> "right")
> 2. Clipping disks to work around old BIOSen (want to remove)
> 3. Hiding suspend partitions (generally want to keep it on)
> 4. Clipping odd sector count disks to even sizes (want to keep on)
>
> and more..
Ew.
As an aside, it would be nice if we could enable/disable hpa on a
per-drive (or at least per-controller) basis.
Can't HPA be used by default for new installations, and be
disabled
when the user asks to upgrade a pre-hpa fedora system ?
This late in the game, looks like we're going to stick with what we've
got right now, which is HPA respected by default, and the ability to
override it at install time if the installer is booted with
libata.ignore_hpa=1. First go 'round, those with partitions in the hpa
are going to get an ugly error message, but we'll stick something in
F7KnownIssues (or whatever it is) like we did for FC6 documenting the
work-around.
--
Jarod Wilson
jwilson(a)redhat.com
12:06 p.m.
New subject: mdraid and hpa upgrade issues
On Fri, May 25, 2007 at 12:40:46 -0400,
Jarod Wilson <jwilson(a)redhat.com> wrote:
This late in the game, looks like we're going to stick with what we've
got right now, which is HPA respected by default, and the ability to
override it at install time if the installer is booted with
libata.ignore_hpa=1. First go 'round, those with partitions in the hpa
are going to get an ugly error message, but we'll stick something in
F7KnownIssues (or whatever it is) like we did for FC6 documenting the
work-around.
Maybe we could get setmax into extras. It seems like a tool people might
have use for.
I built it and used it read only and it seemed to work. I got some warnings
about exit because it is missing:
#include <stdlib.h>
But otherwise it compiled cleanly.
I didn't want to try set an HPA on any of my drives, to see if that worked.
I also tested in of FC5, not F7.
I didn't see a license on the page where it is distributed, so someone
would have to check with Brouwer or rewrite it.
1:55 p.m.
New subject: mdraid and hpa upgrade issues
At 12:40 PM -0400 5/25/07, Jarod Wilson wrote:
...
This late in the game, looks like we're going to stick with what
we've
got right now, which is HPA respected by default, and the ability to
override it at install time if the installer is booted with
libata.ignore_hpa=1. First go 'round, those with partitions in the hpa
are going to get an ugly error message, but we'll stick something in
F7KnownIssues (or whatever it is) like we did for FC6 documenting the
work-around.
That workaround works here. I tried the Rescue CD (thanks, Bruno!) and
dmesg shows that with "libata.ignore_hpa=1" added to the command line the
hpa is disabled. I don't know what else I can do to test Anaconda from the
rescue CD -- perhaps start an HTTP install from, umm, somewhere?
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:06 p.m.
New subject: mdraid and hpa upgrade issues
On Fri, May 25, 2007 at 14:55:24 -0400,
Tony Nelson <tonynelson(a)georgeanelson.com> wrote:
At 12:40 PM -0400 5/25/07, Jarod Wilson wrote:
...
>This late in the game, looks like we're going to stick with what we've
>got right now, which is HPA respected by default, and the ability to
>override it at install time if the installer is booted with
>libata.ignore_hpa=1. First go 'round, those with partitions in the hpa
>are going to get an ugly error message, but we'll stick something in
>F7KnownIssues (or whatever it is) like we did for FC6 documenting the
>work-around.
That workaround works here. I tried the Rescue CD (thanks, Bruno!) and
dmesg shows that with "libata.ignore_hpa=1" added to the command line the
hpa is disabled. I don't know what else I can do to test Anaconda from the
rescue CD -- perhaps start an HTTP install from, umm, somewhere?
You could try using rawhide. I don't know for sure that they are tagged
the same, but I did see that everything in rawhide changed last night.
6 p.m.
New subject: mdraid and hpa upgrade issues
At 2:06 PM -0500 5/25/07, Bruno Wolff III wrote:
On Fri, May 25, 2007 at 14:55:24 -0400,
Tony Nelson <tonynelson(a)georgeanelson.com> wrote:
> At 12:40 PM -0400 5/25/07, Jarod Wilson wrote:
> ...
> >This late in the game, looks like we're going to stick with what we've
> >got right now, which is HPA respected by default, and the ability to
> >override it at install time if the installer is booted with
> >libata.ignore_hpa=1. First go 'round, those with partitions in the hpa
> >are going to get an ugly error message, but we'll stick something in
> >F7KnownIssues (or whatever it is) like we did for FC6 documenting the
> >work-around.
>
> That workaround works here. I tried the Rescue CD (thanks, Bruno!) and
> dmesg shows that with "libata.ignore_hpa=1" added to the command line the
> hpa is disabled. I don't know what else I can do to test Anaconda from the
> rescue CD -- perhaps start an HTTP install from, umm, somewhere?
You could try using rawhide. I don't know for sure that they are tagged
the same, but I did see that everything in rawhide changed last night.
That seemed to work OK.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
11:45 a.m.
New subject: mdraid and hpa upgrade issues
At 5:11 PM +0200 5/25/07, Nicolas Mailhot wrote:
Le Ven 25 mai 2007 16:24, Alan Cox a écrit :
> On Fri, May 25, 2007 at 09:44:09AM -0400, Jarod Wilson wrote:
>> Personally, I'd rather see us respect the hpa whenever we can. Just
>> seems like the correct thing to do. Then again, it sounds like the
>> only
>> case where its really necessary, the bios hard-codes it anyhow...
>
> Its a real PITA to answer that. HPA is uses for
>
> 1. Hiding Windoze recovery partitions (depends on the user what is
> "right")
> 2. Clipping disks to work around old BIOSen (want to remove)
> 3. Hiding suspend partitions (generally want to keep it on)
> 4. Clipping odd sector count disks to even sizes (want to keep on)
>
> and more..
Can't HPA be used by default for new installations, and be disabled
when the user asks to upgrade a pre-hpa fedora system ?
I think the issue is the other way around. Until F7, by default the kernel
disabled the HPA temporarily on each boot. Thus, the drive is formatted to
use thw whole size. But now that the behavior has changed, and the drive
size is smaller than the formatted size. So it isn't new installations
that are having a problem (unless the protected area is large), but old
installations that won't be upgradable. I expect this is all fallout from
the change to "all disks are SCSI disks".
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
2:33 p.m.
New subject: mdraid and hpa upgrade issues
On Fri, 2007-05-25 at 10:24 -0400, Alan Cox wrote:
On Fri, May 25, 2007 at 09:44:09AM -0400, Jarod Wilson wrote:
> Personally, I'd rather see us respect the hpa whenever we can. Just
> seems like the correct thing to do. Then again, it sounds like the only
> case where its really necessary, the bios hard-codes it anyhow...
Its a real PITA to answer that. HPA is uses for
would a reasonable default be
"honor HPA when making new partitions"
"ignore HPA for existing partition tables that cross it"
(how to implement that is a different kettle of fish obviously)
7:43 a.m.
New subject: mdraid and hpa upgrade issues
On Mon, May 28, 2007 at 12:33:07PM -0700, Arjan van de Ven wrote:
would a reasonable default be
"honor HPA when making new partitions"
"ignore HPA for existing partition tables that cross it"
I would say the reasonable default is always ignore the HPA in the kernel.
The repartitioning question is a matter for user tools
8:54 p.m.
New subject: mdraid and hpa upgrade issues
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?
Warning
The partition table on device sdX was unreadable. To create new
partitions it must be initialized, causing the loss of ALL DATA on this
drive.
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@georgeanelson.com>
' <http://www.georgeanelson.com/>
4:24 p.m.
New subject: mdraid and hpa upgrade issues (was: Fedora Rel-Eng Meeting Recap)
On Thu, 2007-05-24 at 14:55 -0400, 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).
Magic added to anaconda to recognize and dtrt with libata.ignore_hpa=1
as a command line flag. Post F7, I'll make it generic for all modules
and module options.
Jeremy
12:36 p.m.
On 5/22/07, John Poelstra <poelstra(a)redhat.com> wrote:
* iwl3945 wireless
* linville committed some fixes for it and is looking at it more today
* doesn't blowup machines any more, but needs more testing
* jeremy plans to look into it a little more
Is there anything specific i could be testing I could be doing and
reporting back on?
-jef
2:19 p.m.
Jeff Spaleta wrote:
On 5/22/07, John Poelstra <poelstra(a)redhat.com> wrote:
> * iwl3945 wireless
> * linville committed some fixes for it and is looking at it more
> today
> * doesn't blowup machines any more, but needs more testing
> * jeremy plans to look into it a little more
Is there anything specific i could be testing I could be doing and
reporting back on?
just use your card ;)
connect/disconnect to networks
download data / upload data
scan for networks etc.
if you notice any oops or other bugs, report them...
2:47 p.m.
On 5/23/07, dragoran <drago01(a)gmail.com> wrote:
Jeff Spaleta wrote:
> On 5/22/07, John Poelstra <poelstra(a)redhat.com> wrote:
>> * iwl3945 wireless
>> * linville committed some fixes for it and is looking at it more
>> today
>> * doesn't blowup machines any more, but needs more testing
>> * jeremy plans to look into it a little more
>
> Is there anything specific i could be testing I could be doing and
> reporting back on?
>
just use your card ;)
connect/disconnect to networks
download data / upload data
scan for networks etc.
if you notice any oops or other bugs, report them...
Still fails on first attempt a re-associating, same as before.....
Here is the beginning of the borkage. I'm actually connected to AP
00:14:6a:5b:3a:80 (WAP) when this happens. There are 2 APs for the
same network; perhaps the driver is dueling with both of them? [There
is also another WEP network present.]
May 23 12:37:46 localhost kernel: wlan0: authenticate with AP 00:14:69:3b:af:60
May 23 12:37:46 localhost kernel: wlan0: Initial auth_alg=0
May 23 12:37:46 localhost kernel: wlan0: authenticate with AP 00:14:6a:5b:3a:80
May 23 12:37:46 localhost kernel: wlan0: RX authentication from
00:14:6a:5b:3a:80 (alg=0 transaction=2 status=0)
May 23 12:37:46 localhost kernel: wlan0: authenticated
May 23 12:37:46 localhost kernel: wlan0: associate with AP 00:14:6a:5b:3a:80
May 23 12:37:46 localhost kernel: wlan0: RX deauthentication from
00:14:6a:5b:3a:80 (reason=2)
May 23 12:37:46 localhost kernel: wlan0: deauthenticated
May 23 12:37:46 localhost kernel: wlan0: RX WEP frame with unknown
keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80
A3=00:16:41:e2:48:c7)
May 23 12:37:46 localhost kernel: wlan0: RX WEP frame with unknown
keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80
A3=00:12:da:c3:84:c9)
Believe this is the same I've BZ'ed before.....
tom
--
Tom London
3:03 p.m.
just use your card ;)
connect/disconnect to networks
download data / upload data
scan for networks etc.
if you notice any oops or other bugs, report them...
I was wondering if there were specific things that the daily kernel
build churning was trying to address, that my day to day usage isn't
hitting. Today's kernel changelog speaks of iwl3945 related changes
by there's no referenced bug number for me to read up on.
-jef"why on earth does modprobe freak out and chew cpu when trying to
remove the iwl3945 module?"spaleta
3:15 p.m.
Jeff Spaleta wrote:
> just use your card ;)
> connect/disconnect to networks
> download data / upload data
> scan for networks etc.
> if you notice any oops or other bugs, report them...
I was wondering if there were specific things that the daily kernel
build churning was trying to address, that my day to day usage isn't
hitting. Today's kernel changelog speaks of iwl3945 related changes
by there's no referenced bug number for me to read up on.
-jef"why on earth does modprobe freak out and chew cpu when trying to
remove the iwl3945 module?"spaleta
Just have a look through the official iwlwifi bugzilla for the reaction
level to externally reported problems
http://bughost.org/bugzilla/buglist.cgi?query_format=specific&order=r...
However the driver is getting reviewed at the moment for inclusion into
the mainline kernel and it seems that things will improve. Perhaps
including not pushing things into closed source firmware that are better
done in the 80211 stack.
-Andy
6175
days inactive
6182
days old
37 comments
14 participants
participants (14)
-
Alan Cox -
Andy Green -
Arjan van de Ven -
Bruno Wolff III -
drago01 -
Jarod Wilson -
Jason L Tibbitts III -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
John Poelstra -
Nicolas Mailhot -
Tom London -
Tony Nelson