FC3rc5

[Elliot Lee]

For your weekend enjoyment, please try:

http://fedora.linux.duke.edu/FC3-rc/3/
http://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
rsync://sunsite.mff.cuni.cz/ftp/OS/Linux/Dist/Fedora.RC/3/
http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 8pm EDT Oct
29.)

This is likely to be the last FC3 release candidate, so please give it all
the loving attention you possibly can. It does have fixes for some of the
more serious issues reported here - your efforts are having results. When
testing FC3rc5, things that could use extra-special attention are upgrades
and the kernel. Please make sure to file any showstopper bugs (data loss
or corruption, major install/upgrade failures)  in bugzilla and bring the
bug #'s to our attention.

In respond to all the queries about "why are the .iso timestamps
changing", it's because I'm putting the latest RC in the same location as
the older ones, so the files do change.

Thanks y'all!
-- Elliot

[Kim Lux]

How does this compare with the files that were in FC3-rc/3/ yesterday ?

They were dated October 28th.  Is there a changelog ?  What repositories
would one use to get to what you are posting today ?

How do we refer to these versions when posting in Bugzilla ?

BTW: I posted 5 bugs today from the Oct 28th "rc3"

Some appear to be being worked on as I write this. 


On Fri, 2004-10-29 at 17:03 -0400, Elliot Lee wrote:
>  For your weekend enjoyment, please try:
>  
>  http://fedora.linux.duke.edu/FC3-rc/3/
>  http://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
>  ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
>  rsync://sunsite.mff.cuni.cz/ftp/OS/Linux/Dist/Fedora.RC/3/
>  http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 8pm EDT Oct
> 29.)
>  
>  This is likely to be the last FC3 release candidate, so please give it all
>  the loving attention you possibly can. It does have fixes for some of the
>  more serious issues reported here - your efforts are having results. When
>  testing FC3rc5, things that could use extra-special attention are upgrades
>  and the kernel. Please make sure to file any showstopper bugs (data loss
>  or corruption, major install/upgrade failures)  in bugzilla and bring the
>  bug #'s to our attention.
>  
>  In respond to all the queries about "why are the .iso timestamps
>  changing", it's because I'm putting the latest RC in the same location as
>  the older ones, so the files do change.
>  
>  Thanks y'all!
>  -- Elliot
>

[Kim Lux]

Here are the bugs I posted today:

137579 	No sound/artsd goes wild in fresh FC3rc3
137582  kfind hangs on search in FC3t3 and FC3rc3
137610  Kdevelop crashes in FC3rc3. Looks like glibc related.
137617  kwireless reports no network when session is resumed or n...
137619  files lose file assocations in FC3T3 and TC3rc3.
137620  Ark chokes on large tar files.
137625  K3b jumps ahead while burning DVD+RW with 2 files. FC3T3...

All of these problems were present in FC3T3 except the kwireless issue.
That is new. 

Here is something funny: everyone says not to use the test releases a
real work machines, but it is only when these releases are used for real
work that that one finds the issue. 

I'm a bit choked about something: I posted issues to the list for a day
and repeatedly was told that the problem was because I UPGRADED from a
stable FC2 to FC3T3.  I was assured that if I did a fresh install all my
problems would disappear.  In fact, none of them did.  Now today I've
heard from several people that they want to hear responses from people
who are specifically UPGRADING.  I'll bet that 50% of the FC3 installs
are going to be UPGRADES, probably half of them from FC2.  I do not
think it was smart for the board to write off my issues as being
"upgrade related" and "solved".  They should have been given
attention
when they existed as a upgraded installation. 


One more thing: I had an installation glitch with FC3rc3 last night.
I'll report it as a bug when I get the info from it later tonight. (I
sent an email from my neighbors machines outlining it and he will email
it to me when he gets home.)  Basically, I got an out of disk space
error when there was lots of disk space.  This was on a fresh install.

[Jef Spaleta]

On Fri, 29 Oct 2004 15:19:23 -0600, Kim Lux <lux(a)diesel-research.com&gt; wrote:
>  I'm a bit choked about something: I posted issues to the list for
> a day
>  and repeatedly was told that the problem was because I UPGRADED from a
>  stable FC2 to FC3T3.   
Step back a second... take a deep breath. 
Please realise that this is an open community forum. The ability to
speak and to give suggestions as to resolutions and workarounds is not
dependant on how knowledge the person giving the suggestions is. Nor
can it be assumed that anyone making suggestions as to workarounds and
resolutions on the list, speaks for the maintainer or developer of the
affected package or for fedora leadership. As valuable as community
input on problems can be, the same community can be exceedingly
unvaluable as well. Real fixes concerning upgrade issues come from
developers and maintainers via bug reports and interacting with the
package maintainers and developers via bugzilla. Take the comments in
this list with a grain of salt, and focus more on the comments from
developers in bugzilla about your upgrade and install bugs.

I will point you to the fedora core list of objectives, for
reassurance that smooth upgrades from core release to core release is
considered important as a matter of fedora core policy. While I
personally avoid doing upgrades and I personally prefer fresh
installs, you shouldn't take my personal preference nor any other
community member's personal preference as a statement of upgrade
policy by fedora core. It's important to be able to seperate random
community input from project policy.


-jef

[Kim Lux]

Thanks for replying. 

Comments below. 

On Fri, 2004-10-29 at 17:44 -0400, Jeff Spaleta wrote:
>  On Fri, 29 Oct 2004 15:19:23 -0600, Kim Lux
> <lux(a)diesel-research.com&gt; wrote:
>  > I'm a bit choked about something: I posted issues to the list for a day
>  > and repeatedly was told that the problem was because I UPGRADED from a
>  > stable FC2 to FC3T3.  
>  
>  Step back a second... take a deep breath.  
OK. 

>  Please realise that this is an open community forum. The ability to
>  speak and to give suggestions as to resolutions and workarounds is not
>  dependant on how knowledge the person giving the suggestions is. Nor
>  can it be assumed that anyone making suggestions as to workarounds and
>  resolutions on the list, speaks for the maintainer or developer of the
>  affected package or for fedora leadership. 
Agreed and understood. 

>   As valuable as community
>  input on problems can be, the same community can be exceedingly
>  unvaluable as well. Real fixes concerning upgrade issues come from
>  developers and maintainers via bug reports and interacting with the
>  package maintainers and developers via bugzilla. Take the comments in
>  this list with a grain of salt, and focus more on the comments from
>  developers in bugzilla about your upgrade and install bugs. 
I learned that today.  Yesterday and today were my first days on the
list.  First of all, I enjoyed myself.  I used to be involved in large
Windows development efforts and this kind of reminded me of that. 

Secondly, I kind of thought, rightly or wrongly, mostly wrongly, that
speaking to the group was like speaking to the developers.  It kind of
is, but on an issue like the sound problem or missing open office file
associations, it isn't.  I should have been reporting those to
bugzilla. 

