The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
* I run Majordomo2 which is a great mailinglist manager. Not all my mail is getting delivered and I'm getting messages with blank bodies. No one else seems to be having this problem. I'm not sure what I can do now. It could be perl, or worse, it could be gcc which was used to build perl.
* I have a Palm IIIc connected on a serial port. pilot-link woks ok but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) are all unable to connect to the device. No one knows why. I suspect gcc.
* I have a Dell Dimension 4700 at work. The upgrade went fine from Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
Am Montag, den 11.07.2005, 19:39 -0400 schrieb Steven W. Orr:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
- I run Majordomo2 which is a great mailinglist manager. Not all my mail is getting delivered and I'm getting messages with blank bodies. No one else seems to be having this problem. I'm not sure what I can do now. It could be perl, or worse, it could be gcc which was used to build perl.
I doub't that gcc has something to do with it.
- I have a Palm IIIc connected on a serial port. pilot-link woks ok but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) are all unable to connect to the device. No one knows why. I suspect gcc.
I suspect either Selinux or udev. Btw last week was a bank robery. Nobody knows who is responsible. I suspect gcc also for that.
What does STRACE tell you? What GDB?
- I have a Dell Dimension 4700 at work. The upgrade went fine from Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
Sure that is a major critical bug! Let us all burn our FC4 cds.
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
Come on, be specific. I cannot use my Washing Machine at all. So now let us blame Fedora for it.
What does /var/log/audit/audit.log tell you? Is Selinux offline?
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
I did a log of swearing of FC4 myself, when I was running into random bad behavior of various config tools. What happens when you boot with enforcing=0? That disables selinux. It cured all my problems. If that works, then selinux should be re-instated, with the right policies, etc.
Am Montag, den 11.07.2005, 19:39 -0400 schrieb Steven W. Orr:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
- I run Majordomo2 which is a great mailinglist manager. Not all my mail is getting delivered and I'm getting messages with blank bodies. No one else seems to be having this problem. I'm not sure what I can do now. It could be perl, or worse, it could be gcc which was used to build perl.
=I doubt that gcc has something to do with it.
- I have a Palm IIIc connected on a serial port. pilot-link woks ok but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) are all unable to connect to the device. No one knows why. I suspect gcc.
=I suspect either Selinux or udev. Btw last week was a bank robery. =Nobody knows who is responsible. I suspect gcc also for that.
Look, I'm doing the best I can. Things are badly broken and it causes a huge amount of trouble.
=What does STRACE tell you? What GDB?
Absolutely nothing.
Selinux is disabled. udev is not the culprit. I'm on a serial port and the udev entry works fine for creating my symlink to /dev/pilot
- I have a Dell Dimension 4700 at work. The upgrade went fine from Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
=Sure that is a major critical bug! Let us all burn our FC4 cds.
Depends if it's your machine or not.
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
=Come on, be specific. I cannot use my Washing Machine at all. So now let =us blame Fedora for it.
Tell me what you need and I will be happy to supply it.
=What does /var/log/audit/audit.log tell you? Is Selinux offline?
523 > ls -l /var/log/audit/audit.log ls: /var/log/audit/audit.log: No such file or directory 524 >
526 > selinuxenabled 527 > echo $? 1 528> (even though the manpage for selinuxenabled says to expect a *minus* 256. :-)
Am Montag, den 11.07.2005, 20:22 -0400 schrieb Steven W. Orr:
What does STRACE tell you? What GDB?
Absolutely nothing.
I cannot believe that.
Selinux is disabled. udev is not the culprit. I'm on a serial port and the udev entry works fine for creating my symlink to /dev/pilot
Ok, can you do an id $youruser and check if this user belongs to the group uucp?
Depends if it's your machine or not.
I have several machines with FC4. And did not notice any problems.
Tell me what you need and I will be happy to supply it.
[user@yourpc] script <enter> [user@yourpc] strace jpilot [user@yourpc] lots of output .... [user@yourpc] exit
you should have a file named typescript, let us see that.
When I upgraded (installed fresh) Fedora Core 4 I immediately noticed that my teeth were whiter, my abs were tighter and more sexy, and my party bashes had great-looking beer-commercial women at them.
Seriously, this release has given me about half the problems that "3" did. Of course I know a lot more now than I did then and that could have something to do with it. I would advise sticking with it and working out the problems. You will gain a TON of (marketable) knowledge in a really short amount of time.
Patrick
I'm just a linux n00b, but.. I test drove FC3 when figuring out what distro to go with and moved on. Came around to FC4 after 10 or so distros and am sticking with it for the foreseable future.
-j Yes, Windows is familiar.. and you know what they say "familiarity breeds contempt."
--- Patrick list_patrick@complete-office-installations.com wrote:
When I upgraded (installed fresh) Fedora Core 4 I immediately noticed that my teeth were whiter, my abs were tighter and more sexy, and my party bashes had great-looking beer-commercial women at them.
Seriously, this release has given me about half the problems that "3" did. Of course I know a lot more now than I did then and that could have something to do with it. I would advise sticking with it and working out the problems. You will gain a TON of (marketable) knowledge in a really short amount of time.
Patrick
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
____________________________________________________ Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/
Okay, I think the "don't install on production systems" point has been made loud enough. Let's not forget that there is no magic line which separates production servers from playboxes. Some uses will be in that gray area, where it's not quite production or mission critical, but it still gives you grief if it breaks. There's a whole continuous range of "importance", and that's the call of the user/administrator, which I'm sure Steven is well aware of now.
Regardless, FC4 is not working for him. He may have started the thread wrong by coming out claiming all of FC4 was junk, but for him at least, it is. Anyway, it's safe to say that during any OS release upgrade there will be some systems which fail. Fedora is certainly not exempt. But I've also seen upgrades of major high-priced proprietary Unixes fail occasionally, and certainly many other Linux distros also have occasional upgrade failures. FC may be slightly worse than others because of it's pace, but it's not exactly fair to just say "go away and use something else, you should've known better".
What we on the Fedora list (many of whom participate in the Fedora process) need to do is to ignore the poster's emotional overreaction and get down to helping him solve the problem.
* * *
Anyway, Steven, if this is truly critical and you can't wait to figure this out, you may want to back up files and reinstall FC3. There is no way to downgrade that I know of. If you had partitioned your disks with LVM you may be able to just install a partial FC3 alongside which you let you run until the FC4 issues are figured out.
About the Dell systems...yes, Dell has a long history of producing BIOSes that are very un-Linux friendly, especially with some of the video drivers. The newer Linux drivers like i810 as you've found seem to deal with them better on some models. Ultimately this is most likely a Dell issue as they have flawed BIOSes, but as you've done your homework on bugzilla, it seems you have resolved that problem.
Turning off selinux was the first step for your other problems. At some point you'll want to turn it back on in non-enforcing mode to see what would have broke before it actually does.
I don't know Majordomo (I'm a Python and hence Mailman user), but there should be a way to enable some sort of Perl debugging in it. Perhaps if you describe what the problem actually is better. Is it random or repeatable. Does it depend on any of the inputs, or on the recipient addresses? Are the mail headers intact? Can you capture the messages in the sendmail queue (or are you using something other than sendmail?)? If you're experienced enough, perhaps you can download the official Majordomo code itself and try building it anew.
And I think the output of strace may still have some useful information in it.
Deron Meranda
Actually... My FC3 to FC4 upgrade was pretty painless and other than a few minor things...everything has been running pretty stable for me.
On Mon, 2005-07-11 at 19:39 -0400, Steven W. Orr wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
Stefan Held wrote:
Am Montag, den 11.07.2005, 19:39 -0400 schrieb Steven W. Orr:
[snip]
I suspect either Selinux or udev. Btw last week was a bank robery. Nobody knows who is responsible. I suspect gcc also for that.
Sarcasm like this really doesn't look well on the one who uses it.
BTW, I had considered upgrading to FC4 from FC2, but reconsidered after watching here for about a month.
I don't like this guy's tone much, either. But I decided against FC4 for basically the reasons he gave.
[snip]
Come on, be specific. I cannot use my Washing Machine at all. So now let us blame Fedora for it.
Makes you look sillier than him.
FC4 looks too unstable for me at present, as well. I'll wait until some dust settles. But I'm sure things will get worked out.
Mike
Upgrade? What type of upgrade did you perform, a full install or a true upgrade from a previous version? Were your settings saved in a separate partition?
On Monday 11 July 2005 16:39, Steven W. Orr wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
- I run Majordomo2 which is a great mailinglist manager. Not all my mail is getting delivered and I'm getting messages with blank bodies. No one else seems to be having this problem. I'm not sure what I can do now. It could be perl, or worse, it could be gcc which was used to build perl.
If no one else seems to be having this problem then the problem is probably not with Fedora but with the settings not being correct.
- I have a Palm IIIc connected on a serial port. pilot-link woks ok but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) are all unable to connect to the device. No one knows why. I suspect gcc.
No one knows why? Have you been following this list for any length of time? A couple of recent messages had very useful information to help solve this problem.
- I have a Dell Dimension 4700 at work. The upgrade went fine from Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
Using drivers from previous versions often causes problems. Many things get changed between version which is why I recommend a fresh install (saving all the /home directories as separate, unformatted partitions).
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
-- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
This one time, at band camp, "Steven W. Orr" steveo@syslang.net wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine
Gee, and it all works so well for me... maybe I should uninstall it
On Mon, 11 Jul 2005, Steven W. Orr wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
I agree, so much so we reinstalled the previous FC from backup and are not going to update, all updates wil be done manually from kernel org and respective programs distro points, FC4 is ajoke, even most the install CD's fail until you make it in an error condition then running install, X is screwed, with fonts, video drivers that work on ealier versions dont in FC4, the list goes on and on and on...
- I have a Dell Dimension 4700 at work. The upgrade went fine from
Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here:
lol my previous that used this driver wont work, only the vesa driver does , hey maybe they renamed them backto front LOL (j/k but might as well hey haha)
I've seen unstable beta versions far superior and more stable :)
Kevin Waterson wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine
Gee, and it all works so well for me... maybe I should uninstall it
This is a rather silly discussion.
So FC-4 works fine for you. You are lucky.
The OP was over the top with his reaction to what seem like 3 isolated problems. However, anyone with problems when upgrading Fedora deserves to be listened to.
Since there are no statistics (perhaps there should be?) it is hard to judge, but my impression is that more people had more problems with FC-4 than with previous upgrades.
Unfortunately I have little confidence that the Fedora team are paying sufficient attention to this.
From my reading (admittedly very superficial) of development lists
there is too much time and energy spent on new developments, and not enough on making sure the basic installation is rock solid. [Making sure Xorg works on all systems is far more important than getting 3D graphics in place, IMHO.]
Also the bugzilla system needs an overhaul. It is absurdly complicated, and many bugs do not seem to be looked at at all. (I posted one about a problem installing on my Sony Picturebook C1VFK, with a complete error listing, but as far as I can see it went into a black hole. I'd suggest that all bugs should at least be assigned to someone, and the poster told of this, within a reasonable time, say 2 weeks.)
I also think that it should be possible normally to upgrade from the Fedora test versions (it probably is, but one is warned not to try it). My impression is that only a small proportion of users are trying the test versions, probably for this reason. This is particularly the case with people who have one, perhaps aged, box, who are exactly the people likely to get problems.
Hi
Unfortunately I have little confidence that the Fedora team are paying sufficient attention to this.
From my reading (admittedly very superficial) of development lists
there is too much time and energy spent on new developments, and not enough on making sure the basic installation is rock solid. [Making sure Xorg works on all systems is far more important than getting 3D graphics in place, IMHO.]
Fedora development list is about new development (duh!) so its not surprising that the discussion there is mostly about what happens on the development tree. For people working on 3D systems, getting them working is their top priority and the only reason Xorg could be remotely usable for them. So examples like that are biased. Installer related discussions happens on the anaconda list. If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
regards Rahul
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla, at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940 ======================================= Bugzilla Bug 160940 ? anaconda bombs out on Sony Picturebook while "Reading package information" =======================================
No, no progress. Might as well have written to the Pope.
Only response I got was to ask for the Traceback, which I had already given, in full, in the original report.
I posted another bugzilla on the kdesktop site, https://bugs.freedesktop.org/show_bug.cgi?id=718. Again, no response except from others saying they had the same problem. Someone wrote to me with a patch, which worked (after re-compiling xorg). I reported this, but got no response. I wrote to half-a-dozen people mentioned in the source, but none replied.
Then, about a year later the patch was applied, again without mention in the bugzilla.
So I'm afraid my experience is that posting a bugzilla is unlikely to be a rewarding experience.
Also the way the bugzilla site is arranged is like something out of the ark. Someone ought to ask themselves, "Is this the best way of organising a bug-reporting site? Will people find it simple to report bugs? Will people find it simple to search through the site."
As far as I am concerned, the answer is "No. No. No."
Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla,
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
regards Rahul
Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla, at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940 ======================================= Bugzilla Bug 160940 ? anaconda bombs out on Sony Picturebook while "Reading package information" =======================================
No, no progress. Might as well have written to the Pope.
So, you have complaints about the Pope as well? Or at least it seems so.
[snip]
Also the way the bugzilla site is arranged is like something out of the ark. Someone ought to ask themselves, "Is this the best way of organising a bug-reporting site? Will people find it simple to report bugs? Will people find it simple to search through the site."
As far as I am concerned, the answer is "No. No. No."
Yes, I have found bugzilla difficult to navigate.
If you really are having such a terrible time, then you probably need not to use FC4. The decision to put it on your machine was made by one man. That same man has decided to let FC4 remain on his machine. That man is the only one who can put something else on it.
Mike
Dear Group,
If I post the contents of an E-mail, I sent to LXF (Linux Format Magazine) Letters, it would take of 3 Full Pages, on a 17" Monitor, and it would only be about Half the problems I had, trying to get a Current copy of Fedora Core, on to My PIII 600 Mhz Test Server. And I was starting with FC1, but I finally got FC4 to start, and Reboot.
It has been running, almost Non-stop, for 18 days. Now I realize that although I prefer the Gnome GUI, I should have installed it as a Text-based Install. Because I can't seem to install any additional software, like Exim 4.51, Rootkit Hunter, ClamAV, etc., onto the computer.
My experience goes back to a 4 Year Degree, in Management Information Systems, I received in 1977, from Mcgill University, in Montreal, Quebec, CANADA. That was the Good Olde Days when We entered everything by Punch Card. Alright, I wait a minute, till You all stop laughing.
Everybody finished now?
Thank You.
I may just start over and stick to Text-based, and stop at FC3. If I'm reading My System Log properly, somebody has been trying to hack My Root Account. SELinux is running, and I don't know if the problems that You are all talking about, may be adding to My Problems, but I am testing Fedora Core, on My server, for a Website, and will use CentOS 4.x, for My Workstations, and I don't need the problems.
So, that's My useless bit of contribution, for this Column.
Michael Fiddes (Determined)
On 7/12/05, Rahul Sundaram sundaram@redhat.com wrote:
Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla,
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
regards Rahul
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
On Tue, 2005-07-12 at 10:13, Michael wrote:
If I post the contents of an E-mail, I sent to LXF (Linux Format Magazine) Letters, it would take of 3 Full Pages, on a 17" Monitor, and it would only be about Half the problems I had, trying to get a Current copy of Fedora Core, on to My PIII 600 Mhz Test Server. And I was starting with FC1, but I finally got FC4 to start, and Reboot.
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
It has been running, almost Non-stop, for 18 days. Now I realize that although I prefer the Gnome GUI, I should have installed it as a Text-based Install. Because I can't seem to install any additional software, like Exim 4.51, Rootkit Hunter, ClamAV, etc., onto the computer.
Please explain how you think a GUI is stopping you from installing software. Open a terminal and you can do anything you would do in text mode.
My experience goes back to a 4 Year Degree, in Management Information Systems, I received in 1977, from Mcgill University, in Montreal, Quebec, CANADA. That was the Good Olde Days when We entered everything by Punch Card. Alright, I wait a minute, till You all stop laughing.
Everybody finished now?
Times have changed. Computers are a lot more fun now.
I may just start over and stick to Text-based, and stop at FC3. If I'm reading My System Log properly, somebody has been trying to hack My Root Account.
If you are on the internet and have ssh running, of course someone is trying to hack your root account - probably many people. Turn off ssh if you don't need it yourself, and use good passwords. This has nothing to do with the OS version you are running.
SELinux is running, and I don't know if the problems that You are all talking about, may be adding to My Problems, but I am testing Fedora Core, on My server, for a Website, and will use CentOS 4.x, for My Workstations, and I don't need the problems.
That seems backwards. Most people would want RHEL/CentOS for the server because Linux server apps have been feature-complete for ages and there is not much reason to upgrade frequently. However, the Linux desktop apps are evolving rapidly so you do see some good things from the Fedora fast release cycle.
Steven W. Orr wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
I've upgraded (well, fresh installs) three different machines from FC3->FC4 lately, and I have the opposite opinion. FC4 was smoother (less problems) than any of the previous cores I've tried (FC1 was the first), on all my machines (one of which is a server/gateway running DNS, mail, DHCPD, databases, etc). Gnome is faster and cleaner, too ! The only thing that bothers me a bit is that the latest kernels have been buggy (for instance the CD/DVD insert=>panic problem on the latest update, and the one before that which wouldn't boot at all on my laptop).
GCC4 has given me less troubles than I would've ever imagined. For things that don't work with GCC4 yet, there's always compat-gcc-32.
I have no problem in recommending FC4 to anyone. Perhaps I've been lucky, who knows.
Øyvind.
Les Mikesell wrote:
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
That's the approach I've decided to take. I may upgrade from FC2 to FC3 soon.
[snip... used to use punched cards]
Times have changed. Computers are a lot more fun now.
Umm, I'm not so sure. I really didn't enjoy punching cards, myself. OTOH, some of the best fun I've had is using some really limited stuff. Especially embedded, with limited I/O and debug facilities.
[snip]
Mike
Mike McCarty wrote:
Umm, I'm not so sure. I really didn't enjoy punching cards, myself. OTOH, some of the best fun I've had is using some really limited stuff.
Yeah, like JCL.
On Tue, 12 Jul 2005 13:56:56 -0500, Mike McCarty wrote:
Les Mikesell wrote:
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
That's the approach I've decided to take. I may upgrade from FC2 to FC3 soon.
It's the approach I used to take as a total sub-technoid; and it was OK, I guess -- but I did twelve or fifteen installs on five machines over about three years, and all the keeping up got pretty old pretty fast.
Then one of the first people I asked suggested the opposite tack: start a new release near the outset, and count on keeping it clear to legacy. So, like Øyvind Stegard in this thread, but with what must be far less expertise, I've now done upgrades from FC1, 2, and 3 -- and am glad, so far.
I do have a problem with one erstwhile FC1 machine, but that was my fault for doing something unusually stupid while reacting to a power failure that hit just as an install was finishing; it seems unrelated to Fedora, and I'll look for help elsewhere.
beartooth wrote:
On Tue, 12 Jul 2005 13:56:56 -0500, Mike McCarty wrote:
Les Mikesell wrote:
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
That's the approach I've decided to take. I may upgrade from FC2 to FC3 soon.
It's the approach I used to take as a total sub-technoid; and it was OK, I guess -- but I did twelve or fifteen installs on five machines over about three years, and all the keeping up got pretty old pretty fast.
Why do that many installs? One doesn't have to go stepwise, you know. I may wait for FC4 to settle down in, say, 6 mo and then go for FC4.
Mike
On Tue, 2005-07-12 at 14:14, beartooth wrote:
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
It's the approach I used to take as a total sub-technoid; and it was OK, I guess -- but I did twelve or fifteen installs on five machines over about three years, and all the keeping up got pretty old pretty fast.
Then one of the first people I asked suggested the opposite tack: start a new release near the outset, and count on keeping it clear to legacy. So, like Øyvind Stegard in this thread, but with what must be far less expertise, I've now done upgrades from FC1, 2, and 3 -- and am glad, so far.
That's reasonable also if the machine isn't critical or if you already have 'plan b' for what to do if some needed program doesn't work or a device driver for your hardware is missing or fails.
I do have a problem with one erstwhile FC1 machine, but that was my fault for doing something unusually stupid while reacting to a power failure that hit just as an install was finishing; it seems unrelated to Fedora, and I'll look for help elsewhere.
It's a good idea to learn how to save and reinstall your own files and changes so instead of doing upgrades you can do clean installs of each new version.
On Mon, 2005-11-07 at 23:40 -0400, Deron Meranda wrote:
Okay, I think the "don't install on production systems" point has been made loud enough. Let's not forget that there is no magic line which separates production servers from playboxes. Some uses will be in that gray area, where it's not quite production or mission critical, but it still gives you grief if it breaks. There's a whole continuous range of "importance", and that's the call of the user/administrator, which I'm sure Steven is well aware of now.
People are supposed to use FC to help work out problems before RHEL is updated. If they don't run it in Real World situations it does no good to RHEL.
This whole project is about testing in the real world to make sure all the software is as good as possible for mainstream use so it can be implemented in a future version RHEL, but then you get steam rolled when you use it and when a problem that needs to be fixed.
Regardless, FC4 is not working for him. He may have started the thread wrong by coming out claiming all of FC4 was junk, but for him at least, it is. Anyway, it's safe to say that during any OS release upgrade there will be some systems which fail. Fedora is certainly not exempt. But I've also seen upgrades of major high-priced proprietary Unixes fail occasionally, and certainly many other Linux distros also have occasional upgrade failures. FC may be slightly worse than others because of it's pace, but it's not exactly fair to just say "go away and use something else, you should've known better".
I'll agree his subject is inflammatory. When all you ever hear is that everything works perfectly, except in your unusual case, your patience starts to run a little thin, and that's when people do things that would otherwise be uncharacteristic.
What we on the Fedora list (many of whom participate in the Fedora process) need to do is to ignore the poster's emotional overreaction and get down to helping him solve the problem.
Absolutely, and I would like to add that the developers should lead by example, and not be the ones who drive people to desperation.
Anyway, Steven, if this is truly critical and you can't wait to figure this out, you may want to back up files and reinstall FC3. There is no way to downgrade that I know of. If you had partitioned your disks with LVM you may be able to just install a partial FC3 alongside which you let you run until the FC4 issues are figured out.
About the Dell systems...yes, Dell has a long history of producing BIOSes that are very un-Linux friendly, especially with some of the video drivers. The newer Linux drivers like i810 as you've found seem to deal with them better on some models. Ultimately this is most likely a Dell issue as they have flawed BIOSes, but as you've done your homework on bugzilla, it seems you have resolved that problem.
Turning off selinux was the first step for your other problems. At some point you'll want to turn it back on in non-enforcing mode to see what would have broke before it actually does.
I don't know Majordomo (I'm a Python and hence Mailman user), but there should be a way to enable some sort of Perl debugging in it. Perhaps if you describe what the problem actually is better. Is it random or repeatable. Does it depend on any of the inputs, or on the recipient addresses? Are the mail headers intact? Can you capture the messages in the sendmail queue (or are you using something other than sendmail?)? If you're experienced enough, perhaps you can download the official Majordomo code itself and try building it anew.
I setup majordomo on a RHES4 server this weekend and the SELinux is : $/usr/sbin/getenforce Enforcing
I downloaded the tarball from the main site then built it an installed it.
One trick to be aware of : Majordomo like Mailman uses an suid wrapper and sendmail won't use it unless a link is setup in /etc/smrsh.
$ cd /etc/smrsh $ sudo ln -s /usr/lib/majordomo/wrapper wrapper
Assuming you have configured sudo, that should allow it to work.
To check for errors :
$ tail -f /var/log/maillog
Then hit the return key a few times so you can see a boundary area in the log information, and send an email to the list. On the command line press <ctrl>+<c>. There may be a cryptic error message that you can include with your request for help or put in Google or your other favourite search engine to see if others have had the same problem and what was done to solve it.
And I think the output of strace may still have some useful information in it.
Deron Meranda
I would not be surprised if the poster did not use strace, depending on his level of expertise and what packages he installed, he may not have the program or know about it. Even if he did have it and know about it, he may not understand the output or know what to look for.
I may not have seen his request for help before this posting, because I was looking for other subjects. Sorry if I missed it and could have helped before Steven popped his top, but I am just another user on this list, and can't be expected to help everyone because the developers have an ego to maintain. Majordomo is not supported, because mailman is, so the developers will say, if you want help go elsewhere or do it yourself and submit it to Extras {gag}.
On Tue, 2005-12-07 at 00:46 -0500, Mike McCarty wrote:
Stefan Held wrote:
Am Montag, den 11.07.2005, 19:39 -0400 schrieb Steven W. Orr:
[snip]
I suspect either Selinux or udev. Btw last week was a bank robery. Nobody knows who is responsible. I suspect gcc also for that.
Sarcasm like this really doesn't look well on the one who uses it.
BTW, I had considered upgrading to FC4 from FC2, but reconsidered after watching here for about a month.
I don't like this guy's tone much, either. But I decided against FC4 for basically the reasons he gave.
Agreed after fighting it out over problems with the last release, I figured I'd sit this one out for a while and watch everyone else get bashed around. From what I can tell FC4 was released with a number of problems that are show stoppers for some, irritants for others but don't affect some people at all.
I have yet to see a developer say : Oops, I must have missed that one, please do <this> and reply back with the results, so I can get right on it for you.
Unfortunately, we're just here to do the QA and provide entertainment for the developers when the feel like steam rolling someone.
[snip]
Come on, be specific. I cannot use my Washing Machine at all. So now let us blame Fedora for it.
Makes you look sillier than him.
FC4 looks too unstable for me at present, as well. I'll wait until some dust settles. But I'm sure things will get worked out.
From the way the developers talk, you would think this is
the rawhide list. I thought FC was supposed to be a step above rawhide not the same catagory. I also though FC was supposed to be STABLE but with frequent revisions, not unusable except in specific situations.
Mike
-- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!
Hi
I have yet to see a developer say : Oops, I must have missed that one, please do <this> and reply back with the results, so I can get right on it for you.
Did you see http://fedoranews.org/mediawiki/index.php/Caveats_and_Known_Bugs_on_FC4
regards Rahul
On Tue, 2005-12-07 at 16:48 +0530, Rahul Sundaram wrote:
Hi
Unfortunately I have little confidence that the Fedora team are paying sufficient attention to this.
From my reading (admittedly very superficial) of development lists
there is too much time and energy spent on new developments, and not enough on making sure the basic installation is rock solid. [Making sure Xorg works on all systems is far more important than getting 3D graphics in place, IMHO.]
Fedora development list is about new development (duh!) so its not surprising that the discussion there is mostly about what happens on the development tree. For people working on 3D systems, getting them working is their top priority and the only reason Xorg could be remotely usable for them. So examples like that are biased. Installer related discussions happens on the anaconda list. If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
regards Rahul
We all read :
Hi
...snip...
Blah Blah 3d Blah Blah Xorg Blah Blah More of the same bullshit Blah Blah Bugzilla Blah Blah.
LOL Rahul
No need to respond, we have heard the same BS so many times. Don't respond unless you are going to help!
On Tue, 2005-12-07 at 14:53 +0100, Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla, at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940 ======================================= Bugzilla Bug 160940 ? anaconda bombs out on Sony Picturebook while "Reading package information" =======================================
No, no progress. Might as well have written to the Pope.
I heard he responds though.
Only response I got was to ask for the Traceback, which I had already given, in full, in the original report.
I posted another bugzilla on the kdesktop site, https://bugs.freedesktop.org/show_bug.cgi?id=718. Again, no response except from others saying they had the same problem. Someone wrote to me with a patch, which worked (after re-compiling xorg). I reported this, but got no response. I wrote to half-a-dozen people mentioned in the source, but none replied.
Then, about a year later the patch was applied, again without mention in the bugzilla.
So I'm afraid my experience is that posting a bugzilla is unlikely to be a rewarding experience.
Also the way the bugzilla site is arranged is like something out of the ark. Someone ought to ask themselves, "Is this the best way of organising a bug-reporting site? Will people find it simple to report bugs? Will people find it simple to search through the site."
As far as I am concerned, the answer is "No. No. No."
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
On Tue, 2005-12-07 at 19:31 +0530, Rahul Sundaram wrote:
Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla,
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
regards Rahul
And neither are your repetitious posts to submit bug reports for bugs that already have multiple entries.
On Tue, 2005-12-07 at 09:38 -0500, Mike McCarty wrote:
Timothy Murphy wrote:
Rahul Sundaram wrote:
If you want bugs to be addressed, Fedora Bugzilla is the right place for that.
That reminds me - time to take the monthly look at my bugzilla, at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940 ======================================= Bugzilla Bug 160940 ? anaconda bombs out on Sony Picturebook while "Reading package information" =======================================
No, no progress. Might as well have written to the Pope.
So, you have complaints about the Pope as well? Or at least it seems so.
I thought it was a compliment, he seemed to have expectation of getting at least some kind of an answer.
[snip]
Also the way the bugzilla site is arranged is like something out of the ark. Someone ought to ask themselves, "Is this the best way of organising a bug-reporting site? Will people find it simple to report bugs? Will people find it simple to search through the site."
As far as I am concerned, the answer is "No. No. No."
Yes, I have found bugzilla difficult to navigate.
If you really are having such a terrible time, then you probably need not to use FC4. The decision to put it on your machine was made by one man. That same man has decided to let FC4 remain on his machine. That man is the only one who can put something else on it.
Mike
That's it, tell everyone to get lost and there will be nobody using it.
On Tue, 2005-12-07 at 14:20 -0500, Mike McCarty wrote:
beartooth wrote:
On Tue, 12 Jul 2005 13:56:56 -0500, Mike McCarty wrote:
Les Mikesell wrote:
The trick to avoiding problems with Fedora is to wait until towards the end of a version's life. Not past the end - you want a version still being actively used, but you want to be able to immediately do a 'yum update' to pick up the fixes for the problems others have already experienced. FC1 is too old since it is no longer being updated - if you find a new problem it won't be fixed, and FC4 is too new if you don't want to be involved in helping with the fixes.
That's the approach I've decided to take. I may upgrade from FC2 to FC3 soon.
It's the approach I used to take as a total sub-technoid; and it was OK, I guess -- but I did twelve or fifteen installs on five machines over about three years, and all the keeping up got pretty old pretty fast.
Why do that many installs? One doesn't have to go stepwise, you know. I may wait for FC4 to settle down in, say, 6 mo and then go for FC4.
That is the life of the distro!
Mike
-- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!
On Monday, Jul 11th 2005 at 19:39 -0400, quoth Steven W. Orr:
=>The problems with it are a mile long and I'm very disappointed that I upgraded =>my home machine. => =>* I run Majordomo2 which is a great mailinglist manager. Not all my => mail is getting delivered and I'm getting messages with blank => bodies. No one else seems to be having this problem. I'm not sure => what I can do now. It could be perl, or worse, it could be gcc => which was used to build perl. => =>* I have a Palm IIIc connected on a serial port. pilot-link woks ok => but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) => are all unable to connect to the device. No one knows why. I => suspect gcc. => =>* I have a Dell Dimension 4700 at work. The upgrade went fine from => Core 3 to 4. Afterwards, I went to start X and it failed. The => xorg.conf file was identical both before and after the upgrade, => including after running system-config-display --configure. The fix, => after a team of people poured 6 hours into it was to not use the => VESA driver that it used before. The correct choice is to use the => i810 driver. The writeup for it is here: => https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
I never thought this discussion would get as far out of control as it did. All I wanted to do was to suggest to those who needed the suggestion that things just might not be as stable as my expectation.
Thanks go to all the people who interpreted my message in the correct tone.
The problem with majordomo was fixed 20 minutes after my rant by the mj2 developer. One thing that should be made clear is that the problem was not with majordomo. The problem was with Majordomo2. Mj2 is a total rewrite and has no relationship to the old majordomo that has seen no action for about 7 years.
The problem with the palm is being looked at and I can survive until a solution is found. It seems that the problem happens on FC4 machines exclusively.
I now return you to your normal flow of infotrons.
On Wed, 2005-13-07 at 01:49 +0530, Rahul Sundaram wrote:
Hi
I have yet to see a developer say : Oops, I must have missed that one, please do <this> and reply back with the results, so I can get right on it for you.
Did you see http://fedoranews.org/mediawiki/index.php/Caveats_and_Known_Bugs_on_FC4
regards Rahul
I read it twice, and don't see any admissions.
Now why would I have read that?
Maybe you are all about bugzilla and mediawiki, but I am not reading them every day, that is your job. My job is trying out the software and when I find something that may be a problem ask if anyone has a simple solution, and if it is a bug check to see if there is a solution, if not submit a bug report. Then you and the other developers are supposed to fix the bug or provide assitance to get additional information so you can fix the bug. It is part of the social contact : We don't get charged to use the software, but have to help when we find bugs, so that the people who pay outrageous amounts for RHEL do not have to put up with many serious bugs.
The software is supposed to be stable when put into FC, where it is more thoroughly tested by end users, who are willing to put up with some bugs. It is not supposed to be BETA testing that is what rawhide is for. I guess you might call it tertiary or DELTA testing. There is no abrogation of responsibility for the proper testing by the developers. There is also no call for uncongenial comments or magniloquence, we just want straight answers.
On Wed, 2005-13-07 at 02:00 +0530, Rahul Sundaram wrote:
Hi
We all read :
speak for yourself
No need to respond, we have heard the same BS so many times. Don't respond unless you are going to help!
Avoid pre implications
I have watched you steam rolling people for a long time, in case you didn't know 'pre' indicates something 'in advance of' which comes for the latin root 'ad' which means 'toward'. Somthing that comes 'afterwards' uses the term 'post', and since I was indicated prior actions as being the cause of the dismissal your comment makes little sense. If you meant that, in order to comply we would not have to read your insults and magniloquent suggestions, then by all means please comply.
regards Rahul
Rahul Sundaram wrote:
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
Well, my experience is exactly the opposite. I've had great help from the Fedora mailing list - and particularly from you, Rahul, thank you - but my experience with redhat bugzilla has not been encouraging.
It is not just that my two bugs were not solved, I saw no evidence that anyone had looked at them at all. I'd really like to feel that there was a mechanism in place, and hopefully someone looking over it, so that if a bug had not been investigated for say two months a reminder would be sent to the person in charge.
Timothy Murphy wrote:
Rahul Sundaram wrote:
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
Well, my experience is exactly the opposite.
Well you dont have to take my word on it. Generate a report here https://bugzilla.redhat.com/bugzilla/query.cgi?format=report-table and see for yourself the stats available
I've had great help from the Fedora mailing list - and particularly from you, Rahul, thank you -
Welcome
but my experience with redhat bugzilla has not been encouraging.
Maybe the interactions needs to be improved there. I have been writing a few guidelines in http://fedoraproject.org/wiki/BugsReports
It is not just that my two bugs were not solved, I saw no evidence that anyone had looked at them at all. I'd really like to feel that there was a mechanism in place, and hopefully someone looking over it, so that if a bug had not been investigated for say two months a reminder would be sent to the person in charge.
A Fedora bug squad has been formed to address more of these concerns. http://fedoraproject.org/wiki/Bugs. Stay turned for more information.
regards Rahul
regards Rahul
On Wed, 2005-13-07 at 04:14 +0530, Rahul Sundaram wrote:
Timothy Murphy wrote:
Rahul Sundaram wrote:
Your specific bugs may not have been addressed but if you look at the reports, thousands of bugs are being worked upon every week. If you put in bugzilla, you have a way to reach the developers and help keep track of it. Users list is not going to provide you that.
Well, my experience is exactly the opposite.
Well you dont have to take my word on it. Generate a report here https://bugzilla.redhat.com/bugzilla/query.cgi?format=report-table and see for yourself the stats available
I've had great help from the Fedora mailing list - and particularly from you, Rahul, thank you -
Welcome
but my experience with redhat bugzilla has not been encouraging.
Maybe the interactions needs to be improved there. I have been writing a few guidelines in http://fedoraproject.org/wiki/BugsReports
It is not just that my two bugs were not solved, I saw no evidence that anyone had looked at them at all. I'd really like to feel that there was a mechanism in place, and hopefully someone looking over it, so that if a bug had not been investigated for say two months a reminder would be sent to the person in charge.
A Fedora bug squad has been formed to address more of these concerns. http://fedoraproject.org/wiki/Bugs. Stay turned for more information.
Maybe I was too harsh, in my previous posts.
That kind of strategy is what I have been waiting to hear, and is commonplace in many of the opensource projects I have contributed to.
It is easier to get help from the FC community, if there is a glimmer of hope that someone is listening and is interested in finding a solution. Less triage would be necessary if more simple answer were provided on the list, rather than telling people to place a bug report first.
When I discover a problem, I first check the man pages and documentation, if I don't find any solutions, I use Google only then do I ask on a mailing list. If I don't get any help then I look for bug reports and if there are no bugs that are the same, place a new report.
I don't recall the last time I had a bug that wasn't listed a bunch of times in bugzilla, so I haven't added a new one for years. What has been stressful since FC3 is the fact that all the bugs I found had many unsolved entries and appeared to have been closed with an excuse for not resolving the issue, rather than a solution.
I am encouraged to see that you are interested in motivating the developers to work with the community in a co-operative fashion rather than the combative one that seems to be prevalent now. I know that speaking for myself at least, if a developer has a helpful attitude I would bend over backward to help, but if they have a snotty holier than thou attitude, I won't give a moments thought about responding harshly or not at all. At the end of the day, I don't have to live with any RH products, but if the developers value their job, they do. RH used to provide the absolute best products in the market until RHL 8.0. I bought many box sets and even had subscriptions for my home machines. I sold a bunch of people of getting RHL Professional, but since then RH has provided me with more and more grief. I can only hope there are others like yourself who strive to get things back on track.
regards Rahul
regards Rahul
Hmmmm........... Have you ever heard of the two words "back up" ?
I back everything up before upgrading or doing a fresh install. I had no issues with my home desktop machine I did have an issue with my laptop. It upgraded ok......... I had to rebuild a couple of things that would run with the new kernel, everything was fine. Then all of a sudden....... X quit working, and it would not even boot in a low level. The rescue CD didn't do me a bit of good..........
Well.......(since I had things backed up)...... I just did a fresh install.
Everything is happy now. Yes, it is more time consuming, but well worth the effort as I learned...........
On Tue, 12 Jul 2005, Mike McCarty wrote:
Stefan Held wrote:
Am Montag, den 11.07.2005, 19:39 -0400 schrieb Steven W. Orr:
[snip]
I suspect either Selinux or udev. Btw last week was a bank robery. Nobody knows who is responsible. I suspect gcc also for that.
Sarcasm like this really doesn't look well on the one who uses it.
BTW, I had considered upgrading to FC4 from FC2, but reconsidered after watching here for about a month.
I don't like this guy's tone much, either. But I decided against FC4 for basically the reasons he gave.
[snip]
Come on, be specific. I cannot use my Washing Machine at all. So now let us blame Fedora for it.
Makes you look sillier than him.
FC4 looks too unstable for me at present, as well. I'll wait until some dust settles. But I'm sure things will get worked out.
Mike
Actually, I think a little humor helps the frustrated soul.......... I have had the frustrations, and some of these comments on here, albeit unneccesary, are funny..... ;-)
On Tuesday 12 July 2005 23:07, Don Dupy wrote:
Hmmmm........... Have you ever heard of the two words "back up" ?
I back everything up before upgrading or doing a fresh install. I had no issues with my home desktop machine I did have an issue with my laptop. It upgraded ok......... I had to rebuild a couple of things that would run with the new kernel, everything was fine. Then all of a sudden....... X quit working, and it would not even boot in a low level. The rescue CD didn't do me a bit of good..........
Well.......(since I had things backed up)...... I just did a fresh install.
Everything is happy now. Yes, it is more time consuming, but well worth the effort as I learned...........
-- Don Dupy
Well, I've just come upstairs in defeat, defeated by FC4. I'd asked previously how to get the kde kicker back after yum had updated some of kde, which resulted in the kicker crashing on startup. And each time that portion of my posting was ignored, even when I stripped it down and left ONLY that question.
So I re-installed, thinking it would check and see what was broken, but only mozilla was down-dated.
So I installed the whole thing, 3rd pass. It got to /dev/hda3 and claimed it was busy and couldn't do the install, tried 3 times until the missus said it was time for dinner, at Sully's... Shut it off & left.
After dinner, fired it back up & started an install, doing it 2 more times from the first cd on, each time telling it to autopartition /dev/hda only, which worked rather nicely the first time. Each time I got to it, I assigned a hostname & address on my local network for eth0. Using ipv4 syntax, as in 192.168.x.x etc. Setting gateway etc exactly as its set for the other 2 machines here.
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking. yum of course loves that...
All this worked flawlessly except for having to run a card fully capable of 32 bit color in 1600x1200 24 bit mode, on the first install 2 weeks ago.
About the only thing that got quasi-fixed was that now, its actually booting from /dev/hda1 instead of /dev/hdb1. So now, my emc install on /dev/hdb is inaccessable until I mount /dev/hdb1 and copy all the stuff back, probably editing as I go.
This forum, with all due respect, seems to be only a place to post ones grips, letting the user vent. But as far as actually getting a message that there is something wrong, TO THE PERSON WHO IS FAMILIAR ENOUGH WITH THE AREA IN QUESTION THAT AN ANSWER MIGHT BE SUPPLIED, IS OBVIOUSLY NOT POSSIBLE UNLESS YOU ARE WILLING TO HACK AT BUGZILLA UNTIL IT FINALLY ACCEPTS A BROKEN, PIDGEON ENGLISH VERSION OF THE PROBLEM. And we get the impression its intended to be that way because redhat/fedora doesn't really want to fix problems when there is this kewl new project to work on that we don't even know the name of yet... Sarcasm intended.
Redhat/Fedora needs to assign some folks to monitor this list for say 6 to 8 weeks after a release, who can actually deduce whats wrong from postings to this list, or bring it to the attention of someone who can, and not route it to the internal /dev/bitbucket in the back of the server closet where problems never make it to the right people who can fix them. Thats not how to win friends and influence people whom you would like at some point, to sell a $700 RHEL package to. 98% of us you never will, but you should try to impress, not frustrate folks further by sending them to bugzilla where they get caught in an endless loop of searching for their problem without ever finding it or getting to the bug data entry screen. Been there, done that, probably 3 dozen times all told, but only managed to get lucky and get at the edit screen twice, maybe 3 times in 5 plus years. By then I'm usually so frustrated with it I can't even remember my name, so you get a piss-poor report missing 90% of the details.
Now, does anyone know how I can make an ifconfig of eth0 show an ipv4 style address AND get a working network? Or should I go do a 7th "everything" install? If thats the case, it WON'T be FC4.
FWIW, I even tried to do a 'service network restart' after checking the eth0 files, but even that doesn't work, kmalloc says it cannot allocate 4GB (round figure of course) of memory. Yes, thats right, a 'service network restart' is asking for 4GB of memory.
FC4 is not ready, even for alpha testing, at least at this users location.
I installed FC4 last night. Tonight I was doing yum upgrades. I didn't touch a thing. I just gave the command yum -y upgrade. Everything started downloading fine. 279 packages I think it was. Sound works, just plug in the speakers, no fiddling with anything.
I decided to reinstall though as the partitioning wasn't what I wanted. Not FC4's fault, it was mine. I should have paid more attention during the partitioning last night.
Other than the reinstall due to my lack of attention, I was quite pleased with what I saw. NO PROBLEMS.
Perhaps one of the key issues here backup your data, DO A CLEAN INSTALL.
I've been on these lists since ver 5.2 I believe it was. There are several others who have been here perhaps longer than me. I have NEVER done an UPGRADE. Always a clean install. I simply do not have the issues that I see people complaining about here.
I'm not trying to start a religious war here about you should do this or that. Or say that anyone is wrong or whatever. I'm simply telling you what I do and the results. YMMV
Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gene Heskett wrote:
| 3 more installs later I still don't have a usable x-server like I | had with the first install, seems the nv driver doesn't support 32 | bit, nor 1600x1200 screens, suddenly??. And x-server problems
This sounds really like you did not tell X that your monitor was capable of this yet. Make sure you set up your monitor appropriately in system-config-display.
| This forum, with all due respect, seems to be only a place to post | ones grips, letting the user vent. But as far as actually getting | a message that there is something wrong, TO THE PERSON WHO IS | FAMILIAR ENOUGH WITH THE AREA IN QUESTION THAT AN ANSWER MIGHT BE | SUPPLIED, IS OBVIOUSLY NOT POSSIBLE UNLESS YOU ARE WILLING TO HACK | AT BUGZILLA
Bugzilla is NOT very end-user friendly or that effective in searching IMO too. Many times I could not find entries that are in there by searching. But I'm willing to believe heavy users can work it really effectively by learning its quirks. Yesterday I saw this for example:
http://bugzilla.ximian.com/query.cgi
and that is just a brick wall killer for simple low duty-cycle end-user participation. Redhat have a "simple search" but that either finds a bazillion ancient bugs or "zaroo" (yeah really cute after the hundredth time). But what'd be better is a flat Google-type interface, lose all the comboboxes and just accept product and versioning as "literal strings" if given.
| Redhat/Fedora needs to assign some folks to monitor this list for | say 6 to 8 weeks after a release, who can actually deduce whats | wrong
Rahul is around a lot, that never used to be. I often see kernel changelogs coming out of complaints on the lists and bugzilla. So I think noting issues publicly does have the desired effect. However there is a kind of threshold at work here I have observed... one can stick a complaint in Bugzilla and it is apparently ignored for weeks. (One can also get great immediate service in there too, but that's not my point). Then a few more people get the same problem and add their voices on the ml and/or bugzilla, maybe someone *@redhat.com gets the problem and then suddenly it is fully on the agenda and being attacked. So the path to getting the full-on attention is not always direct, it does not mean that your apparently ignored complaint did not get noted and maybe help crank up the potential on that neuron to just below firing level.
I don't know how else they can really work that except allow the guys responsible for the package with the problem to choose which issues to address based on available info, prevalence of the problem, reproducibility, etc, and also to allow them to just not respond if they have nothing to say. If you really want 100% attack on every random bugzilla entry RH will be having to pay for a lot more tech staff for little or no benefit to them, it ain't going to happen.
| Now, does anyone know how I can make an ifconfig of eth0 show an | ipv4
Sorry, I did not install FC4 yet.
- -Andy
Hi
It is easier to get help from the FC community, if there is a glimmer of hope that someone is listening and is interested in finding a solution. Less triage would be necessary if more simple answer were provided on the list, rather than telling people to place a bug report first.
Not really. Developers cannot read all of the mails in the users list and provide answers here. The amount of traffic is simply overwhelming. Bug triaging is more eloborate and well established process that covers more ground.
regards Rahul
Guy Fraser wrote:
On Wed, 2005-13-07 at 02:00 +0530, Rahul Sundaram wrote:
speak for yourself
I have watched you steam rolling people for a long time, in case you didn't know 'pre' indicates something 'in advance of' which comes for the latin root 'ad' which means 'toward'. Somthing that comes 'afterwards' uses the term 'post', and since I was indicated prior actions as being the cause of the dismissal your comment makes little sense. If you meant that, in order to comply we would not have to read your insults and magniloquent suggestions, then by all means please comply.
I didn't understand your earlier cryptic posting, but as far as I can see you are criticising Rahul Sundaram in some way.
I am critical of some aspects of Fedora development (particularly anaconda) but I have always found Rahul very helpful, and in fact the person most likely to help with Fedora queries.
I hope he will not be discouraged by what seems to me gratuitous rudeness.
Hi
It wouldn't be so overwhelming if there were fewer bugs.
Users discuss many other stuff besides bugs.
If you want bugzilla reports, then fix bugzilla so we CAN file a report. Getting stuck in search loop's infinite version of hell, with no way to get to the editor and make a new report is not productive use of time for either of us.
Hasnt happened to me in a long time now. It gets updated and improved all the time. It might not be the best tool out there but its pretty usable. Bugzilla has itself as a component too ;-)
regards Rahul
On Wednesday 13 July 2005 08:49, Rahul Sundaram wrote:
Hi
It is easier to get help from the FC community, if there is a glimmer of hope that someone is listening and is interested in finding a solution. Less triage would be necessary if more simple answer were provided on the list, rather than telling people to place a bug report first.
Not really. Developers cannot read all of the mails in the users list and provide answers here. The amount of traffic is simply overwhelming.
It wouldn't be so overwhelming if there were fewer bugs.
Bug triaging is more eloborate and well established process that covers more ground.
The word is 'elaborate', and bugzilla is excedrin headache #1 to me. If you want bugzilla reports, then fix bugzilla so we CAN file a report. Getting stuck in search loop's infinite version of hell, with no way to get to the editor and make a new report is not productive use of time for either of us. We give up and you don't get the report, so both of our time spent on bugzilla is wasted. Fix bugzilla so *we* can file bug reports if you want bug reports.
And let us know when it has been fixed.
The automated crash reporting tools for this supplied with FC4, with all their pulldown choices, have not so far been effective as the pulldowns don't include the name of the app that actually failed in their choices, (where is rhn-applet, or kde 'kicker') and even if they did, how would one get the message out when there is no networking? The networking setup is now totally fubar, doing ipv6 stuffs only, which doesn't work in an ipv4 environment. It might be a nice idea in the ideal world, but it certainly isn't worth its disk space in the real world, with real problems.
A bugzilla that works FOR REAL PEOPLE is whats needed.
regards Rahul
Gene Heskett wrote:
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking. yum of course loves that...
I don't set up as an expert, but it seems to me that the changes you are making are too comprehensive. You would be better off pausing a little longer, and trying to work out why one particular thing is not working.
For example, if I had a problem with X I would try installing in text mode, and then try to set up X later, using one of the several tools available.
I've never understood your problems with /dev/hda and /dev/hdb . I think that normally the computer will try to boot from /dev/hda unless you have told the BIOS otherwise. But if you install grub on the /dev/hda MBR it can certainly find partitions on /dev/hdb .
As for IPv6, I think you can disable this by adding IPV6INIT=no to /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) and saying "service network restart" as root. (Or you could remove the IPv6 module from /lib/modules/<version>/ .)
M.Lewis wrote:
I installed FC4 last night. Tonight I was doing yum upgrades. I didn't touch a thing. I just gave the command yum -y upgrade. Everything started downloading fine. 279 packages I think it was. Sound works, just plug in the speakers, no fiddling with anything.
I decided to reinstall though as the partitioning wasn't what I wanted. Not FC4's fault, it was mine. I should have paid more attention during the partitioning last night.
Other than the reinstall due to my lack of attention, I was quite pleased with what I saw. NO PROBLEMS.
Perhaps one of the key issues here backup your data, DO A CLEAN INSTALL.
You seem to me to be somewhat lacking in imagination. "I have never had a crash in my car. KEEP YOUR CAR CLEAN."
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
I've been on these lists since ver 5.2 I believe it was. There are several others who have been here perhaps longer than me. I have NEVER done an UPGRADE. Always a clean install. I simply do not have the issues that I see people complaining about here.
Consider the possibility that this is because you are using a different computer.
On Wednesday 13 July 2005 02:12, Andy Green wrote:
Redhat have a "simple search" but that either finds a bazillion ancient bugs or "zaroo" (yeah really cute after the hundredth time). But what'd be better is a flat Google-type interface, lose all the comboboxes and just accept product and versioning as "literal strings" if given.
A reasonable alternative is to, in fact, use Google.
<search terms> site:bugzilla.redhat.com
will, I find, work better than bugzilla's own search tools.
Regards, Mike Klinke
On Wednesday 13 July 2005 09:34, Timothy Murphy wrote:
Gene Heskett wrote:
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking. yum of course loves that...
I don't set up as an expert,
Neither did I. I just selected automatic disk partitioning on /dev/hda, and manual configuration of the network (which I did) as opposed to the default dhcp. And 'everything'...
but it seems to me that the changes you are making are too comprehensive. You would be better off pausing a little longer, and trying to work out why one particular thing is not working.
For example, if I had a problem with X I would try installing in text mode, and then try to set up X later, using one of the several tools available.
I don't think there is, and I haven't found, a non gui install (linux text) that doesn't fail from a /dev/hda3 is busy condition.
I've never understood your problems with /dev/hda and /dev/hdb .
Its real simple, both hda1 and hdb1 were marked as bootable, because hdb was originally hda & vice-versa. The bios apparently doesn't care, and up till the last reboot last night, it was actually booting from the contents of /dev/hdb1 even though it wasn't mounted once booted, hda1 was.
I think that normally the computer will try to boot from /dev/hda unless you have told the BIOS otherwise. But if you install grub on the /dev/hda MBR it can certainly find partitions on /dev/hdb .
And vice-versa as has been proved here for quite some time.
As for IPv6, I think you can disable this by adding IPV6INIT=no to /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) and saying "service network restart" as root.
But a 'service network restart' fails because it cannot allocate via kmalloc, 4GB of ram. Thats a ridiculous error on the face of it, and has to be a real bug.
(Or you could remove the IPv6 module from /lib/modules/<version>/ .)
Why should I have to, when in the installs network config, dhcp is disabled and the network configured by hand, and iptables and selinux is disabled since I'm behind a firewall? I still have to add to the /etc/hosts file of course, but thats not helping now since it decided to use only ipv6 addressing according to an 'ifconfig eth0' report.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Gene Heskett wrote:
On Wednesday 13 July 2005 09:34, Timothy Murphy wrote:
Gene Heskett wrote:
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking.
What is in /etc/hosts, /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0 ?
Paul.
On Wed, 2005-07-13 at 08:42, Timothy Murphy wrote:
Perhaps one of the key issues here backup your data, DO A CLEAN INSTALL.
You seem to me to be somewhat lacking in imagination. "I have never had a crash in my car. KEEP YOUR CAR CLEAN."
It's more like "KEEP YOUR EYES ON THE ROAD"...
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Then you've created a totally unique situation where the reason it works at all is likely because you have bits and pieces of some unrelated version still running. That might work for you, but if you have problems no one else will understand them or be able to help.
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That's a reasonable approach, as is backing it up and restoring. You probably want the backup anyway in case you make a mistake involving the partitions.
I simply do not have the issues that I see people complaining about here.
Consider the possibility that this is because you are using a different computer.
Historically, Linux kernels have solved most of their hardware issues somewhere around X.X.20. If don't use anything unusual you might not notice this. I see that firewire might be fixed in 2.6.12...
Gene Heskett wrote:
On Wednesday 13 July 2005 09:34, Timothy Murphy wrote:
Gene Heskett wrote:
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking. yum of course loves that...
I don't set up as an expert,
Neither did I. I just selected automatic disk partitioning on /dev/hda, and manual configuration of the network (which I did) as opposed to the default dhcp. And 'everything'...
but it seems to me that the changes you are making are too comprehensive. You would be better off pausing a little longer, and trying to work out why one particular thing is not working.
For example, if I had a problem with X I would try installing in text mode, and then try to set up X later, using one of the several tools available.
I don't think there is, and I haven't found, a non gui install (linux text) that doesn't fail from a /dev/hda3 is busy condition.
You didn't say that. You said that "the nv driver doesn't support 32 bit", which seems to me to imply that you have the system working except for X. (Yes, I know you have networking problems too.)
In any case, my point is that you seem to have brought up at least 3 totally unrelated issues, and apparently believe that repeated installation will resolve them.
I've never understood your problems with /dev/hda and /dev/hdb .
Its real simple, both hda1 and hdb1 were marked as bootable, because hdb was originally hda & vice-versa. The bios apparently doesn't care, and up till the last reboot last night, it was actually booting from the contents of /dev/hdb1 even though it wasn't mounted once booted, hda1 was.
Normally (that is, unless you go into the BIOS setup at boot-time and alter the settings) the machine will boot from /dev/hda , that is, the master disk on the first controller. It won't look at the MBR on /dev/hdb (the master disk on the second controller) at all, and it won't care what partition on /dev/hdb you have marked as active.
I would suspect that if you changed the two disks then there is something wrong with your grub installation or with the entries in /dev/fstab . Personally, I would re-install grub with "grub-install --recheck /dev/hda",
I would guess the "busy /dev/hda3" is due to confusion over partitions.
I think that normally the computer will try to boot from /dev/hda unless you have told the BIOS otherwise. But if you install grub on the /dev/hda MBR it can certainly find partitions on /dev/hdb .
And vice-versa as has been proved here for quite some time.
I don't know what you mean by vice versa, but the machine will not normally look at the MBR on /dev/hdb (if that is what you are referring to).
As for IPv6, I think you can disable this by adding IPV6INIT=no to /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) and saying "service network restart" as root.
But a 'service network restart' fails because it cannot allocate via kmalloc, 4GB of ram. Thats a ridiculous error on the face of it, and has to be a real bug.
(Or you could remove the IPv6 module from /lib/modules/<version>/ .)
Why should I have to, when in the installs network config, dhcp is disabled and the network configured by hand, and iptables and selinux is disabled since I'm behind a firewall? I still have to add to the /etc/hosts file of course, but thats not helping now since it decided to use only ipv6 addressing according to an 'ifconfig eth0' report.
What do you mean by "configured by hand"? When networking starts up, it will look at /etc/sysconfig/network-scripts/ifcfg-eth0 so what is in this file is highly relevant.
Les Mikesell wrote:
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Then you've created a totally unique situation where the reason it works at all is likely because you have bits and pieces of some unrelated version still running. That might work for you, but if you have problems no one else will understand them or be able to help.
How can one have "bits and pieces of some unrelated version still running" if you do a clean install?
I'm not actually asking for your help, I'm simply pointing out that your dogmatic assertion that installation is always better than upgrade is not true, giving as a counter-example the fact that I have a machine where the first did not work, and the second did.
The reason for this - although this is not strictly relevant - is that recent versions of Fedora run mkinitrd when installing their kernel. This has to determine in some way which modules should be included in initrd and in my case it includes the wrong scsi driver. There are various ways in which I can counter-act this, but the simple fact is that a clean install does not work - it leaves a machine which will not boot.
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That's a reasonable approach, as is backing it up and restoring. You probably want the backup anyway in case you make a mistake involving the partitions.
It's not an either-or situation. You implied that you deleted /home , and I'm pointing out that that was a silly thing to do.
Historically, Linux kernels have solved most of their hardware issues somewhere around X.X.20. If don't use anything unusual you might not notice this. I see that firewire might be fixed in 2.6.12...
This seems to me complete nonsense. There are many hardware issues for Linux remaining, eg problems with RAID, graphics, 11g WiFi, many USB devices, etc, etc, I suspect there always will be such problems, as new hardware devices come out.
Timothy Murphy wrote:
Les Mikesell wrote:
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Then you've created a totally unique situation where the reason it works at all is likely because you have bits and pieces of some unrelated version still running. That might work for you, but if you have problems no one else will understand them or be able to help.
How can one have "bits and pieces of some unrelated version still running" if you do a clean install?
Erm, he was responding to your comment on having an upgrade work when a clean install won't. His point is well-taken, I think.
I'm not actually asking for your help, I'm simply pointing out that your dogmatic assertion that installation is always better than upgrade is not true, giving as a counter-example the fact that I have a machine where the first did not work, and the second did.
I think that your comment about upgrade being in some instances better than install is well-taken, but not supported by your argument.
IMO Mode on:
A better argument is that if Linux is ever to overtake W* as a user-friendly OS, it had better find a way to upgrade W/O smashing all user data.
Period.
End of argument.
If overtaking W* is not a goal, then whatever floats your boat is fine.
[snip]
Backup is another area which is black magic at present under *NIX systems. Until the time comes when a user, upon boot, is presented with an option to create a disaster recovery set, and is allowed to make checkpoints to CD/DVD/Whatever by just clicking on a widget somewhere, then Linux, in all its incarnations, has a long long way to go just to catch up to W*, let alone overtake it and pass it by.
Just my $0.02 worth. YMMV
IMO Mode off
Mike
Steven W. Orr wrote:
The problems with it are a mile long and I'm very disappointed that I upgraded my home machine.
- I run Majordomo2 which is a great mailinglist manager. Not all my mail is getting delivered and I'm getting messages with blank bodies. No one else seems to be having this problem. I'm not sure what I can do now. It could be perl, or worse, it could be gcc which was used to build perl.
Drop the pretty GUI, and be a man - use your hand. Figure out what the problem is. Don't blame wonderful software because of your incompetency.
- I have a Palm IIIc connected on a serial port. pilot-link woks ok but all software that uses pilot-link (jpilot, kpilot, gnome-pilot) are all unable to connect to the device. No one knows why. I suspect gcc.
(see above)
- I have a Dell Dimension 4700 at work. The upgrade went fine from Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
Alright, I'll give you that one. So you're expecting a completely flawless upgrade? 2/3 success rate is good, regardless of what you're upgrading.
I've had good and bad upgrade experiences before, but this is killing me. My home machine is my domain server and it's been pretty badly crippled because of the mail problems. I can still use my palm but it's a new experience in being crippled.
I don't understand why people like you have to make a big scene like this. If you really took the time to learn how stuff works behind the pretty colors, and fix your stuff when it's broken, perhaps read a few logs - I'm quite certain that all your problems will clear up. I'm never one to just tell someone to "RTFM", but I think this does apply here.
Look at this crap that you polluted the email list with. Look how much time you've wasted, yours included. I didn't even bother to read the follow-ups, but I'm sure you've been given this type of lecture dozens of times. And you've replied once.
Let's say you get a new car, let's call it a brand new Civic - they're cool, as the kids put it. This Civic comes with 1/2 a tank of gas, factory tires, and no tint. Does this mean you're going to write consumer reports and tell them that it sucks? No. It comes that way because it was configured that way. You had a choice of picking another one, but you didn't. Is there anything wrong with your new Civic? Absolutely not. You're just pissed off because it only has half a tank of gas, factory tires, and no tint.
The type of petty complaints and blatant whining you bring, are not welcome here, especially when you do so in such a manner that has you trying to make a particular operating system look bad due simply to your incompetence.
Constructive troubleshooting by reading logs, doing research, and a clue, however, are very welcome here. There are thousands of people here who have done all of the above, and they're to help. They're not going to help you if you don't take the initiative and do your own homework first.
Sorry to waste all your guys' time on the list for reading this, but I do believe that this is a point worth making.
Thanks -dant
Dan Trainor wrote:
Steven W. Orr wrote:
[snip]
- I have a Dell Dimension 4700 at work. The upgrade went fine from
Core 3 to 4. Afterwards, I went to start X and it failed. The xorg.conf file was identical both before and after the upgrade, including after running system-config-display --configure. The fix, after a team of people poured 6 hours into it was to not use the VESA driver that it used before. The correct choice is to use the i810 driver. The writeup for it is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162699
Alright, I'll give you that one. So you're expecting a completely flawless upgrade? 2/3 success rate is good, regardless of what you're upgrading.
IMO, 2/3 success on upgrade is abysmal. [snip]
Look at this crap that you polluted the email list with. Look how much time you've wasted, yours included. I didn't even bother to read the follow-ups, but I'm sure you've been given this type of lecture dozens of times. And you've replied once.
This is not true. He has replied multple times.
Let's say you get a new car, let's call it a brand new Civic - they're cool, as the kids put it. This Civic comes with 1/2 a tank of gas, factory tires, and no tint. Does this mean you're going to write consumer reports and tell them that it sucks? No. It comes that way because it was configured that way. You had a choice of picking another one, but you didn't. Is there anything wrong with your new Civic? Absolutely not. You're just pissed off because it only has half a tank of gas, factory tires, and no tint.
Not a fair comparison. If he took his new Civic to the dealer to get a cracked windshield fixed, and it came back with a groaning transmission which frequently slipped out of gear, that might be a more apt comparison.
The type of petty complaints and blatant whining you bring, are not welcome here, especially when you do so in such a manner that has you trying to make a particular operating system look bad due simply to your incompetence.
Who set you up as netcop? Do you know what I like or dislike? Please speak only for yourself.
Now, as it turns out, I don't like his tone one bit. But I think his gripes are legitimate.
Constructive troubleshooting by reading logs, doing research, and a clue, however, are very welcome here. There are thousands of people here who have done all of the above, and they're to help. They're not going to help you if you don't take the initiative and do your own homework first.
Sorry to waste all your guys' time on the list for reading this, but I do believe that this is a point worth making.
And your constructive criticism of him was?
Sorry, but I classify your message just as much a rant as his.
Mike
On Wed, 2005-07-13 at 12:34, Timothy Murphy wrote:
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Then you've created a totally unique situation where the reason it works at all is likely because you have bits and pieces of some unrelated version still running. That might work for you, but if you have problems no one else will understand them or be able to help.
How can one have "bits and pieces of some unrelated version still running" if you do a clean install?
You don't with a new install. If you upgrade as you suggest, you probably do.
I'm not actually asking for your help, I'm simply pointing out that your dogmatic assertion that installation is always better than upgrade is not true, giving as a counter-example the fact that I have a machine where the first did not work, and the second did.
I'm not being dogmatic about it being better, I'm being dogmatic about no one else being able to help with additional problems on an upgraded machine because no one will know which bits are left over from the previous version.
The reason for this - although this is not strictly relevant - is that recent versions of Fedora run mkinitrd when installing their kernel. This has to determine in some way which modules should be included in initrd and in my case it includes the wrong scsi driver. There are various ways in which I can counter-act this, but the simple fact is that a clean install does not work - it leaves a machine which will not boot.
Some bugs aren't found until someone tries the combination of things that the program gets wrong. Reporting your lspci output and the module that is wrongly installed is probably the best you can do along with using whatever means you can to work around the bug.
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That's a reasonable approach, as is backing it up and restoring. You probably want the backup anyway in case you make a mistake involving the partitions.
It's not an either-or situation. You implied that you deleted /home , and I'm pointing out that that was a silly thing to do.
It's not silly - it's a matter of choice. If there is anything important there you should be prepared to restore it from backups in any case. Doing it that way gives you a change to resize, use a different filesystem, use LVM or whatever new features your new version offers. Not formatting the partition saves a few minutes. Pick which you want.
Historically, Linux kernels have solved most of their hardware issues somewhere around X.X.20. If don't use anything unusual you might not notice this. I see that firewire might be fixed in 2.6.12...
This seems to me complete nonsense. There are many hardware issues for Linux remaining, eg problems with RAID, graphics, 11g WiFi, many USB devices, etc, etc, I suspect there always will be such problems, as new hardware devices come out.
There will always be problems with new hardware. I'm talking about problems introduced with new software. At about version 20 it has most of the bugs found and fixed. But if the 20 releases that included those bugs hadn't been released, they still would not be found or fixed. Overgeneralization, of course, but that's what experience suggests...
On 7/13/05, Mike McCarty mike.mccarty@sbcglobal.net wrote:
IMO Mode on:
A better argument is that if Linux is ever to overtake W* as a user-friendly OS, it had better find a way to upgrade W/O smashing all user data.
It's called putting your /home partition on a separate disk or partition and being smart about your system planning. Back up /etc and /var before upgrading (preferably, back them up periodically even if you're not planning on upgrading!).
Don't upgrade, re-install. It's cleaner and you'll have less problems. I've run every version of Red Hat and Fedora since RH 7.3, and even switched to Debian, Ubuntu, and SuSE at various times without losing a byte of user data. It's possible. It's easy if you know how. And there has been at least one discussion on the possibility of adding a user-level backup/migration tool to GNOME that I know of, so it's not like the idea hasn't been floated before... but developers are needed.
(And I dispute that Windows (there, I said it) is any better when upgrading than Linux is, it just happens less often is all. But that's not something I'll argue on this list.)
Period.
End of argument.
If overtaking W* is not a goal, then whatever floats your boat is fine.
(Why would we want to overtake Windows? That's just not going to happen. The expectation that Linux is designed to do so is just ridiculous. But again, that's not what we're here to discuss.)
--- "M.Lewis" _fedoralist_@cajuninc.com wrote:
I installed FC4 last night. Tonight I was doing yum upgrades. I didn't touch a thing. I just gave the command yum -y upgrade. Everything started downloading fine. 279 packages I think it was. Sound works, just plug in the speakers, no fiddling with anything.
I decided to reinstall though as the partitioning wasn't what I wanted. Not FC4's fault, it was mine. I should have paid more attention during the partitioning last night.
Other than the reinstall due to my lack of attention, I was quite pleased with what I saw. NO PROBLEMS.
Perhaps one of the key issues here backup your data, DO A CLEAN INSTALL.
I've been on these lists since ver 5.2 I believe it was. There are several others who have been here perhaps longer than me. I have NEVER done an UPGRADE. Always a clean install. I simply do not have the issues that I see people complaining about here.
I'm not trying to start a religious war here about you should do this or that. Or say that anyone is wrong or whatever. I'm simply telling you what I do and the results. YMMV
Mike
--
You say everything works? How about 'Sound Events' in KDE or Gnome? Have you tried them?
If they work and are not distorted, tell the rest of us how you got them to work; or maybe its the hardware you using that makes it work.
Ben Steeves wrote:
On 7/13/05, Mike McCarty mike.mccarty@sbcglobal.net wrote:
IMO Mode on:
A better argument is that if Linux is ever to overtake W* as a user-friendly OS, it had better find a way to upgrade W/O smashing all user data.
[snip]
If overtaking W* is not a goal, then whatever floats your boat is fine.
(Why would we want to overtake Windows? That's just not going to happen. The expectation that Linux is designed to do so is just ridiculous. But again, that's not what we're here to discuss.)
I've seen it stated here, before. Are you sure that the future of Linux distribution and the features they may have are not reasonable topics of discussion here?
Mike
BRUCE STANLEY wrote:
--- "M.Lewis" _fedoralist_@cajuninc.com wrote:
[snip]
I've been on these lists since ver 5.2 I believe it was. There are several others who have been here perhaps longer than me. I have NEVER done an UPGRADE. Always a clean install. I simply do not have the issues that I see people complaining about here.
I'm not trying to start a religious war here about you should do this or that. Or say that anyone is wrong or whatever. I'm simply telling you what I do and the results. YMMV
Mike
--
You say everything works? How about 'Sound Events' in KDE or Gnome? Have you tried them?
If they work and are not distorted, tell the rest of us how you got them to work; or maybe its the hardware you using that makes it work.
Bruce, I can't tell you anything about Gnome. I tried it several versions ago and didn't like it. I use only KDE.
I can't address you question about sound events. No, I have NOT tried them. I can say that sound for me works with playing CD's, new mail, and gaim. I didn't tweak anything to get this to work.
As far as the hardware, this machine is maybe 2 years old. It has an old Voodoo 3000 video card, the sound is built it to the mobo. I'd have to look to see what it actually is.
Hope that helps a little.
Mike
Les Mikesell wrote:
I'm not being dogmatic about it being better, I'm being dogmatic about no one else being able to help with additional problems on an upgraded machine because no one will know which bits are left over from the previous version.
You seem to misunderstand. I'm not asking for your (or anyone's) help. This particular machine - with an Asus P2B-LS motherboard - has been running without any problems, 24/7, for 5 or 6 years. [Well, the disk seemed sick once, so I changed it.]
I'm simply pointing out that this machine _does not boot_ if I do a clean install. I hope I have explained the exact reason for this, namely, mkinitrd does not install the correct SCSI driver.
My deduction from this is that it is not true that a clean installation is _always_ better than an upgrade. Something that does not work cannot be better than something that does.
Some bugs aren't found until someone tries the combination of things that the program gets wrong. Reporting your lspci output and the module that is wrongly installed is probably the best you can do along with using whatever means you can to work around the bug.
Sigh. The machine does not run if I do a clean install, so I cannot "report my lspci output". The machine runs perfectly when I compile the kernel (with scsi compiled in it rather than a module) so there is no point in reporting my lspci output.
But here it is if you want to see it.
============================================ [tim@alfred ~]$ lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:06.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891 00:07.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02) 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) 00:0b.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) 00:0c.0 Multimedia audio controller: Platform Technologies, Inc. AGOGO sound chip (aka ESS Maestro 1) (rev 10) 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro] (rev 11) ============================================
On Wednesday 13 July 2005 13:12, Timothy Murphy wrote:
Gene Heskett wrote:
On Wednesday 13 July 2005 09:34, Timothy Murphy wrote:
Gene Heskett wrote:
3 more installs later I still don't have a usable x-server like I had with the first install, seems the nv driver doesn't support 32 bit, nor 1600x1200 screens, suddenly??. And x-server problems notwithstanding, the last two installs have set eth0 up with only an ipv6 style address, and of course I have no networking. yum of course loves that...
I don't set up as an expert,
Neither did I. I just selected automatic disk partitioning on /dev/hda, and manual configuration of the network (which I did) as opposed to the default dhcp. And 'everything'...
And one more install seems to have found the planets & stars in favorable alignment. I got thru the install, networking is working (yaay) and yum -y update is now running. And I didn't do anything different except take a pci card that acted like a dumb isa card back out of the system. It was a triple 82C55 i/o card that had no bios rom on it whatsoever. This card, while not being overly friendly to an lspci -vv listing, has never effected any of the previous installs or boot sequences. Its been in that machine for about 6 months, but will not be used with the newer stepper drivers I just bought for emc's use.
This time it went thru the post install checks and let me setup the nv card & monitor pretty much to its full capabilities. Sound worked even. The acid test of course will be when I type 'switchdesk kde' and reboot after all the yum work is finished in a couple hours. And hopefully no power failures as there is not a ups on that box, unlike these 2 here. I'm up here on the eastern edge of whats left of Dennis & we've had intermittent showers since 3ish this afternoon. And it just started up again, this time having definitely found the instructions written on the heel. Half an hour of this will equal an inch of precip. The wind is gusty, to maybe 25 mph too.
Wish me luck, I may need it...
[...]
Its real simple, both hda1 and hdb1 were marked as bootable, because hdb was originally hda & vice-versa. The bios apparently doesn't care, and up till the last reboot last night, it was actually booting from the contents of /dev/hdb1 even though it wasn't mounted once booted, hda1 was.
Normally (that is, unless you go into the BIOS setup at boot-time and alter the settings) the machine will boot from /dev/hda , that is, the master disk on the first controller. It won't look at the MBR on /dev/hdb (the master disk on the second controller) at all, and it won't care what partition on /dev/hdb you have marked as active.
This bios definitely does look at every disk in the system, but has no provisions to lock out hdb, so when that drive was made into hdb, it continued to boot from the first partition of that disk. Weird, but thats the truth. But after a few FC4 full installs, its finally booting from /dev/hda1, & once things settle, I need to go get the stuff in /dev/hdb1 and move it back so I can dual boot again.
Its a Mach motherboard, and its amazing. The previous mobo that processor and ram lived in was a biostar, and the cpu never ran lower than 150F, and often closer to 170. Same cpu & 266 fsb memory in this motherboard and the cpu, overclocked by the same 200 mhz, hasn't made it past 105 yet. A huge Glaciator cooler on it, used to 1st degree my testing finger, now I can't tell for sure if its powered up!
I would suspect that if you changed the two disks then there is something wrong with your grub installation or with the entries in /dev/fstab . Personally, I would re-install grub with "grub-install --recheck /dev/hda",
I tried that, didn't make a spec of difference.
I would guess the "busy /dev/hda3" is due to confusion over partitions.
I think that normally the computer will try to boot from /dev/hda unless you have told the BIOS otherwise. But if you install grub on the /dev/hda MBR it can certainly find partitions on /dev/hdb .
And vice-versa as has been proved here for quite some time.
I don't know what you mean by vice versa, but the machine will not normally look at the MBR on /dev/hdb (if that is what you are referring to).
But it was showing me the /dev/hdb1/grub/grub.conf's contents in the grub menu, not /dev/hda1/grub/grub.conf's. Now, finally, its straightened out again. Till I put a spare 4gig drive in for swap (or possibly /var) that is. :-) I detest having /var on the main drive in case it goes read-only & there goes your ability to troubleshoot by reading the logs cause there aren't any. Been there, done that, tempted to buy the T-short even.
As for IPv6, I think you can disable this by adding IPV6INIT=no to /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) and saying "service network restart" as root.
Didn't have to once the install actually worked, ifconfig now shows a normally configured eth0.
But a 'service network restart' fails because it cannot allocate via kmalloc, 4GB of ram. Thats a ridiculous error on the face of it, and has to be a real bug.
(Or you could remove the IPv6 module from /lib/modules/<version>/ .)
Why should I have to, when in the installs network config, dhcp is disabled and the network configured by hand, and iptables and selinux is disabled since I'm behind a firewall? I still have to add to the /etc/hosts file of course, but thats not helping now since it decided to use only ipv6 addressing according to an 'ifconfig eth0' report.
What do you mean by "configured by hand"?
By turning off dhcp for eth0 and filling in the hostname and address/mask data yourself. This small home network runs on the hosts file for address resolution till it hits the fireall box looking for an outside location.
On 7/13/05 6:34 AM, "Timothy Murphy" tim@birdsnest.maths.tcd.ie wrote:
As for IPv6, I think you can disable this by adding IPV6INIT=no to /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) and saying "service network restart" as root. (Or you could remove the IPv6 module from /lib/modules/<version>/ .)
You might also wish to add
alias net-pf-10 off
To /etc/modprobe.conf
This is a little easier than deleting the file from /lib/modules.
Steve
On Wed, 2005-07-13 at 22:27, Timothy Murphy wrote:
Some bugs aren't found until someone tries the combination of things that the program gets wrong. Reporting your lspci output and the module that is wrongly installed is probably the best you can do along with using whatever means you can to work around the bug.
Sigh. The machine does not run if I do a clean install,
So your workaround for the bug was to upgrade just so you kept the old modprobe.conf... Another approach that should have worked would have been to boot the install CD in rescue mode after your clean install failed to boot itself, add the correct line for the aic7xxx module, and rebuild the initrd image with the mkinitrd command. The difference is that now you don't know precisely what else you still have left over from the last system besides the part that luckily works around a new bug. The effects from the other parts may not be so lucky for you.
Guys,
This is getting annoying and ridiculous. For all the noise and hoo haa about capital letters, so many people have accepted and allowed this thread to go on i.e "WARNING: DO NOT UPGRADE TO CORE 4".
Please just terminate the thread, and move on. Its gone beyond the original scope of the thread.
Regards Dan
On Wednesday 13 July 2005 23:31, Gene Heskett wrote:
On Wednesday 13 July 2005 13:12, Timothy Murphy wrote:
Gene Heskett wrote:
On Wednesday 13 July 2005 09:34, Timothy Murphy wrote:
Gene Heskett wrote:
[...]
Neither did I. I just selected automatic disk partitioning on /dev/hda, and manual configuration of the network (which I did) as opposed to the default dhcp. And 'everything'...
And one more install seems to have found the planets & stars in favorable alignment. I got thru the install, networking is working (yaay) and yum -y update is now running. And I didn't do anything different except take a pci card that acted like a dumb isa card back out of the system. It was a triple 82C55 i/o card that had no bios rom on it whatsoever. This card, while not being overly friendly to an lspci -vv listing, has never effected any of the previous installs or boot sequences. Its been in that machine for about 6 months, but will not be used with the newer stepper drivers I just bought for emc's use.
This time it went thru the post install checks and let me setup the nv card & monitor pretty much to its full capabilities. Sound worked even. The acid test of course will be when I type 'switchdesk kde' and reboot after all the yum work is finished in a couple hours. And hopefully no power failures as there is not a ups on that box, unlike these 2 here. I'm up here on the eastern edge of whats left of Dennis & we've had intermittent showers since 3ish this afternoon. And it just started up again, this time having definitely found the instructions written on the heel. Half an hour of this will equal an inch of precip. The wind is gusty, to maybe 25 mph too.
Wish me luck, I may need it...
Looks like I do, need the luck that is. I did reboot ok without changing to kde yet, then logged in as gene & did an su (forgot the - sign though) and fired off a 'yum -y update' session. That failed after several hours due to a DSA key failure thats since scrolled off screen, the default history in a terminal is way too small at 1000 lines.
So the first question since I'm not that familiar with gnome, is how do I expand the shell history in gnome thats so easily done in kde?
Due to the above DSA key error it apparently didn't install/update all 279 of the updates it had counted.
Anyway, I fired off another run of 'yum -y update' thinking maybe that would self heal as mirrors got updated.
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
One line is being output at the bottom of the screen, the other about 10 lines down from the top, I've expanded the terminal screen height to full height on a 1280x1024 screen. And the machine is being lagged somewhat by all this of course. ctl+c's and ctl+d's on that window are being ignored.
Opening another terminal and doing an su -, I do a 'ps -ea|grep yum' to find its id, and I've issued 2 'kill 11066's now without effect.
I could just hit the reset button, but thats not very friendly, so I'll wait for advice from this group as to what to do next.
Another install, the 8th or 9th attempt now, is not a very appetizing thought. The cd's have been check-summed 2 times now by the disk 1's test facility.
FWIW, memtest86 ran for about 36 hours with no errors 3 weeks ago before I started all this headache.
Next?
On Thu, 2005-07-14 at 07:09 -0400, Gene Heskett wrote:
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
My deepest sentiments, but your rpmdb is broken very badly ;-)
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Ralf
On Thu, Jul 14, 2005 at 07:09:57AM -0400, Gene Heskett wrote:
So the first question since I'm not that familiar with gnome, is how do I expand the shell history in gnome thats so easily done in kde?
Right click, pick "Edit Current Profile", choose the tab "Scrolling", increase the Scrollback number, press Close.
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
Emmanuel
Les Mikesell wrote:
The machine does not run if I do a clean install,
So your workaround for the bug was to upgrade just so you kept the old modprobe.conf... Another approach that should have worked would have been to boot the install CD in rescue mode after your clean install failed to boot itself, add the correct line for the aic7xxx module, and rebuild the initrd image with the mkinitrd command.
Actually, as I explained early in this rather long thread that was exactly what I did, except that I used Knoppix rather than the Fedora CD, which for some reason did not work in rescue mode. I also had a second solution, which was not to format /boot (which is on a separate partition) so that old kernels were available, and I only had to restore the old grub.conf , which I did with a tomsrtbt floppy.
However, the only point I am trying to make is that when I followed the instructions to make a clean install it did not work, for reasons which I have already explained (many times).
The difference is that now you don't know precisely what else you still have left over from the last system besides the part that luckily works around a new bug. The effects from the other parts may not be so lucky for you.
I don't know what you mean. I have never had any problems of this kind when upgrading. The main advantage of upgrading as far as I am concerned is that you don't have to worry about re-writing CUPS config files, etc.
But my original point remains: people should not be so dogmatic about what works or does not work, based on their experience with one (or even several) machines. The fact that FC4 works without any problem on one machine does not show that it will work on every machine in the world, and that if it doesn't then the user must be a fool.
On the other hand, the fact that you have a problem installing FC-4 (or even three problems, like the OP) does not mean that Fedora is a disaster. It just means you have to knuckle down and analyse the cause of the failure.
On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
If you're lucky you can get away with it.
If you're even more lucky, the fix is to remove all gpg-key*'s from the db, the run rpm --rebuilddb and to re-import the gpg-keys (There had been a time when rpm screwed up badly on gpg-keys, some user might have inherited this problem from this time.)
If you're even yet more lucky, an "rpm --rebuilddb" helps.
If you're less lucky, your rpmdb is hosed in unrecoverable ways.
And if all goes wrong the file system or the hard disk underneath are damaged.
Except of the HW-failure case, I've seen all cases happening.
Ralf
Les Mikesell wrote:
The machine does not run if I do a clean install,
So your workaround for the bug was to upgrade just so you kept the old modprobe.conf...
No. I always run compiled kernels anyway, so it is not worth spending too much time working out why the distribution kernel does not work.
By the way, as you are so expert I wish you (or anyone else) could explain to me how I can do a clean install - or even an upgrade - on my Sony C1VFK Picturebook, as anaconda bombs out whether using CDs or hard-disk half way through the installation: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940.
The only way I have found is to upgrade by running "yum update" after altering /etc/fedora-release . If anyone can suggest another route I would be very interested.
On Thu, 14 Jul 2005, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
If you're lucky you can get away with it.
If you're even more lucky, the fix is to remove all gpg-key*'s from the db, the run rpm --rebuilddb and to re-import the gpg-keys (There had been a time when rpm screwed up badly on gpg-keys, some user might have inherited this problem from this time.)
If you're even yet more lucky, an "rpm --rebuilddb" helps.
If you're less lucky, your rpmdb is hosed in unrecoverable ways.
Even here, if you have the list of installed RPMs (see /var/log/rpmpkgs) and the RPMs themselves (say, all together in a directory), you should be able to reinitialize the db and then
rpm -ivh --justdb *.rpm
to repopulate it.
And if all goes wrong the file system or the hard disk underneath are damaged.
Except of the HW-failure case, I've seen all cases happening.
Ralf
On Thursday 14 July 2005 07:37, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 07:09 -0400, Gene Heskett wrote:
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
My deepest sentiments, but your rpmdb is broken very badly ;-)
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
How about a reset and when rebooted, if it will, doing an rpm --rebuilddb?
Ralf
On Thu, 2005-07-14 at 10:13 -0400, Gene Heskett wrote:
On Thursday 14 July 2005 07:37, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 07:09 -0400, Gene Heskett wrote:
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
My deepest sentiments, but your rpmdb is broken very badly ;-)
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
How about a reset and when rebooted, if it will, doing an rpm --rebuilddb?
C.f. to the parallel thread - If you're lucky, you can recover from this (backup /var/lib/rpm before any attempt to fix it).
Ralf
On Thu, 2005-07-14 at 06:09, Gene Heskett wrote:
Due to the above DSA key error it apparently didn't install/update all 279 of the updates it had counted.
Anyway, I fired off another run of 'yum -y update' thinking maybe that would self heal as mirrors got updated.
Usually I just do: "yum update" and if the list it shows includes yum or rpm I cancel and just get those first, then repeat for the rest of the packages.
On Thursday 14 July 2005 08:20, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
Emmanuel
I was going to follow these instructions, but there is no lib in the /mnt/sysimage/var path. None, nada, zip. I left it with memtest86 running, but I note something odd, I have a version 3.0 on a floppy thats many moons old now, but the version on the rescue cd says its 1.55. Why is a very valuable testing tool thats probably 6 or 7 years old being used today?
And, what happened to the boot option 'linux single' which used to mount everything in r/w & drop you to a shell? That did a normal boot up to the point where it should have started X, but x is now fubar & gets into a loop of a blue screen with an X, then going black, then repeat, each time doing it more slowly until the blue screen becomes contaminated with stray data. At that point I 3 fingered it.
FC4 looked pretty good, till I turned yum loose to update it, useing only the contents of /etc/yum.repo.d as just installed. And yum proved once more that it exists only to commit hari-kari. Only this time it took the whole, freshly installed & apparently 100% working, system down with it.
After memtest runs a couple of loops, I'm going to do a clean install one more time. But as a test, I'm going to reenable the main repo addresses in those files, screw the mirrors. Before I do a yum update again.
Seriously folks, stuff like this should never be allowed out the door, and we need an FC4-1 release that fixes whatever the hell is screwing this up.
But you have to understand that by now, there is no way in hell I'd touch this working FC2 system with an FC4 install. This one may not have a working yum, and has enough tarballs installed, largely because of FC2's long standing bugs re cups vs kde, that apt-get wants to remove about 90 packages from the heart of the system just to "clean it up".
yum seems intent on destroying yum, at least on this FC2 system. It never heard of the hypocratic oath, first, do no harm.
It was yum that destroyed yum here, by installing an incompatible libxml2.so that no one can tell me how to fix, other than going back to the original cd's and forceably reinstalling that yum and all the xml & python related stuff. I've done that three times now, but will have to burn another set of FC2 cd's before I can do that again. I ditched mine when FC4 final came out. Silly boy...
If and when I ever get an FC4 install working again, is there a sequence I should be using so that things get updated in the right order next time? Like resetting /etc/inittab to 3, so x isn't running when yum tries to update it, and other things like that need to be known? ?????
On Thursday 14 July 2005 09:11, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
If you're lucky you can get away with it.
If you're even more lucky, the fix is to remove all gpg-key*'s from the db, the run rpm --rebuilddb and to re-import the gpg-keys (There had been a time when rpm screwed up badly on gpg-keys, some user might have inherited this problem from this time.)
Yeah, but this is a fresh install, no (theoreticaly) leftovers
If you're even yet more lucky, an "rpm --rebuilddb" helps.
But in rescue mode /var/lib doesn't even exist. So an rpm -vv --rebuilddb cannot create its scratch files on a hardcoded /var/lib/
If you're less lucky, your rpmdb is hosed in unrecoverable ways.
And if all goes wrong the file system or the hard disk underneath are damaged.
With all fingers pointing at yum, the system was fine till then.
Except of the HW-failure case, I've seen all cases happening.
Ralf
I don't believe the disk is failing, I previously had smartd running on both disks with no problems.
On Thursday 14 July 2005 10:09, Matthew Saltzman wrote:
On Thu, 14 Jul 2005, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
If you're lucky you can get away with it.
If you're even more lucky, the fix is to remove all gpg-key*'s from the db, the run rpm --rebuilddb and to re-import the gpg-keys (There had been a time when rpm screwed up badly on gpg-keys, some user might have inherited this problem from this time.)
If you're even yet more lucky, an "rpm --rebuilddb" helps.
If you're less lucky, your rpmdb is hosed in unrecoverable ways.
Even here, if you have the list of installed RPMs (see /var/log/rpmpkgs) and the RPMs themselves (say, all together in a directory), you should be able to reinitialize the db and then
rpm -ivh --justdb *.rpm
to repopulate it.
Yes, and how valid will that be after yum has updated nearly 200 packages before it got a tummy ache over a keys checksum?
And if all goes wrong the file system or the hard disk underneath are damaged.
Except of the HW-failure case, I've seen all cases happening.
Ralf
-- Matthew Saltzman
Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs
On Thursday 14 July 2005 08:04, Matthew Miller wrote:
On Thu, Jul 14, 2005 at 07:09:57AM -0400, Gene Heskett wrote:
So the first question since I'm not that familiar with gnome, is how do I expand the shell history in gnome thats so easily done in kde?
Right click, pick "Edit Current Profile", choose the tab "Scrolling", increase the Scrollback number, press Close.
While it may work (I haven't tried it, the system is currently DOA again because yum died in mid-session) why is it so hidden? kde's terminals have it right out front as 'history', with an auto-inc-dec, or you can type into it, scrollbox to set the number of lines.
Thanks for the info, and I'll see if I can fix that if I ever get it going again, but this seemingly purposefull obtuseness of gnome is one of the reasons I much prefer kde. Frankly, the gnome attitude that the customer is never right so this stuff is hidden from an intuitive menu searching eye gets old, very old, very fast. Just like the constant nagging of root when he is trying to get something constructive done. Or has that been muffled in this version of gnome? Muffled, hell, I'd strangle it after about the 20th time I had to close a friggin popup.
-- Matthew Miller mattdm@mattdm.org http://www.mattdm.org/ Boston University Linux ------> http://linux.bu.edu/ Current office temperature: 75 degrees Fahrenheit.
On Thursday 14 July 2005 06:09, Gene Heskett wrote:
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
Several have been hit by this, me included. See..
http://www.google.com/search?hl=en&lr=&q=rpmdbNextIterator+rebuilddb...
I managed to recover by using the suggested fix here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122601
Regards, Mike Klinke
On Thursday 14 July 2005 10:44, Les Mikesell wrote:
On Thu, 2005-07-14 at 06:09, Gene Heskett wrote:
Due to the above DSA key error it apparently didn't install/update all 279 of the updates it had counted.
Anyway, I fired off another run of 'yum -y update' thinking maybe that would self heal as mirrors got updated.
Usually I just do: "yum update" and if the list it shows includes yum or rpm I cancel and just get those first, then repeat for the rest of the packages.
Chuckle, seems like the ideal way to do it, but when the package list is longer than the shells scrollback??????
Also if yum destroys itself, at least the rest of the system is spared. :( Don't laugh Mike, its done that here 6 times on 2 different machines and installs now.
-- Les Mikesell lesmikesell@gmail.com
Gene Heskett wrote:
FC4 looked pretty good, till I turned yum loose to update it, useing only the contents of /etc/yum.repo.d as just installed. And yum proved once more that it exists only to commit hari-kari. Only this time it took the whole, freshly installed & apparently 100% working, system down with it.
Sorry to be sceptical, but I'm not convinced there is anything wrong with yum.
I don't know how others read it, but to me you seem to have your own way of doing everything, and appear to be willing to re-install yet again at the drop of a hat without trying to work out what went wrong.
Eg you said that "FC4 looked pretty good", but you also said you had apparently insoluble problems with X. So which is it? Was FC4 working OK until you said "yum update"?
I must say I have never had a problem where yum did something it should not have done, though I've had several problems where it refused to update, the error in most cases turning out to be mine, though sometimes there were problems at the repositories. [I'm not entirely sure if the default repositories, as installed by FC-4, _are_ correct.]
From my experience, you need to be sure
that no non-standard repositories (such as livna, dag, fedora-devel, fedora-updates-testing, etc) are enabled. And it may be worth seeing that /etc/fedora-release does say "Fedora Core 4".
On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 10:09, Matthew Saltzman wrote:
On Thu, 14 Jul 2005, Ralf Corsepius wrote:
On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
If you're lucky you can get away with it.
If you're even more lucky, the fix is to remove all gpg-key*'s from the db, the run rpm --rebuilddb and to re-import the gpg-keys (There had been a time when rpm screwed up badly on gpg-keys, some user might have inherited this problem from this time.)
If you're even yet more lucky, an "rpm --rebuilddb" helps.
If you're less lucky, your rpmdb is hosed in unrecoverable ways.
Even here, if you have the list of installed RPMs (see /var/log/rpmpkgs) and the RPMs themselves (say, all together in a directory), you should be able to reinitialize the db and then
rpm -ivh --justdb *.rpm
to repopulate it.
Yes, and how valid will that be after yum has updated nearly 200 packages before it got a tummy ache over a keys checksum?
I didn't say it would be easy...
If you meet the prerequisites:
RPM db hosed, but files OK List of RPMs available RPMs (the versions that were installed) available GPG keys available
then it should recreate the db to match the installed system. If I missed that you couldn't satisfy these conditions for some reason, then just forget I said anything.
On Thu, Jul 14, 2005 at 11:25:14AM -0400, Gene Heskett wrote:
Right click, pick "Edit Current Profile", choose the tab "Scrolling", increase the Scrollback number, press Close.
While it may work (I haven't tried it, the system is currently DOA again because yum died in mid-session) why is it so hidden? kde's terminals have it right out front as 'history', with an auto-inc-dec, or you can type into it, scrollbox to set the number of lines.
Why do you say that it's hidden? It's a completely obvious preference. (The "Right click" thing is only because I'm not sure if you've hidden the menu bar or not -- if the menu bar is visibile, instead of right click, look on the edit menu.)
On Thu, 2005-07-14 at 08:02, Timothy Murphy wrote:
However, the only point I am trying to make is that when I followed the instructions to make a clean install it did not work, for reasons which I have already explained (many times).
Agreed: sometimes you have to do things that are not optimal to work around bugs or other pragmatic issues. My point is that you should realize that such workarounds may have other side effects.
The difference is that now you don't know precisely what else you still have left over from the last system besides the part that luckily works around a new bug. The effects from the other parts may not be so lucky for you.
I don't know what you mean. I have never had any problems of this kind when upgrading.
The fact that there are differences you don't know about may or may not ever result in problems. As you've seen, some things may even be better. The point is that it isn't predictable anymore.
The main advantage of upgrading as far as I am concerned is that you don't have to worry about re-writing CUPS config files, etc.
What do you expect to happen when new versions of programs installed during an upgrade have new options that would have values supplied in the config files provided by a fresh install but that is omitted in your inherited verson? This possibility is one of the main reasons that RH/Fedora distributions do not do application version-level updates within the same OS version lifetime but instead back in only essential bugfix and security patches trying not to change expected behavior or config requirements. Between OS versions, all such bets are off. Even worse, there may not be an exact correspondence between packages from one release to another so some things that should be replaced might not be. That fact that upgrades work at all shows that someone has put some effort into the process, but I wouldn't trust it to be a priority to get every little thing right even for the instances where there is a 'right' way.
But my original point remains: people should not be so dogmatic about what works or does not work, based on their experience with one (or even several) machines.
I'm not being dogmatic about not doing things like that to work around problems. I'm being dogmatic about understanding that such workarounds may make the machine unpredictable. If some other issues appear, you won't know without testing on other machines whether the problem was created by something inherited from a prior install or not.
On the other hand, the fact that you have a problem installing FC-4 (or even three problems, like the OP) does not mean that Fedora is a disaster. It just means you have to knuckle down and analyse the cause of the failure.
What I like to do is keep a copy of the entire /etc directory along with /home from the prior install. Then if there are any problems with the new version, diff the relevant config files between the two versions to see what made the old one work. This would be painful in your case of a scsi controller mismatch but for most other things you can get far enough to do that.
On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 08:20, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
Emmanuel
I was going to follow these instructions, but there is no lib in the /mnt/sysimage/var path. None, nada, zip. I left it with memtest86 running, but I note something odd, I have a version 3.0 on a floppy thats many moons old now, but the version on the rescue cd says its 1.55. Why is a very valuable testing tool thats probably 6 or 7 years old being used today?
Umm, there are two packages called Memtest86. The one at http://www.memtest86.com/ is at version 3.3. The one at http://www.memtest.org/ (actaully called memtest86+) is currently at version 1.60. The latter was forked from the former around version 3.0.
And, what happened to the boot option 'linux single' which used to mount everything in r/w & drop you to a shell? That did a normal boot up to the point where it should have started X, but x is now fubar & gets into a loop of a blue screen with an X, then going black, then repeat, each time doing it more slowly until the blue screen becomes contaminated with stray data. At that point I 3 fingered it.
Works for me if I add 'single' to the kernel line in Grub. Single-user mode should *not* attempt to start X.
If you are trying to boot in rescue mode from the rescue CD, type "linux rescue", not "linux single". The rescue CD won't try to start X either.
FC4 looked pretty good, till I turned yum loose to update it, useing only the contents of /etc/yum.repo.d as just installed. And yum proved once more that it exists only to commit hari-kari. Only this time it took the whole, freshly installed & apparently 100% working, system down with it.
After memtest runs a couple of loops, I'm going to do a clean install one more time. But as a test, I'm going to reenable the main repo addresses in those files, screw the mirrors. Before I do a yum update again.
Seriously folks, stuff like this should never be allowed out the door, and we need an FC4-1 release that fixes whatever the hell is screwing this up.
Look, lots of folks have installed FC4 and are regularly and successfully performing updates. I'm not saying there are no problems. I'm not saying that whatever unusual property of your system or unusual action that you've performed didn't uncover a bug (perhaps even a serious one). But you have to realize that it is impossible for the developers and beta testers to test with every hardware combination or to anticipate every crackpot sequence of actions that a user might take. When bugs are found, the bug finder and the developers need to work together to recreate and diagnose the problem. Then the developers need to fix it.
I haven't been following this thread very intently, but from skimming some of your earlier messages, it appears that you have some unusual configuration on the problem machine, with a couple of disks and a couple of versions of FC.
Maybe it would help to slow the process down and do some reasonableness and consistency checks after the install and before the updates. Then do the updates in chunks and see if you can narrow down where the failure occurs.
But you have to understand that by now, there is no way in hell I'd touch this working FC2 system with an FC4 install. This one may not have a working yum, and has enough tarballs installed, largely because of FC2's long standing bugs re cups vs kde, that apt-get wants to remove about 90 packages from the heart of the system just to "clean it up".
yum seems intent on destroying yum, at least on this FC2 system. It never heard of the hypocratic oath, first, do no harm.
It was yum that destroyed yum here, by installing an incompatible libxml2.so that no one can tell me how to fix, other than going back to the original cd's and forceably reinstalling that yum and all the xml & python related stuff. I've done that three times now, but will have to burn another set of FC2 cd's before I can do that again. I ditched mine when FC4 final came out. Silly boy...
If and when I ever get an FC4 install working again, is there a sequence I should be using so that things get updated in the right order next time? Like resetting /etc/inittab to 3, so x isn't running when yum tries to update it, and other things like that need to be known? ?????
You should be able to update a running X and then restart it. I've done it lots of times.
Thank you Dan!
On Thu, 2005-07-14 at 09:37 +0100, Dan Track wrote:
Guys,
This is getting annoying and ridiculous. For all the noise and hoo haa about capital letters, so many people have accepted and allowed this thread to go on i.e "WARNING: DO NOT UPGRADE TO CORE 4".
Please just terminate the thread, and move on. Its gone beyond the original scope of the thread.
Regards Dan
On Thu, 2005-07-14 at 10:28, Gene Heskett wrote:
Usually I just do: "yum update" and if the list it shows includes yum or rpm I cancel and just get those first, then repeat for the rest of the packages.
Chuckle, seems like the ideal way to do it, but when the package list is longer than the shells scrollback??????
The worst that will happen if you say yum update rpm yum as a separate first step is that you waste some time while it tells you that you already have the latest versions.
Also if yum destroys itself, at least the rest of the system is spared. :( Don't laugh Mike, its done that here 6 times on 2 different machines and installs now.
Sometimes I've been able to 'apt-get update; apt-get upgrade' to fix a yum-induced problem and sometimes I've had to do the opposite.
On Thursday 14 July 2005 11:27, Mike Klinke wrote:
On Thursday 14 July 2005 06:09, Gene Heskett wrote:
It said there were 78 packages in 870 megs to go and started downloading some more packages. I left it twiddling its own thumbs and came up here to check the mail. 20 mins later I unblank a very pretty screen to discover its outputting, at 2 locations on the same terminal window, continuous lines of:
error: rpmdbNextIterator: skipping #h 325 Header V3 DSA signature: BAD, key ID 4f2a6fd2
Several have been hit by this, me included. See..
http://www.google.com/search?hl=en&lr=&q=rpmdbNextIterator+rebuilddb ++Pubkeys+site%3Abugzilla.redhat.com&btnG=Search
I managed to recover by using the suggested fix here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122601
Regards, Mike Klinke
This last link appeared to contain the fix, thanks Mike. I got the db repaired, and then had yum update rpm and rpm-lib, then yum but no update there.
Then I fired a 'yum update' (in a "linux single" boot) off to go do the rest of it, 32 additional packages were downloaded, and 585 transactions were attempted. Lots of checksum failures, one of them in the all important kde3/launcher_panelapplet.so, and nearly 10 of them in the various openoffice-org-langpack files, mostly in the help tree, one in kmix/window.png, one in kstars/jupiter.L2.Vsop and in kbruch/convert.png.
I reran yum and it picked up only one of the openoffice-langpacks it had failed on before.
I changed /etc/inittab to boot to level 3 and exited the single shell expecting a reboot, but it went ahead and tried to finish the bootup from there. The runlevel 3 seemed to be fighting with something as it kept taking my login screen away in favor of an attempt to run x, but failed and looped back, eventually letting me login. But then, I mounted /dev/hdb1 as /mnt/bdi-boot intending to recover my emc install on /dev/hdb, and discovered that this partition, while a slightly different size according to a df report, was otherwise identical to /dev/hda1 currently mounted as /boot as far as its contents were concerned.
So my bdi install of emc on /dev/hdb is apparently toast. Thanks FC4, I had some drivers for that triple 82C55 card under developement there too. :-( So thats another wheel I may have to re-invent.
So I typed 'reboot'.
Now its stuck here:
OK, booting the kernel (this would be the updated one yum just installed I think) crc error Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
So WTF is wrong now?
On Thu, 2005-07-14 at 10:08, Gene Heskett wrote:
If you're even yet more lucky, an "rpm --rebuilddb" helps.
But in rescue mode /var/lib doesn't even exist. So an rpm -vv --rebuilddb cannot create its scratch files on a hardcoded /var/lib/
If you boot the install CD with 'linux rescue' at the prompt it should detect and mount your installed system under /mnt/sysinstall and suggest a chroot command for you to make repairs. After the chroot you should see your /var/lib in it's usual place.
Les Mikesell wrote:
On Thu, 2005-07-14 at 10:28, Gene Heskett wrote:
Usually I just do: "yum update" and if the list it shows includes yum or rpm I cancel and just get those first, then repeat for the rest of the packages.
Sometimes I've been able to 'apt-get update; apt-get upgrade' to fix a yum-induced problem and sometimes I've had to do the opposite.
In general I find it unwise to bootstrap an update to my update tool. (The exception is "rpm -Uvh rpm*.rpm". But then, in that case what choice do I have?) I normally use synaptic to update my (FC4) system, but if I find a new version of apt or synaptic in the list, I drop out and use yum to update those packages, then restart synaptic to repeat the upgrade. Cheers, Gordon Keehn
On Thursday 14 July 2005 11:54, Timothy Murphy wrote:
Gene Heskett wrote:
FC4 looked pretty good, till I turned yum loose to update it, useing only the contents of /etc/yum.repo.d as just installed. And yum proved once more that it exists only to commit hari-kari. Only this time it took the whole, freshly installed & apparently 100% working, system down with it.
Sorry to be sceptical, but I'm not convinced there is anything wrong with yum.
I don't know how others read it, but to me you seem to have your own way of doing everything, and appear to be willing to re-install yet again at the drop of a hat without trying to work out what went wrong.
Eg you said that "FC4 looked pretty good", but you also said you had apparently insoluble problems with X. So which is it?
Oh it looked pretty good, in 800x600, which to me is pretty gross resolution. This screen on this box is running at 1600x1200.
Was FC4 working OK until you said "yum update"?
As much as I tested seemed to work.
I must say I have never had a problem where yum did something it should not have done,
I've had the FC2 version of yum commit hari-kari 4 times now on a system upgraded to FC2, each and everytime it was by replaceing the distribution version of libxml2 with a newer one, which promptly broke python when it tries to import, due to unresolved references such as this one:
# yum check-update Traceback (most recent call last): File "/usr/bin/yum", line 22, in ? import yummain File "/usr/share/yum/yummain.py", line 31, in ? import yumcomps File "/usr/share/yum/yumcomps.py", line 4, in ? import comps File "/usr/share/yum/comps.py", line 5, in ? import libxml2 File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in ? import libxml2mod ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: undefined symbol: xmlNewDocPI
I rest my case. I can fix it by going back to the distro cd's and forceably reinstalling all the libxml2 stuff.
though I've had several problems where it refused to update, the error in most cases turning out to be mine, though sometimes there were problems at the repositories. [I'm not entirely sure if the default repositories, as installed by FC-4, _are_ correct.]
At this point neither am I. The base repos are disabled and a round robin mirror lookup is used instead.
From my experience, you need to be sure that no non-standard repositories (such as livna, dag, fedora-devel, fedora-updates-testing, etc) are enabled. And it may be worth seeing that /etc/fedora-release does say "Fedora Core 4".
A bit difficult to check when after the update, it won't even boot. See my message in the thread from hell everyone wants to kill.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
On Thursday 14 July 2005 12:36, Matthew Saltzman wrote:
On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 08:20, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me. http://www.rpm.org/hintskinks/repairdb/
Emmanuel
I was going to follow these instructions, but there is no lib in the /mnt/sysimage/var path. None, nada, zip. I left it with memtest86 running, but I note something odd, I have a version 3.0 on a floppy thats many moons old now, but the version on the rescue cd says its 1.55. Why is a very valuable testing tool thats probably 6 or 7 years old being used today?
Umm, there are two packages called Memtest86. The one at http://www.memtest86.com/ is at version 3.3. The one at http://www.memtest.org/ (actaully called memtest86+) is currently at version 1.60. The latter was forked from the former around version 3.0.
Any special reason for the fork? This one does seem faster, like some of the more time consuming bit twiddling tests are left out.
And, what happened to the boot option 'linux single' which used to mount everything in r/w & drop you to a shell? That did a normal boot up to the point where it should have started X, but x is now fubar & gets into a loop of a blue screen with an X, then going black, then repeat, each time doing it more slowly until the blue screen becomes contaminated with stray data. At that point I 3 fingered it.
Works for me if I add 'single' to the kernel line in Grub. Single-user mode should *not* attempt to start X.
If you are trying to boot in rescue mode from the rescue CD, type "linux rescue", not "linux single". The rescue CD won't try to start X either.
FC4 looked pretty good, till I turned yum loose to update it, useing only the contents of /etc/yum.repo.d as just installed. And yum proved once more that it exists only to commit hari-kari. Only this time it took the whole, freshly installed & apparently 100% working, system down with it.
After memtest runs a couple of loops, I'm going to do a clean install one more time. But as a test, I'm going to reenable the main repo addresses in those files, screw the mirrors. Before I do a yum update again.
Seriously folks, stuff like this should never be allowed out the door, and we need an FC4-1 release that fixes whatever the hell is screwing this up.
Look, lots of folks have installed FC4 and are regularly and successfully performing updates. I'm not saying there are no problems. I'm not saying that whatever unusual property of your system or unusual action that you've performed didn't uncover a bug (perhaps even a serious one). But you have to realize that it is impossible for the developers and beta testers to test with every hardware combination or to anticipate every crackpot sequence of actions that a user might take. When bugs are found, the bug finder and the developers need to work together to recreate and diagnose the problem. Then the developers need to fix it.
I haven't been following this thread very intently, but from skimming some of your earlier messages, it appears that you have some unusual configuration on the problem machine, with a couple of disks and a couple of versions of FC.
2 disks yes, but the other install, on the second disk (or it was anyway) was a debian based install of emc via the brain dead installer, version 4.08. It uses adeos to run machinery in realtime.
Maybe it would help to slow the process down and do some reasonableness and consistency checks after the install and before the updates. Then do the updates in chunks and see if you can narrow down where the failure occurs.
But you have to understand that by now, there is no way in hell I'd touch this working FC2 system with an FC4 install. This one may not have a working yum, and has enough tarballs installed, largely because of FC2's long standing bugs re cups vs kde, that apt-get wants to remove about 90 packages from the heart of the system just to "clean it up".
yum seems intent on destroying yum, at least on this FC2 system. It never heard of the hypocratic oath, first, do no harm.
It was yum that destroyed yum here, by installing an incompatible libxml2.so that no one can tell me how to fix, other than going back to the original cd's and forceably reinstalling that yum and all the xml & python related stuff. I've done that three times now, but will have to burn another set of FC2 cd's before I can do that again. I ditched mine when FC4 final came out. Silly boy...
If and when I ever get an FC4 install working again, is there a sequence I should be using so that things get updated in the right order next time? Like resetting /etc/inittab to 3, so x isn't running when yum tries to update it, and other things like that need to be known? ?????
You should be able to update a running X and then restart it. I've done it lots of times.
This ones always had problems doing any of that while x is running. But now yum has installed a new kernel, and it won't boot at all.
-- Matthew Saltzman
Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs
On Thursday 14 July 2005 12:09, Matthew Miller wrote:
On Thu, Jul 14, 2005 at 11:25:14AM -0400, Gene Heskett wrote:
Right click, pick "Edit Current Profile", choose the tab "Scrolling", increase the Scrollback number, press Close.
While it may work (I haven't tried it, the system is currently DOA again because yum died in mid-session) why is it so hidden? kde's terminals have it right out front as 'history', with an auto-inc-dec, or you can type into it, scrollbox to set the number of lines.
Why do you say that it's hidden? It's a completely obvious preference. (The "Right click" thing is only because I'm not sure if you've hidden the menu bar or not -- if the menu bar is visibile, instead of right click, look on the edit menu.)
Which doesn't seem to be visible for a non-root user.
-- Matthew Miller mattdm@mattdm.org http://www.mattdm.org/ Boston University Linux ------> http://linux.bu.edu/ Current office temperature: 77 degrees Fahrenheit.
On Thursday 14 July 2005 11:28, Gene Heskett wrote:
On Thursday 14 July 2005 10:44, Les Mikesell wrote:
On Thu, 2005-07-14 at 06:09, Gene Heskett wrote:
Due to the above DSA key error it apparently didn't install/update all 279 of the updates it had counted.
Anyway, I fired off another run of 'yum -y update' thinking maybe that would self heal as mirrors got updated.
Usually I just do: "yum update" and if the list it shows includes yum or rpm I cancel and just get those first, then repeat for the rest of the packages.
Chuckle, seems like the ideal way to do it, but when the package list is longer than the shells scrollback??????
Also if yum destroys itself, at least the rest of the system is spared. :( Don't laugh Mike, its done that here 6 times on 2 different machines and installs now.
Make that 7 times, it just ate the system again.
-- Les Mikesell lesmikesell@gmail.com
-- 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.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Thu, 2005-07-14 at 10:04, Gene Heskett wrote:
And, what happened to the boot option 'linux single' which used to mount everything in r/w & drop you to a shell?
It still works. When you used lilo to boot, you could type that at the boot prompt. With grub you just have to edit the kernel line before booting and add the 'single' option.
Seriously folks, stuff like this should never be allowed out the door, and we need an FC4-1 release that fixes whatever the hell is screwing this up.
The Fedora project has never bothered to rebuild the isos for a released version. Usually the k12ltp project will release a version that adds some new things and include the FC updates up to that point. Installing from their isos can save a lot of time adding updates even if you don't include their added packages. They appear to be a few days from a release based on FC4. Their web pages tend to be out of date but you can find the releases here: ftp://k12linux.mesd.k12.or.us/pub/K12LTSP/ when the files under 4.4.0/isos stop having -pre in the names it will be the released version.
On Thursday 14 July 2005 14:48, Les Mikesell wrote:
On Thu, 2005-07-14 at 10:04, Gene Heskett wrote:
And, what happened to the boot option 'linux single' which used to mount everything in r/w & drop you to a shell?
It still works. When you used lilo to boot, you could type that at the boot prompt. With grub you just have to edit the kernel line before booting and add the 'single' option.
Which is finally what I did.
Seriously folks, stuff like this should never be allowed out the door, and we need an FC4-1 release that fixes whatever the hell is screwing this up.
The Fedora project has never bothered to rebuild the isos for a released version. Usually the k12ltp project will release a version that adds some new things and include the FC updates up to that point. Installing from their isos can save a lot of time adding updates even if you don't include their added packages. They appear to be a few days from a release based on FC4. Their web pages tend to be out of date but you can find the releases here: ftp://k12linux.mesd.k12.or.us/pub/K12LTSP/ when the files under 4.4.0/isos stop having -pre in the names it will be the released version.
Bookmarked, thanks.
-- Les Mikesell lesmikesell@gmail.com
On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 12:36, Matthew Saltzman wrote:
Umm, there are two packages called Memtest86. The one at http://www.memtest86.com/ is at version 3.3. The one at http://www.memtest.org/ (actaully called memtest86+) is currently at version 1.60. The latter was forked from the former around version 3.0.
Any special reason for the fork? This one does seem faster, like some of the more time consuming bit twiddling tests are left out.
According to the memtest.org site, it looked in 2004 like the original was abandonware. Apparently the original package is being maintained again, but some of the 3.2 update came from the fork's 1.30. Incestuous, isn't it?
At 2:33 PM -0400 7/14/05, Gene Heskett wrote:
On Thursday 14 July 2005 12:09, Matthew Miller wrote:
On Thu, Jul 14, 2005 at 11:25:14AM -0400, Gene Heskett wrote:
Right click, pick "Edit Current Profile", choose the tab "Scrolling", increase the Scrollback number, press Close.
While it may work (I haven't tried it, the system is currently DOA again because yum died in mid-session) why is it so hidden? kde's terminals have it right out front as 'history', with an auto-inc-dec, or you can type into it, scrollbox to set the number of lines.
Why do you say that it's hidden? It's a completely obvious preference. (The "Right click" thing is only because I'm not sure if you've hidden the menu bar or not -- if the menu bar is visibile, instead of right click, look on the edit menu.)
Which doesn't seem to be visible for a non-root user.
The terminal menu bar is visible by default. Feel free to enable it in terminal's preferences (that right-click thing again). ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
On Thursday 14 July 2005 16:55, Matthew Saltzman wrote:
On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 12:36, Matthew Saltzman wrote:
Umm, there are two packages called Memtest86. The one at http://www.memtest86.com/ is at version 3.3. The one at http://www.memtest.org/ (actaully called memtest86+) is currently at version 1.60. The latter was forked from the former around version 3.0.
Any special reason for the fork? This one does seem faster, like some of the more time consuming bit twiddling tests are left out.
According to the memtest.org site, it looked in 2004 like the original was abandonware. Apparently the original package is being maintained again, but some of the 3.2 update came from the fork's 1.30. Incestuous, isn't it?
Rather. :)
-- Matthew Saltzman
Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs
On Wed, 2005-13-07 at 14:42 +0100, Timothy Murphy wrote:
M.Lewis wrote:
I installed FC4 last night. Tonight I was doing yum upgrades. I didn't touch a thing. I just gave the command yum -y upgrade. Everything started downloading fine. 279 packages I think it was. Sound works, just plug in the speakers, no fiddling with anything.
I decided to reinstall though as the partitioning wasn't what I wanted. Not FC4's fault, it was mine. I should have paid more attention during the partitioning last night.
Other than the reinstall due to my lack of attention, I was quite pleased with what I saw. NO PROBLEMS.
Perhaps one of the key issues here backup your data, DO A CLEAN INSTALL.
You seem to me to be somewhat lacking in imagination. "I have never had a crash in my car. KEEP YOUR CAR CLEAN."
Consider the possibility that an installation might not work on machine X, but an upgrade might.
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
I've been on these lists since ver 5.2 I believe it was. There are several others who have been here perhaps longer than me. I have NEVER done an UPGRADE. Always a clean install. I simply do not have the issues that I see people complaining about here.
Consider the possibility that this is because you are using a different computer.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Guy Fraser wrote:
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
At 1:32 PM +0100 7/16/05, Timothy Murphy wrote:
Guy Fraser wrote:
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
Or maybe he does this to save time. It's only a few extra commands to a *nix expert (though I'd need time to figure it out): tar, mkdir, tar, and diff. Should be faster than troubleshooting it instead. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
Tony Nelson wrote:
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
Or maybe he does this to save time. It's only a few extra commands to a *nix expert (though I'd need time to figure it out): tar, mkdir, tar, and diff. Should be faster than troubleshooting it instead.
Are there actually any config files under /home which are affected by installing or upgrading? Which user do they belong to?
Does this affect fresh installs? I am about to do a fresh install of core 4 on a machine and then copy data over from a rh9 install
On Jul 16, 2005, at 1:59 PM, Timothy Murphy wrote:
Tony Nelson wrote:
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
Or maybe he does this to save time. It's only a few extra commands to a *nix expert (though I'd need time to figure it out): tar, mkdir, tar, and diff. Should be faster than troubleshooting it instead.
Are there actually any config files under /home which are affected by installing or upgrading? Which user do they belong to?
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
At 2:03 PM -0500 7/16/05, Jeffrey Lee wrote:
On Jul 16, 2005, at 1:59 PM, Timothy Murphy wrote:
Tony Nelson wrote:
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
Or maybe he does this to save time. It's only a few extra commands to a *nix expert (though I'd need time to figure it out): tar, mkdir, tar, and diff. Should be faster than troubleshooting it instead.
Are there actually any config files under /home which are affected by installing or upgrading? Which user do they belong to?
Sure. They belong to each user. Look for hidden files and directories. Lots of config and settings files in ~. Feel free to experiment.
Does this affect fresh installs? I am about to do a fresh install of core 4 on a machine and then copy data over from a rh9 install
Just be careful about what you copy over. In general, all of /etc, and hidden files and directories (starting with a ".") contain settings. If you copy an entire home directory, it will copy the hidden files as well. The old settings may work, or maybe they won't. If you overwrite directories, you could lose stuff. Better to compare and merge with the new /etc, or a new user account, using, say, diff (man diff, -r option I think). This goes for the various home directories and /etc at least, but I'm too new to *nix to know what else. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
Tony Nelson wrote:
Are there actually any config files under /home which are affected by installing or upgrading? Which user do they belong to?
Sure. They belong to each user. Look for hidden files and directories. Lots of config and settings files in ~. Feel free to experiment.
I guess my remark was a bit silly. But in fact I've never had any problem using dot files in my /home directory from previous installations.
I just looked at these files, and the only rpmnew version seems to be of bash_logout, which is strange since I certainly never changed that.
I definitely don't want to spend hours combing through .bash_profile and .bash_rc, etc, every time I upgrade.
To me this would be a bit like going through my wallet every time I change my jacket.
On Sat, 2005-07-16 at 13:32 +0100, Timothy Murphy wrote:
Guy Fraser wrote:
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
There is no "quick" way to update a server (or any other machine that's actually being used). Somehow you're going to have to move your configuration files forward to the new release.
If you go the "upgrade" route then rpm will identify lots of files that may need changes making (by creating .rpmsave/.rpmnew files) but you still may need to do some manual package maintenance (e.g. removing packages no longer part of the distribution [e.g. some of the emacs packages in FC4], adding in optional new packages [e.g. evince in FC4]). Per-user configuration files like ~/.gnome* won't get changed if you do an upgrade, so for instance if you do an FC2->FC3 upgrade, you'll still have one panel in gnome rather than the FC3 default of two.
If you go the "install" route then you'll have to identify for yourself the configuration files you'll need to move forward, and save and restore those files. You won't have any accumulated package cruft though, which will save some post-install time removing and adding packages. If you retain /home as an unaltered partition then you'll still have the issues with per-user configuration files as with the upgrade route.
So there's no easy way and what's best for one person isn't necessarily best for anyone else.
Paul.
On Sat, 2005-16-07 at 13:32 +0100, Timothy Murphy wrote:
Guy Fraser wrote:
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
No, not really. Using diff and other command line 'filters', it doesn't take too long to find necessary changes.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
On Thu, Jul 28, 2005 at 03:20:21PM -0600, Guy Fraser wrote:
On Sat, 2005-16-07 at 13:32 +0100, Timothy Murphy wrote:
Guy Fraser wrote:
Also consider the possibility that it might make more sense to keep /home on a separate partition, and leave this alone even if installing.
That can and does cause problems as well.
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
No, not really. Using diff and other command line 'filters', it doesn't take too long to find necessary changes.
I did this upgrade fro FC# to FC4. All of my problems were resolved by doing a yum update. But maybe other people have different problems.
Guy Fraser wrote:
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
No, not really. Using diff and other command line 'filters', it doesn't take too long to find necessary changes.
I see that I have 325 files in .kde/share/config/ alone , many if not most of which are presumably altered when using a system for a long time. Do you really go through all these each time a new version of Fedora comes out?
As I said, you must have lots of free time.
At 2:45 PM +0100 7/29/05, Timothy Murphy wrote:
Guy Fraser wrote:
Using old configuration files can and does cause lots of problems when the software that uses them is updated, that includes to user level config files in the home directories.
Unless the update process has a way of updating all the configuration files under /home it is better to tar it up and store it somewhere. You can restore it in an alternate location and move the files that don't exist after the upgrade then use diff to determine what needs to changed in with the files that are left.
That is basically what I do when I upgrade a server.
You must have lots of spare time on your hands.
No, not really. Using diff and other command line 'filters', it doesn't take too long to find necessary changes.
I see that I have 325 files in .kde/share/config/ alone , many if not most of which are presumably altered when using a system for a long time. Do you really go through all these each time a new version of Fedora comes out?
As I said, you must have lots of free time.
No, he doesn't, or it wouldn't have taken him so long to respond. He's just a more able *nix user than you or I, and uses the commands to batch the process. He doesn't have to do anything with the files that turn out to have no differences. Files that have differences need consideration, and some of them must be merged, but that is by far the fastest way to keep one's old settings and still have the new system function properly. The whole process probably takes him less than an hour, while ignoring the issue would lead to debugging it over a period of months, taking up days of time, at least. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
Les Mikesell wrote:
The machine does not run if I do a clean install,
So your workaround for the bug was to upgrade just so you kept the old modprobe.conf...
No. I always run compiled kernels anyway, so it is not worth spending too much time working out why the distribution kernel does not work.
By the way, as you are so expert I wish you (or anyone else) could explain to me how I can do a clean install - or even an upgrade - on my Sony C1VFK Picturebook, as anaconda bombs out whether using CDs or hard-disk half way through the installation: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160940.
The only way I have found is to upgrade by running "yum update" after altering /etc/fedora-release . If anyone can suggest another route I would be very interested.
-
akonstam＠trinity.edu -
Albert Hawker -
Amadeus W.M. -
Andy Green -
Beartooth -
Ben Steeves -
Brian Millett -
BRUCE STANLEY -
Dan Track -
Dan Trainor -
Deron Meranda -
Don Dupy -
Emmanuel Seyman -
Fred Morcos -
Gene Heskett -
Gordon Keehn -
Guy Fraser -
Jeffrey Lee -
Josh Coffman -
Kevin Waterson -
Les Mikesell -
M. Lewis -
Matthew Miller -
Matthew Saltzman -
Michael -
Mike Klinke -
Mike McCarty -
Patrick -
Paul Howarth -
Rahul Sundaram -
Ralf Corsepius -
Res -
Stefan Held -
Steven W. Orr -
Thomas Taylor -
Timothy Murphy -
Tony Nelson -
»Steven Ringwald« -
Øyvind Stegard