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
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
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.
On Fri, 29 Oct 2004 15:19:23 -0600, Kim Lux lux@diesel-research.com 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
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@diesel-research.com 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 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
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.
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.
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.
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 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
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.
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@iki.fi
On Fri, 29 Oct 2004 17:02:03 -0600, Kim Lux lux@diesel-research.com 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
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@diesel-research.com 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
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.
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
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.
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@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
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 ;-)
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@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
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 :-)).
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.
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.
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
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.
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.
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 :-)
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.
On Friday 29 October 2004 17:03, Elliot Lee wrote:
Humm, unknown host from here...
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,
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
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
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
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@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
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@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
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@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
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
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@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
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
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:katzj@redhat.com, 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@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
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
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
On Fri, Nov 05, 2004 at 09:50:49AM -0600, RON FLORY wrote:
- 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.
-
Andrew W. Donoho -
Arjan van de Ven -
Chuck Anderson -
Dax Kelson -
Elliot Lee -
Féliciano Matias -
Gene Heskett -
Jakub Jelinek -
Jef Spaleta -
Kim Lux -
Markku Kolkka -
Michael Mansour -
Paul Iadonisi -
Per Bjornsson -
Res -
Robert L Cochran -
Rodolfo J. Paiz -
ron flory -
William Hooper