>  I will point you to the fedora core list of objectives, for
>  reassurance that smooth upgrades from core release to core release is
>  considered important as a matter of fedora core policy. While I
>  personally avoid doing upgrades and I personally prefer fresh
>  installs, you shouldn't take my personal preference nor any other
>  community member's personal preference as a statement of upgrade
>  policy by fedora core. It's important to be able to seperate random
>  community input from project policy. 
I too prefer fresh installs and now that I've got USB drives working so
well (which allow me to easily back up /home)  I probably will do more
fresh installs.  However, when one has a computer loaded with data and
configs from several years, one is reluctant to abandon all that with a
fresh install.  That is the situation with one of our server
computers.  

I also agree that good upgrades should be the goal. 

Here is the rub: several times over the last few days people have come
on to the site and asked if they could update from FC2 to FC3T3 and then
to FC3 Final without "repercussions".  Nobody has come out and said
"yes".  I question why nobody is saying yes ?  Are we not sure that our
upgrade process replaces everything ?  Are we not sure how it handles
already installed config files ?  Shouldn't an upgrade be an upgrade no
matter where it starts from ?

I guess my whole thing is that I think the developers and the group
should take an issue seriously, whether it comes from a fresh install or
from an upgrade. 

Anyway:

a) I enjoyed myself here today (I won't be a regular participant here,
btw.)  I'm only here until kdevelop works...

b) I hope I've contributed.

c) I think FC3 is going to be an awesome product.  There are many good
things that I found while using it over the last week. 

d) I think the open source software effort is in great hands. 





>  
>  -jef
>

On upgrading [Re: FC3rc5]

[Per Bjornsson]

On Fri, 2004-10-29 at 17:44 -0400, Jeff Spaleta wrote:
>  > I will point you to the fedora core list of objectives, for
>  > reassurance that smooth upgrades from core release to core release is
>  > considered important as a matter of fedora core policy. 
<snip>
On Fri, 2004-10-29 at 15:06, Kim Lux wrote:
>  Here is the rub: several times over the last few days people have
> come
>  on to the site and asked if they could update from FC2 to FC3T3 and then
>  to FC3 Final without "repercussions".  Nobody has come out and said
>  "yes".  I question why nobody is saying yes ?  Are we not sure that our
>  upgrade process replaces everything ?  Are we not sure how it handles
>  already installed config files ?  Shouldn't an upgrade be an upgrade no
>  matter where it starts from ? 
Well, that's almost true, but there is a fundamental difference between
upgrading from a stable release to a new release (be it stable or test)
and upgrading from Rawhide or a test release to a stable release. The
difference is that occasionally things slip into rawhide and test
releases that mess up the system in such a way that it's a difficult to
recover.

Just consider the following theoretical situation: Somehow the command
"rm -rf /" gets stuck in the post-uninstall scripts of a package that
hits Rawhide. Oops. It's just not that easy to upgrade from that state,
is it? ;)

Now, Rawhide doesn't contain packages that do stupid things like that,
but that's only because the Red Hat people are too smart to make that
dumb mistake. However, they are not infallible, and but by its nature an
RPM package _can_ have side effects outside of the files owned by the
package. Sometimes the side effects of some change aren't all that
obvious and it might not be all that easy to recover from some packaging
mistakes. The stable releases are tested enough that this kind of goof
generally doesn't slip through, and known thinkos are worked around in
the upgrade process (be it in Anaconda or in the RPM scripts). It's just
not possible to fix things up after every broken package that managed to
hit Rawhide.

Actually, this close to a release nothing that serious should sneak in
so if you install the RC and just update to the final you're very likely
to be in good shape. I actually did that from FC2t2, and it didn't seems
to screw things up that time. But there are really no guarantees.

>  I guess my whole thing is that I think the developers and the group
>  should take an issue seriously, whether it comes from a fresh install or
>  from an upgrade.  
Indeed, and a lot of effort is put into getting upgrades to work.
However, because of the issues with upgrading from broken packages,
issues that only arise when following a Rawhide/test release upgrade
path just aren't practical to deal with.

Cheers,
Per

-- 
Per Bjornsson <perbj(a)stanford.edu&gt;
Ph.D. Candidate, Department of Applied Physics, Stanford University

[Féliciano Matias]

Le vendredi 29 octobre 2004 à 15:19 -0600, Kim Lux a écrit :
>  I'm a bit choked about something: I posted issues to the list for
> a day
>  and repeatedly was told that the problem was because I UPGRADED from a
>  stable FC2 to FC3T3.  I was assured that if I did a fresh install all my
>  problems would disappear.  In fact, none of them did.  Now today I've
>  heard from several people that they want to hear responses from people
>  who are specifically UPGRADING.  I'll bet that 50% of the FC3 installs
>  are going to be UPGRADES, probably half of them from FC2.  I do not
>  think it was smart for the board to write off my issues as being
>  "upgrade related" and "solved".  They should have been given
> attention
>  when they existed as a upgraded installation.  
My "opinion".
Today, Fedora does not support :
- FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) .

I think Fedora should support (this mean fedora should no reply with "do
a fresh install please" for a bug) if 'y' (test) is equal to 3.

Or more realistically :
- FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
should be supported.

[Chuck Anderson]

On Sat, Oct 30, 2004 at 12:05:02AM +0200, Matias Féliciano wrote:
>  My "opinion".
>  Today, Fedora does not support :
>  - FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) . 
I'm pretty sure the former is supported--the goal is always to support
upgrading to what will become FC(x+1).  Of course, what do you mean by
"support"?  Anaconda doesn't outright prevent you from doing any
upgrades, so all upgrades are "supported" in that sense.

>  - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
>  should be supported. 
"supported" how?  These are test releases.  The goal is always to have
upgrades work, especially as we get closer to a release, but there
will be bugs in test releases that cannot be solved always without a
fresh install (unless you know how to fix the issues manually
yourself).  An example of this is package version downgrades.

[Kim Lux]

To me, "support" means that when I ask for advice and tell someone that
my installation was an upgrade they don't laugh at me and tell me to
uninstall and reinstall fresh.  That is a Windows concept, not the sort
of attitude we can have with servers and workstation machines. 


On Fri, 2004-10-29 at 18:22 -0400, Charles R. Anderson wrote:
>  On Sat, Oct 30, 2004 at 12:05:02AM +0200, Matias Féliciano wrote:
>  > My "opinion".
>  > Today, Fedora does not support :
>  > - FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) .
>  
>  I'm pretty sure the former is supported--the goal is always to support
>  upgrading to what will become FC(x+1).  Of course, what do you mean by
>  "support"?  Anaconda doesn't outright prevent you from doing any
>  upgrades, so all upgrades are "supported" in that sense.
>  
>  > - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
>  > should be supported.
>  
>  "supported" how?  These are test releases.  The goal is always to have
>  upgrades work, especially as we get closer to a release, but there
>  will be bugs in test releases that cannot be solved always without a
>  fresh install (unless you know how to fix the issues manually
>  yourself).  An example of this is package version downgrades.
>

[Markku Kolkka]

Kim Lux kirjoitti viestissään (lähetysaika lauantai, 30. 
lokakuuta 2004 01:37):
>  To me, "support" means that when I ask for advice and tell
>  someone that my installation was an upgrade they don't laugh
>  at me and tell me to uninstall and reinstall fresh.  That is a
>  Windows concept, not the sort of attitude we can have with
>  servers and workstation machines. 
You should not install test releases to production servers or 
workstations in the first place. A Fedora Core test release is 
_not_ "the latest bleeding edge distro" for your machine, it's 
meant for TESTING! In order to meaningfully test a piece of 
software the system must be in a known state, so you must be 
prepared to freshly install the test system at any time.

-- 
 Markku Kolkka
 markku.kolkka(a)iki.fi

[Robert L Cochran]

Markku Kolkka wrote:

> Kim Lux kirjoitti viestissään (lähetysaika lauantai, 30. 
> lokakuuta 2004 01:37):
>   
>
> >To me, "support" means that when I ask for advice and tell
> >someone that my installation was an upgrade they don't laugh
> >at me and tell me to uninstall and reinstall fresh.  That is a
> >Windows concept, not the sort of attitude we can have with
> >servers and workstation machines.
> >    
> >
>
> You should not install test releases to production servers or 
> workstations in the first place. A Fedora Core test release is 
> _not_ "the latest bleeding edge distro" for your machine, it's 
> meant for TESTING! In order to meaningfully test a piece of 
> software the system must be in a known state, so you must be 
> prepared to freshly install the test system at any time.
>
>   
>  
Yes I agree. Never take a test release of anything and put it on a 
production or serious machine. Personally I have a bunch of spare hard 
drives that I devote to test releases. I wipe them clean and do a fresh 
install each time.

And I don't expect a 'Test' anything to work right.

Bob Cochran

[Kim Lux]

On Fri, 2004-10-29 at 19:01 -0400, Robert L Cochran wrote:
>  And I don't expect a 'Test' anything to work right.
>  
>  Bob Cochran
>   

OK, then when does it make the transition to working right ?  RC1 is
less than a week old.  Did we go from not expecting anything to work
right (last week) to a stable release (next week) in two weeks ?  I
think we need to change some definitions and/or add some testing time
somewhere.  And by testing I mean real live at work testing.  If Test
candidate aren't for real work and we've only got 2 weeks of release
candidates that are suitable to use for work, then our product only has
2 weeks or real work testing on it.

[Kim Lux]

On Sat, 2004-10-30 at 01:49 +0300, Markku Kolkka wrote:
>  Kim Lux kirjoitti viestissään (lähetysaika lauantai, 30. 
>  lokakuuta 2004 01:37):
>  > To me, "support" means that when I ask for advice and tell
>  > someone that my installation was an upgrade they don't laugh
>  > at me and tell me to uninstall and reinstall fresh.  That is a
>  > Windows concept, not the sort of attitude we can have with
>  > servers and workstation machines.
>  
>  You should not install test releases to production servers or 
>  workstations in the first place. A Fedora Core test release is 
>  _not_ "the latest bleeding edge distro" for your machine, it's 
>  meant for TESTING! In order to meaningfully test a piece of 
>  software the system must be in a known state, so you must be 
>  prepared to freshly install the test system at any time. 
When installed from an upgrade, it is in a known state: it is an
update !  Updates have to work too.

I agree that some testing has to take place from fresh installs to
eliminate variables, but as far as I am concerned, once it hits freeze,
it should be tested on at least a 50-50 mix of fresh and upgrades. 

As far as using test releases for work, it has to be done to get
meaningful usage.  Do you want the first people using FC3 in work
conditions to be the unknowledgable "which button do I push" end users ?
I hope not.

I turned in a number of bug reports today (8), probably because I've
been working on FC3T3 full time for about a week now.  I back everything
up to a USB drive almost hourly and run a tar of /home at the end of
every day.

BTW: If we really feel that FC3rc3 is "final" next week, I'd like to
challenge us to a little test: lets all install FC3 final and use it for
a week or two before advertising it to the public.  Call it "post final
testing".  How many new issues do you think we would turn up in those
two weeks of "real" use ?  Furthermore, some of us will be updating
machines from various other RH/FC OSes.  How many issues do you think
that process will turn up ?   

We used to call this "real world" testing and software isn't ready to
ship until that is done.






>  
>  -- 
>   Markku Kolkka
>   markku.kolkka(a)iki.fi
>

[Jef Spaleta]

On Fri, 29 Oct 2004 17:02:03 -0600, Kim Lux <lux(a)diesel-research.com&gt; wrote:
>  I turned in a number of bug reports today (8), probably because
> I've
>  been working on FC3T3 full time for about a week now.  I back everything
>  up to a USB drive almost hourly and run a tar of /home at the end of
>  every day. 
Maybe you would like using rdiff-backup.

-jef

[Kim Lux]

I'm afraid to do diffs because I'm afraid I won't realize when the base
data is corrupted.  There is a neat tar/find combo in "The Linux
Troubleshooting Bible".

On Fri, 2004-10-29 at 19:11 -0400, Jeff Spaleta wrote:
>  On Fri, 29 Oct 2004 17:02:03 -0600, Kim Lux
> <lux(a)diesel-research.com&gt; wrote:
>  > I turned in a number of bug reports today (8), probably because I've
>  > been working on FC3T3 full time for about a week now.  I back everything
>  > up to a USB drive almost hourly and run a tar of /home at the end of
>  > every day.
>  
>  Maybe you would like using rdiff-backup.
>  
>  -jef
>

[Paul Iadonisi]

On Fri, 2004-10-29 at 18:37, Kim Lux wrote:
>  To me, "support" means that when I ask for advice and tell
> someone that
>  my installation was an upgrade they don't laugh at me and tell me to
>  uninstall and reinstall fresh.  That is a Windows concept, not the sort
>  of attitude we can have with servers and workstation machines.  
  Completely unfair comparison.  Since when has *any* OS vendor
supported upgrades from *test* release to official releases?  Please
name them, and provide pointers to some statistics on how well it worked
in practice.
  Microsoft is guilty of a lot, but if you are saying that Windows betas
or release candidates would not allow upgrades to official releases is
something they should be blamed for, then I have to wonder how much
exposure you've had to operating system development.  In other words,
just because you had to do something undesirable in the Windows world,
doesn't mean it's a Windows specific occurrence.  In this particular
case, it's just the nature of operating system development, FLOSS or
proprietary.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Kim Lux]

I wasn't speaking about an upgrade from a test release to a final
release.  I was talking about an upgrade from a stable release.  

Example: I reported sound issues in FC3T3 yesterday and I was told in no
uncertain terms that I shouldn't expect sound to work from an upgrade.
I was point blank told to install fresh to fix it. (Check the archives.)
I was upgrading from FC2, which had been running very stable for over a
month.

That was the wrong attitude to have.  FC2 was stable and sound was
supposed to work in FC3T3, so the issue should have been taken serious
right then and there.  It wasn't.  It turns out the issue is still
present in FC3rc3 from a fresh install ! 

BTW: I have to say one thing: FC2 was a very stable release.  I don't
think I've seen a machine crash with it yet.  


On Fri, 2004-10-29 at 18:54 -0400, Paul Iadonisi wrote:
>  On Fri, 2004-10-29 at 18:37, Kim Lux wrote:
>  > To me, "support" means that when I ask for advice and tell someone that
>  > my installation was an upgrade they don't laugh at me and tell me to
>  > uninstall and reinstall fresh.  That is a Windows concept, not the sort
>  > of attitude we can have with servers and workstation machines. 
>  
>    Completely unfair comparison.  Since when has *any* OS vendor
>  supported upgrades from *test* release to official releases?  Please
>  name them, and provide pointers to some statistics on how well it worked
>  in practice.
>    Microsoft is guilty of a lot, but if you are saying that Windows betas
>  or release candidates would not allow upgrades to official releases is
>  something they should be blamed for, then I have to wonder how much
>  exposure you've had to operating system development.  In other words,
>  just because you had to do something undesirable in the Windows world,
>  doesn't mean it's a Windows specific occurrence.  In this particular
>  case, it's just the nature of operating system development, FLOSS or
>  proprietary.
>  
>  -- 
>  -Paul Iadonisi
>   Senior System Administrator
>   Red Hat Certified Engineer / Local Linux Lobbyist
>   Ever see a penguin fly?  --  Try Linux.
>   GPL all the way: Sell services, don't lease secrets
>

[Paul Iadonisi]

On Fri, 2004-10-29 at 19:08, Kim Lux wrote:
>  I wasn't speaking about an upgrade from a test release to a
> final
>  release.  I was talking about an upgrade from a stable release.   
  Apologies.  Matias stated that:

>  > - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
>  > should be supported. 
and you didn't specify if you were talking about both cases or just the
first.  My bad for assuming you meant both.
  For the record, I agree that "Do a clean install to fix a problem"
should, in general not be a serious answer.  Even if an upgrade is
broken, a manual fix should be possible and the problem itself should be
consider a bug.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Res]

I think a few people here are reading too depply into his post, sure he 
shouldnt use test versions but I read that  as a upgrade on versions, or 
maybe I used common sense in this approach which some people around here 
forbid.

Go get a coffee

On Fri, 29 Oct 2004, Paul Iadonisi wrote:

>  On Fri, 2004-10-29 at 18:37, Kim Lux wrote:
> > To me, "support" means that when I ask for advice and tell someone that
> > my installation was an upgrade they don't laugh at me and tell me to
> > uninstall and reinstall fresh.  That is a Windows concept, not the sort
> > of attitude we can have with servers and workstation machines.
>
>   Completely unfair comparison.  Since when has *any* OS vendor
>  supported upgrades from *test* release to official releases?  Please
>  name them, and provide pointers to some statistics on how well it worked
>  in practice.
>   Microsoft is guilty of a lot, but if you are saying that Windows betas
>  or release candidates would not allow upgrades to official releases is
>  something they should be blamed for, then I have to wonder how much
>  exposure you've had to operating system development.  In other words,
>  just because you had to do something undesirable in the Windows world,
>  doesn't mean it's a Windows specific occurrence.  In this particular
>  case, it's just the nature of operating system development, FLOSS or
>  proprietary.
>
>  --
>  -Paul Iadonisi
>  Senior System Administrator
>  Red Hat Certified Engineer / Local Linux Lobbyist
>  Ever see a penguin fly?  --  Try Linux.
>  GPL all the way: Sell services, don't lease secrets
>
>  --
>  fedora-test-list mailing list
>  fedora-test-list(a)redhat.com
>  To unsubscribe:
>  http://www.redhat.com/mailman/listinfo/fedora-test-list
>  
-- 
Regards,
Res

[Paul Iadonisi]

On Fri, 2004-10-29 at 20:02, Res wrote:

[snip]

>  Go get a coffee 
  Good idea :-)

/me wonders if asking if he should go for the Gevalia or the Green
Mountain is a smart idea on this list or not ;-)

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Res]

On Fri, 29 Oct 2004, Kim Lux wrote:

>  To me, "support" means that when I ask for advice and tell
> someone that
>  my installation was an upgrade they don't laugh at me and tell me to
>  uninstall and reinstall fresh.  That is a Windows concept, not the sort
>  of attitude we can have with servers and workstation machines. 

Agreed



>  On Fri, 2004-10-29 at 18:22 -0400, Charles R. Anderson wrote:
> > On Sat, Oct 30, 2004 at 12:05:02AM +0200, Matias Féliciano wrote:
> >> My "opinion".
> >> Today, Fedora does not support :
> >> - FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) .
> >
> > I'm pretty sure the former is supported--the goal is always to support
> > upgrading to what will become FC(x+1).  Of course, what do you mean by
> > "support"?  Anaconda doesn't outright prevent you from doing any
> > upgrades, so all upgrades are "supported" in that sense.
> >
> >> - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
> >> should be supported.
> >
> > "supported" how?  These are test releases.  The goal is always to have
> > upgrades work, especially as we get closer to a release, but there
> > will be bugs in test releases that cannot be solved always without a
> > fresh install (unless you know how to fix the issues manually
> > yourself).  An example of this is package version downgrades.
> >
>
>  --
>  fedora-test-list mailing list
>  fedora-test-list(a)redhat.com
>  To unsubscribe:
>  http://www.redhat.com/mailman/listinfo/fedora-test-list
>  
-- 
Regards,
Res

[Féliciano Matias]

Le vendredi 29 octobre 2004 à 18:22 -0400, Charles R. Anderson a écrit :
>  On Sat, Oct 30, 2004 at 12:05:02AM +0200, Matias Féliciano wrote:
>  > My "opinion".
>  > Today, Fedora does not support :
>  > - FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) .
>  
>  I'm pretty sure the former is supported--the goal is always to support
>  upgrading to what will become FC(x+1).  Of course, what do you mean by
>  "support"?  Anaconda doesn't outright prevent you from doing any
>  upgrades, so all upgrades are "supported" in that sense.
>  
>  > - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
>  > should be supported.
>  
>  "supported" how? 
If I can't update from FC3RC1 to FC3 it should be considered as a bug.
If after an update from FC1 to FC3RC1 there still bugs, they should be
considered as confirmed bugs. Fedora should not request to do a fresh
install to confirm the bug.

>    These are test releases. 
I know.

>    The goal is always to have
>  upgrades work, especially as we get closer to a release, but there
>  will be bugs in test releases that cannot be solved always without a
>  fresh install (unless you know how to fix the issues manually
>  yourself).  An example of this is package version downgrades. 
After rc1, fedora should not downgrade package. Fedora is freeze since
Test 3.
I am not requesting for a "strong" support. Information in the release
note to update from FC3RC(x) to FC3 is enough (perhaps with some "rpm -U
--oldpackage :-)).

[Paul Iadonisi]

On Fri, 2004-10-29 at 18:45, Matias Féliciano wrote:

>  If I can't update from FC3RC1 to FC3 it should be considered as a
> bug. 
  Not likely to happen.  Ever.  If you wish to donate development effort
to anaconda and lobby the anaconda developers to incorporate
testrelease->officialrelease (all combinations) specific hacks, then you
are welcome to do that.  I'm sure the current anaconda developers have
plenty enough to do that they are probably not interested in wasting
time on upgrades *from* test releases.

>  If after an update from FC1 to FC3RC1 there still bugs, they should
> be
>  considered as confirmed bugs. Fedora should not request to do a fresh
>  install to confirm the bug. 
  You are correct, here.  However, sometimes is can be quite helpful to
determine whether a problem exists in both upgrades and installs or just
in upgrades.  Sometimes, upgrade problems can be harder to fix.  Even
tricky enough that they can't safely be fix in an automated way,
especially when a choice has to be made that is best made by the user. 
But identifying something as an upgrade problem can narrow down the
problem and provide, via the release notes, a way to mitigate or fix the
problem manually.
  If you've done upgrades of *any* other OS, you must know that almost
all upgrades have some issues.  Usually, they are minor, and often, they
are 'release-noted'.
  But if something gets closed as NOTABUG because it is an upgrade
problem (from official release to test release), then I'd bitch, too. 
WONTFIX, I can deal with, though, if it's due to a engineering resource
issue.

[snip]

>  After rc1, fedora should not downgrade package. Fedora is freeze
> since
>  Test 3. 
  In an ideal world, yes.  But there are times when it's unavoidable.

>  I am not requesting for a "strong" support. Information in
> the release
>  note to update from FC3RC(x) to FC3 is enough (perhaps with some "rpm -U
>  --oldpackage :-)).
>  
>  ______________________________________________________________________ 
  Well, that
makes sense.  But sometimes, as I mentioned above, there
are some things that may need user intervention.  Stuff that anaconda
does to fix some things up, that won't work with interim test release
due to an attempt to integrate something into the release that failed. 
Two examples from the FC2 cycle come to mind that might have caused
problems: evolution 1.5 and selinux.  Someone more intimately involved
with those may be able to confirm or deny if these specifically would
have been a problem for upgrades from interim test releases, but they
are just examples to illustrate a point.  And that is that big
integration efforts sometimes don't succeed in time for release.  And
that makes for messy, error-prone, from-test-release upgrades.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Kim Lux]

I think the whole discussion on testing, what should be considered a
suitable point to start using a release for work and what the rules
<guidelines> about upgrading should be is great.  This is how things
improve: when it gets discussed.

[Féliciano Matias]

Le vendredi 29 octobre 2004 à 19:11 -0400, Paul Iadonisi a écrit :
>  On Fri, 2004-10-29 at 18:45, Matias Féliciano wrote:
>  
>  > If I can't update from FC3RC1 to FC3 it should be considered as a bug.
>  
>    Not likely to happen.  Ever.  If you wish to donate development effort
>  to anaconda and lobby the anaconda developers to incorporate
>  testrelease->officialrelease (all combinations) specific hacks, then you
>  are welcome to do that. 
Good point. "yum/up2date --update" should work.

>    I'm sure the current anaconda developers have
>  plenty enough to do that they are probably not interested in wasting
>  time on upgrades *from* test releases.
>  
>  > If after an update from FC1 to FC3RC1 there still bugs, they should be
>  > considered as confirmed bugs. Fedora should not request to do a fresh
>  > install to confirm the bug.
>  
>    You are correct, here.  However, sometimes is can be quite helpful to
>  determine whether a problem exists in both upgrades and installs or just
>  in upgrades.  Sometimes, upgrade problems can be harder to fix.  Even
>  tricky enough that they can't safely be fix in an automated way,
>  especially when a choice has to be made that is best made by the user. 
>  But identifying something as an upgrade problem can narrow down the
>  problem and provide, via the release notes, a way to mitigate or fix the
>  problem manually.
>    If you've done upgrades of *any* other OS, you must know that almost
>  all upgrades have some issues.  Usually, they are minor, and often, they
>  are 'release-noted'.
>    But if something gets closed as NOTABUG because it is an upgrade
>  problem (from official release to test release), then I'd bitch, too. 
>  WONTFIX, I can deal with, though, if it's due to a engineering resource
>  issue.
>  
>  [snip]
>  
>  > After rc1, fedora should not downgrade package. Fedora is freeze since
>  > Test 3.
>  
>    In an ideal world, yes.  But there are times when it's unavoidable.
>  
>  > I am not requesting for a "strong" support. Information in the release
>  > note to update from FC3RC(x) to FC3 is enough (perhaps with some "rpm -U
>  > --oldpackage :-)).
>  > 
>  > ______________________________________________________________________
>    Well, that makes sense.  But sometimes, as I mentioned above, there
>  are some things that may need user intervention.  Stuff that anaconda
>  does to fix some things up, that won't work with interim test release
>  due to an attempt to integrate something into the release that failed. 
>  Two examples from the FC2 cycle come to mind that might have caused
>  problems: evolution 1.5 and selinux.  
During Release Candidat ? Are you sure ?

>   Someone more intimately involved
>  with those may be able to confirm or deny if these specifically would
>  have been a problem for upgrades from interim test releases, but they
>  are just examples to illustrate a point.  And that is that big
>  integration efforts sometimes don't succeed in time for release.  And
>  that makes for messy, error-prone, from-test-release upgrades.
>  
>  -- 
>  -Paul Iadonisi
>   Senior System Administrator
>   Red Hat Certified Engineer / Local Linux Lobbyist
>   Ever see a penguin fly?  --  Try Linux.
>   GPL all the way: Sell services, don't lease secrets
>

[Paul Iadonisi]

On Fri, 2004-10-29 at 19:30, Matias Féliciano wrote:

[snip]

>  > Two examples from the FC2 cycle come to mind that might have
> caused
>  > problems: evolution 1.5 and selinux. 
>  
>  During Release Candidat ? Are you sure ? 
  Were there even any 'release candidates' during FC2 testing?  I quite
honestly don't remember.  Personally, I don't think it matters, though,
as I don't recall any clear distinction being drawn between 'test' and
'release candidate'.  I'm not saying there *shouldn't* be a distinction,
I just don't remember it being explained (though, admittedly, I haven't
read *every* post ;-)).
  The way I see it is that the development and testing phase of a
release is asymptotic in nature.  We're winding down significantly
during the so-called 'release candidate' stage.  But surprises can and
do happen.  And when they do, feature freeze or not, sometimes it makes
sense to back something out of the release if it can be determined that
the lateness vs. feature removal tradeoff warrants it.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Kim Lux]

I think it does matter when one crosses the line between test and rc.
At some point someone (advanced users) need to start using the release
for real work and I think that rcs are probably the place for that to
happen. 

Software doesn't go from buggy to stable over night and there needs to
be a testing and feedback process in place for it to happen.  I think rc
testing might be the place for that to happen.

[Féliciano Matias]

Le vendredi 29 octobre 2004 à 19:39 -0400, Paul Iadonisi a écrit :
>  On Fri, 2004-10-29 at 19:30, Matias Féliciano wrote:
>  
>  [snip]
>  
>  > > Two examples from the FC2 cycle come to mind that might have caused
>  > > problems: evolution 1.5 and selinux. 
>  > 
>  > During Release Candidat ? Are you sure ?
>  
>    Were there even any 'release candidates' during FC2 testing?  I quite
>  honestly don't remember. 
Me to :-)

[Paul Iadonisi]

On Fri, 2004-10-29 at 18:05, Matias Féliciano wrote:

>  My "opinion".
>  Today, Fedora does not support :
>  - FC(x) => FC(x+1)T(y) and FC(x)T(y) => FC(x) .
>  
>  I think Fedora should support (this mean fedora should no reply with "do
>  a fresh install please" for a bug) if 'y' (test) is equal to 3.
>  
>  Or more realistically :
>  - FCx => FC(x+1)RC(y) and FC(x)RC(y) => FC(x)
>  should be supported.
>  
>  ______________________________________________________________________ 
  Well, if
you want the latter to be supported, then I suggest you step
up to the plate and assist with anaconda development (there are mailing
lists for anaconda specific development) or convince more people to
assist with that development, as the task is likely to be monumental and
full hacks and workarounds specific to each and every test
release/release candidate to official release.  And good luck convincing
the core anaconda developers to spend any amount of time on it.  I know
I wouldn't bother.
  The expectation to be able to upgrade from a test release or a release
candidate to an official release is asking for far too much.  As others
have said, it may work, and it has most of the time, but there usually
are far more important things that need testing and fixing in the
installer, than to fix an upgrade from a possibly badly broken test
release so that you get a working and stable final release.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Gene Heskett]

On Friday 29 October 2004 17:03, Elliot Lee wrote:
> http://fedora.linux.duke.edu/FC3-rc/3/ 
Humm, unknown host from here...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

[Rodolfo J. Paiz]

On Fri, 2004-10-29 at 17:03 -0400, Elliot Lee wrote:
>  In respond to all the queries about "why are the .iso
> timestamps
>  changing", it's because I'm putting the latest RC in the same location as
>  the older ones, so the files do change.
>   
RC5? Did I miss 4 somehow?

Also, wouldn't FC3-rc/4/ and FC3-rc/5/ make sense, rather than putting
everything in the same old directory? More orderly, simpler, clearer?
Disk space is not an issue... since you were clearly willing to clobber
earlier RC's in this case, you could have also deleted them then.

Couldn't get to Duke just now, downloading from
testing.fedora.redhat.com.

Cheers,

-- 
Rodolfo J. Paiz <rpaiz(a)simpaticus.com&gt;

[Dax Kelson]

On Fri, 2004-10-29 at 15:03, Elliot Lee wrote:
>  For your weekend enjoyment, please try:
>  
>  http://fedora.linux.duke.edu/FC3-rc/3/
>  http://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
>  ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
>  rsync://sunsite.mff.cuni.cz/ftp/OS/Linux/Dist/Fedora.RC/3/
>  http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 8pm EDT Oct
> 29.) 
Thanks very much for the rsync'able ISOs.

I was able to turn my FC3rc1 ISOs into FC3r3 ISOs quickly and easily:

rsync -v --stats --progress 
rsync://sunsite.mff.cuni.cz/ftp/OS/Linux/Dist/Fedora.RC/3/i386/iso/FC3-i386-disc?.iso .

SunSITE.MFF.CUni.CZ 2TB archive
 
FC3-i386-disc1.iso
   647069696 100%  338.67kB/s    0:31:05  (1, 25.0% of 4)
FC3-i386-disc2.iso
   668514304 100%  875.45kB/s    0:12:25  (2, 50.0% of 4)
FC3-i386-disc3.iso
   667525120 100%  652.62kB/s    0:16:38  (3, 75.0% of 4)
FC3-i386-disc4.iso
   398049280 100%  726.60kB/s    0:08:54  (4, 100.0% of 4)
 
Number of files: 4
Number of files transferred: 4
Total file size: 2381158400 bytes
Total transferred file size: 2381158400 bytes
Literal data: 437885576 bytes
Matched data: 1943272824 bytes
File list size: 85
Total bytes written: 584958
Total bytes read: 438256342
 
wrote 584958 bytes  read 438256342 bytes  104672.94 bytes/sec
total size is 2381158400  speedup is 5.43

[Robert L Cochran]

Elliot Lee wrote:

> For your weekend enjoyment, please try:
>
> http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 8pm EDT Oct
> 29.)
>
>   
>  
Was the x86_64 stuff synced into this? I get the impression from the 
date stamps that they were not.

Bob

[Jakub Jelinek]

On Sat, Oct 30, 2004 at 09:29:11AM -0400, Robert L Cochran wrote:
>  >For your weekend enjoyment, please try:
>  >
>  >http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 
>  >8pm EDT Oct 29.)
>  >
>  > 
>  >
>  Was the x86_64 stuff synced into this? I get the impression from the 
>  date stamps that they were not. 
Just compare the MD5SUMs file in the x86_64 tree and you'll see that
it has not been synced.
Use the remaining two mirrors for x86_64 for now...

	Jakub

[Andrew W. Donoho]

On Oct 29, 2004, at 16:03, Elliot Lee wrote:
>  This is likely to be the last FC3 release candidate, so please give
> it 
>  all
>  the loving attention you possibly can. It does have fixes for some of 
>  the
>  more serious issues reported here - your efforts are having results. 
>  When
>  testing FC3rc5, things that could use extra-special attention are 
>  upgrades
>  and the kernel. Please make sure to file any showstopper bugs (data 
>  loss
>  or corruption, major install/upgrade failures)  in bugzilla and bring 
>  the
>  bug #'s to our attention. 
Folks,

	I tried to upgrade an FC2 SMP i686 system on an LVM managed disk. The 
system did not update grub properly. When I hand edited grub, the 
system then panicked. I'll report more later after I've had time to dig 
in deeper.

Andrew

____________________________________
Andrew W. Donoho
awd(a)DDG.com, PGP Key ID: 0x81D0F250
[phone] (o), [phone] (m)

[Andrew W. Donoho]

On Oct 30, 2004, at 23:51, Andrew W. Donoho wrote:
>  	I tried to upgrade an FC2 SMP i686 system on an LVM managed disk.
> The 
>  system did not update grub properly. When I hand edited grub, the 
>  system then panicked. I'll report more later after I've had time to 
>  dig in deeper. 

Folks,

	I tried re-updating the system. I got the same error:

After NASH loads:

mount: error 6 mounting ext3
mount: error 2 mounting none
switchroot: mount failed: 22
umount /initrd/dev failed 2
Kernel panic - not syncing: Attempted to kill init!

	I'll keep the system this way for awhile waiting for someone's 
response to these messages. Otherwise I'll scrub the drive and restart 
from scratch. Bear in mind that this system was running fine under FC2.

Andrew


____________________________________
Andrew W. Donoho
awd(a)DDG.com, PGP Key ID: 0x81D0F250
[phone] (o), [phone] (m)

[Andrew W. Donoho]

On Oct 31, 2004, at 11:17, Andrew W. Donoho wrote:
>  On Oct 30, 2004, at 23:51, Andrew W. Donoho wrote:
> > 	I tried to upgrade an FC2 SMP i686 system on an LVM managed disk. 
> > The system did not update grub properly. When I hand edited grub, the 
> > system then panicked. I'll report more later after I've had time to 
> > dig in deeper.
>
>
>  Folks,
>
>  	I tried re-updating the system. I got the same error:
>
>  After NASH loads:
>
>  mount: error 6 mounting ext3
>  mount: error 2 mounting none
>  switchroot: mount failed: 22
>  umount /initrd/dev failed 2
>  Kernel panic - not syncing: Attempted to kill init!
>
>  	I'll keep the system this way for awhile waiting for someone's 
>  response to these messages. Otherwise I'll scrub the drive and restart 
>  from scratch. Bear in mind that this system was running fine under 
>  FC2. 
Folks,

	Does anybody want to know what went wrong upgrading my system from FC2 
-> FC3rc5? I don't know where to start sleuthing to tell you what went 
wrong. The system boots fine with the FC3rc5 Rescue disk. Therefore, I 
can go traipsing through the file system. So a response from someone, 
perhaps FC3rc5 test requester, Mr. Lee, would be appreciated. Or was 
this community testing request hoo-ha just a waste of all of our time?

Andrew
____________________________________
Andrew W. Donoho
awd(a)DDG.com, PGP Key ID: 0x81D0F250
[phone] (o), [phone] (m)

[Elliot Lee]

On Mon, 1 Nov 2004, Andrew W. Donoho wrote:

>  On Oct 31, 2004, at 11:17, Andrew W. Donoho wrote:
>  > On Oct 30, 2004, at 23:51, Andrew W. Donoho wrote:
>  >> 	I tried to upgrade an FC2 SMP i686 system on an LVM managed disk. 
>  >> The system did not update grub properly. When I hand edited grub, the 
>  >> system then panicked. I'll report more later after I've had time to 
>  >> dig in deeper.
>  >
>  >
>  > Folks,
>  >
>  > 	I tried re-updating the system. I got the same error:
>  >
>  > After NASH loads:
>  >
>  > mount: error 6 mounting ext3
>  > mount: error 2 mounting none
>  > switchroot: mount failed: 22
>  > umount /initrd/dev failed 2
>  > Kernel panic - not syncing: Attempted to kill init! 
>  > 	I'll keep the system this way for awhile waiting for
> someone's 
>  > response to these messages. Otherwise I'll scrub the drive and restart 
>  > from scratch. Bear in mind that this system was running fine under 
>  > FC2.
>  
>  Folks,
>  
>  	Does anybody want to know what went wrong upgrading my system from FC2 
>  -> FC3rc5? I don't know where to start sleuthing to tell you what went 
>  wrong. The system boots fine with the FC3rc5 Rescue disk. Therefore, I 
>  can go traipsing through the file system. So a response from someone, 
>  perhaps FC3rc5 test requester, Mr. Lee, would be appreciated. Or was 
>  this community testing request hoo-ha just a waste of all of our time? 
We'd need more information on the problem, and some sort of diagnosis,
before a fix would be possible. We also need a report in bugzilla with
these details.

If it's not in bugzilla, it's not a bug, :)
-- Elliot

[Andrew W. Donoho]

On Nov 1, 2004, at 10:41, Elliot Lee wrote:

>  On Mon, 1 Nov 2004, Andrew W. Donoho wrote:
>
> > On Oct 31, 2004, at 11:17, Andrew W. Donoho wrote:
> >> On Oct 30, 2004, at 23:51, Andrew W. Donoho wrote:
> >>> 	I tried to upgrade an FC2 SMP i686 system on an LVM managed disk.
> >>> The system did not update grub properly. When I hand edited grub, 
> >>> the
> >>> system then panicked. I'll report more later after I've had time to
> >>> dig in deeper.
> >>
> >>
> >> Folks,
> >>
> >> 	I tried re-updating the system. I got the same error:
> >>
> >> After NASH loads:
> >>
> >> mount: error 6 mounting ext3
> >> mount: error 2 mounting none
> >> switchroot: mount failed: 22
> >> umount /initrd/dev failed 2
> >> Kernel panic - not syncing: Attempted to kill init!
>
> >> 	I'll keep the system this way for awhile waiting for someone's
> >> response to these messages. Otherwise I'll scrub the drive and 
> >> restart
> >> from scratch. Bear in mind that this system was running fine under
> >> FC2.
> >
> > Folks,
> >
> > 	Does anybody want to know what went wrong upgrading my system from 
> > FC2
> > -> FC3rc5? I don't know where to start sleuthing to tell you what went
> > wrong. The system boots fine with the FC3rc5 Rescue disk. Therefore, I
> > can go traipsing through the file system. So a response from someone,
> > perhaps FC3rc5 test requester, Mr. Lee, would be appreciated. Or was
> > this community testing request hoo-ha just a waste of all of our time?
>
>  We'd need more information on the problem, and some sort of diagnosis,
>  before a fix would be possible. We also need a report in bugzilla with
>  these details.
>
>  If it's not in bugzilla, it's not a bug, :) 

OK, the above is repeated in Bugzilla #: 137807. I would be happy to 
get any log/config file you need off of the system. If the rescue CD 
supports SSH, you could even log into the machine as it has its own 
public IP address.

Andrew

____________________________________
Andrew W. Donoho
awd(a)DDG.com, PGP Key ID: 0x81D0F250
[phone] (o), [phone] (m)

[Michael Mansour]

Hi,

>  >>> On Oct 30, 2004, at 23:51, Andrew W. Donoho
>  wrote:
>  >>>> 	I tried to upgrade an FC2 SMP i686 system on
>  an LVM managed disk.
>  >>>> The system did not update grub properly. When I
>  hand edited grub, 
>  >>>> the
>  >>>> system then panicked. I'll report more later
>  after I've had time to
>  >>>> dig in deeper.
>  >>>
>  >>>
>  >>> Folks,
>  >>>
>  >>> 	I tried re-updating the system. I got the same
>  error:
>  >>>
>  >>> After NASH loads:
>  >>>
>  >>> mount: error 6 mounting ext3
>  >>> mount: error 2 mounting none
>  >>> switchroot: mount failed: 22
>  >>> umount /initrd/dev failed 2
>  >>> Kernel panic - not syncing: Attempted to kill
>  init!
>  >
>  >>> 	I'll keep the system this way for awhile
>  waiting for someone's
>  >>> response to these messages. Otherwise I'll scrub
>  the drive and 
>  >>> restart
>  >>> from scratch. Bear in mind that this system was
>  running fine under
>  >>> FC2.
>  >>
>  >> Folks,
>  >>
>  >> 	Does anybody want to know what went wrong
>  upgrading my system from 
>  >> FC2
>  >> -> FC3rc5? I don't know where to start sleuthing
>  to tell you what went
>  >> wrong. The system boots fine with the FC3rc5
>  Rescue disk. Therefore, I
>  >> can go traipsing through the file system. So a
>  response from someone,
>  >> perhaps FC3rc5 test requester, Mr. Lee, would be
>  appreciated. Or was
>  >> this community testing request hoo-ha just a
>  waste of all of our time?
>  >
>  > We'd need more information on the problem, and
>  some sort of diagnosis,
>  > before a fix would be possible. We also need a
>  report in bugzilla with
>  > these details.
>  >
>  > If it's not in bugzilla, it's not a bug, :)
>  
>  
>  OK, the above is repeated in Bugzilla #: 137807. I
>  would be happy to 
>  get any log/config file you need off of the system.
>  If the rescue CD 
>  supports SSH, you could even log into the machine as
>  it has its own 
>  public IP address.
>  
>  Andrew 
Does the rescue CD support SSH? I tried rescue mode
from FC3T3 disc 1 and it didn't have support for it.
Although I could have used since the problem we were
troubleshooting on the server could have been looked
at by the authors.

Michael.

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

[Andrew W. Donoho]

On Oct 29, 2004, at 16:03, Elliot Lee wrote:
>  This is likely to be the last FC3 release candidate, so please give
> it 
>  all
>  the loving attention you possibly can. It does have fixes for some of 
>  the
>  more serious issues reported here - your efforts are having results. 
>  When
>  testing FC3rc5, things that could use extra-special attention are 
>  upgrades
>  and the kernel. Please make sure to file any showstopper bugs (data 
>  loss
>  or corruption, major install/upgrade failures)  in bugzilla and bring 
>  the
>  bug #'s to our attention. 
Elliot and other developers,

	I did discover an upgrade problem that has been resolved with the 
appropriate engineer, <mailto:[e-mail]>, via Bugzilla, [Bug 
137807]. That said, since this was a "dead in the water" upgrade issue 
involving LVM, I was wondering if you guys are planning on an FC3rc6 
release?

Andrew

____________________________________
Andrew W. Donoho
awd(a)DDG.com, PGP Key ID: 0x81D0F250
[phone] (o), [phone] (m)

FC3rc5 : how to regen 2.6.9-1.649 kernel tree from kernel-2.6.9-1.649.src.rpm

[ron flory]

  This may be covered in a FAQ, README or DOC somewhere, but
I've not been able to find it...

  If FC3T3rc5 was not intended to contain the necessary data to
reconstruct the source tree, then i apologize in advance...

  I disagree with moving the kernel-source RPM from the install
disks to the SRPMS anyway, but kernel-2.6.9-1.649.src.rpm does
not appear to contain data necessary to reconstruct the kernel
source tree as shipped in the FC3T3rc5 - its not even close.

- This SRPM contains many patch files, but none of them
   result in a 2.6.9-1.649 kernel source tree.
- There is no README.
- There are two different 'final' tar.bz2 patch sets- which is
   real?
- Some of the patches appear to be against very old versions
   of the kernel, not against 2.6.9 .
- this RPM contains the original 2.6.9 tarfile as found
   on kernel.org.
- applying the 'final' patches against the 2.6.9 source tree
   results in several warnings and 'reversed' patches.
- I would suggest providing a script to install/patch the
   kernel.

  There needs to be an easy-to install kernel-source RPM (like
there used to be under RHL) for newbies, i.e., one that installs
an exact image of the kernel sources in /usr/src/linux-x.y.z-n.mmm
without requiring the user to guess which patches to install, or
even how to apply these patches, otherwise the same 'how do I
reconstruct the kernel sources' questions will appear over
and over and over....

  Aside from this, FC3T3c5 looks pretty good.

ron

FC3rc5 : how to regen 2.6.9-1.649 kernel tree from kernel-2.6.9-1.649.src.rpm

[Arjan van de Ven]

>  - I would suggest providing a script to install/patch the
>     kernel. 
like.. the spec file ?
which you then can execute with "rpmbuild -bp --target noarch
kernel-2.6.spec"

FC3rc5 : how to regen 2.6.9-1.649 kernel tree from kernel-2.6.9-1.649.src.rpm

[William Hooper]

RON FLORY said:
>  This may be covered in a FAQ, README or DOC somewhere, but
>  I've not been able to find it... 
Read the release notes.

-- 
William Hooper

FC3rc5 : how to regen 2.6.9-1.649 kernel tree from kernel-2.6.9-1.649.src.rpm

[ron flory]

William Hooper wrote:
>  RON FLORY said:
>  
> >This may be covered in a FAQ, README or DOC somewhere, but
> >I've not been able to find it...
>  
>  
>  Read the release notes. 
  $@&!, i read them and missed it 3 times (my fault)...  I'm
used to building released sources from kernel.org, never the RPM.

  1. The specified filename in the release notes is incorrect
     ( kernel.spec --> kernel-2.6.spec )
  2. There needs to be a hint of supported arch's in the release
     notes.
  3. supplying a value of 'all_x86', (which i had to guess at by
     reviewing the specs file), assuming it was the lowest-common
     denominator for x86 tree failed.  'i686' seems to work.
  4. placing the kernel tree in a non-standard location will cause
     some apps to not compile, why isn't it moved to /usr/src/ ?
  5. kernel version is 2.6.9-prep, not 2.6.9-1.649.  is this right?

ron

FC3rc5 : how to regen 2.6.9-1.649 kernel tree from kernel-2.6.9-1.649.src.rpm

[Chuck Anderson]

On Fri, Nov 05, 2004 at 09:50:49AM -0600, RON FLORY wrote:
>   4. placing the kernel tree in a non-standard location will cause
>      some apps to not compile, why isn't it moved to /usr/src/ ? 
/usr/src isn't the correct/standard location for programs to be
compiling against, and hasn't been for years.  The correct location
is:

/lib/modules/`uname-r`/build/include

Note that user space programs should NEVER use kernel headers, either
in /usr/src or in /lib/modules.  Only kernel modules should ever need
to use /lib/modules.