mcfreemind@gmail.com wrote:
Thanks for the more helpful info. How to update FC4 when the laptop can't connect to internet? I installed Fedora4 via a DVD in a book.
Thanks, Min
If you have a working, built-in NIC (wired), you'll need to find someone who will let you connect to their LAN and then download the updates using yum. If that isn't feasible but you have access to a system that has access to the internet, you can download and burn CD images of the unofficial FC4 release 2 ISO images and re-install.
Sorry. No good answers that I'm aware of that don't require internet access.
Dave
Status I was Running FC3 on a PC platform ( 64 bit Intel P4 Prescott 630 in Foxconn mother board). When I tried to upgrade the FC with rpm I had trouble with my network timing out. Disc is a SATA drive Root file system is LVM
I decided to upgrade to FC4. I did a clean install and formatted the disc space. I turned on Samba and few other minor configuration updates. (reinstalled my user directory to get my email back) I did run find from root without any failures.
I tried to update with RPM but the network timed out. I am having the same network time outs on my wife's Mac and a new wintel XP laptop.
I switched to Yum and the update proceeded smoothly but took 3 hours.
Here is where the problems start. I was searching for HelixPlayer to see if it was on the system. Find returned an error " incorrect hard link count in /proc usually a disc driver problem" I decided to reboot to see if the disc would run FSCK. The boot process hung at the same place 2 starting network loopback
I stopped the boot the next time and reverted to the old kernel believing that the disc drivers are in the kernel. (June FC4 install discs ) This worked and the system boots. Appears to be fully functional. I tried a "find" and got the same file system error in /proc directory.
So I thought I would check if this is a known problem.
I assume next steps would be to run FSCK on root disc. ( I do not have experience with LVM and FSCK)
I would like any advice on trouble shooting which update is causing the problems. I wanted the FC4-64bit see if there was a performance difference. I can go back and reinstall FC and manage the Yum update more tightly.
Tony Foster
Cell 916 300 7701 Tony_Foster@surewest.net
"Any sufficiently advanced technology is virtually indistinguishable from magic." (Arthur C. Clarke)
Tony Foster wrote:
I was Running FC3 on a PC platform ( 64 bit Intel P4 Prescott 630 in Foxconn mother board). When I tried to upgrade the FC with rpm I had trouble with my network timing out. Disc is a SATA drive Root file system is LVM
<snip>
I tried to update with RPM but the network timed out. I am having the same network time outs on my wife's Mac and a new wintel XP laptop.
What sort of Internet connection do you have? As I'd look into issues there...
Is there any sort of wireless involved? If it's DSL, how fast is it, and how far from the exchange are you?
Try "ping google.com" for several hours, and see how many packets you drop.
If you lose 1% or more, try traceroute google.com, and ping some of the first hosts on the list.
I switched to Yum and the update proceeded smoothly but took 3 hours.
Here is where the problems start. I was searching for HelixPlayer to see if it was on the system. Find returned an error " incorrect hard link count in /proc usually a disc driver problem"
Firstly, /proc isn't on the hard disk. It's a virtual filesystem, not ext3. There's no way (and no point) to fsck it.
This is an incompatibility between the proc filesystem and find. It's a known issue.
Dave Jones (Red Hat kernel guy) says an upgraded kernel should help: https://www.redhat.com/archives/fedora-list/2005-August/msg04746.html
You should try to get a recent kernel working. Since you say you're on x86-64, try http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/x86_64/ Download and rpm -i some of the recent kernel-* packages, and see if you can find one that works. Presumably you've got hyperthreading on that CPU, so you should really use the kernel-smp-* packages, but you may find a non-SMP version works better.
Hope this helps,
James.
-----Original Message----- From: James Wilkinson [mailto:fedora@westexe.demon.co.uk] Sent: Monday, December 05, 2005 1:27 PM To: Tony Foster Cc: 'For users of Fedora Core releases' Subject: Re: Problem booting after Yum update of FC4
Tony Foster wrote:
I was Running FC3 on a PC platform ( 64 bit Intel P4 Prescott 630 in
Foxconn
mother board). When I tried to upgrade the FC with rpm I had trouble
with my
network timing out. Disc is a SATA drive Root file system is LVM
<snip>
I tried to update with RPM but the network timed out. I am having the
same
network time outs on my wife's Mac and a new wintel XP laptop.
What sort of Internet connection do you have? As I'd look into issues there...
Is there any sort of wireless involved? If it's DSL, how fast is it, and how far from the exchange are you?
Try "ping google.com" for several hours, and see how many packets you drop.
If you lose 1% or more, try traceroute google.com, and ping some of the first hosts on the list.
[Tony Foster] DSL provider is the problem. Old DSL modem (384Mbits) that they would like me to go for a 10Mbit service and get a new modem. All machines in the house go through these time outs. (win XP; MAC OSX; ) the linux machine does better then any of the others. Right around 20Mbytes the network hits a wall and slows way down. I will try your suggestions to get documentation to push on the ISP to replace old modem or upgrade me for free.
I switched to Yum and the update proceeded smoothly but took 3 hours.
Here is where the problems start. I was searching for HelixPlayer to see if it was on the system. Find returned an error " incorrect hard link count in /proc usually a disc driver problem"
Firstly, /proc isn't on the hard disk. It's a virtual filesystem, not ext3. There's no way (and no point) to fsck it.
[Tony Foster] I used to be a strong user of UNIX when I did real software devel. I suspect that Proc was a special case directory. The pre 7.0 unix did not use this model.
This is an incompatibility between the proc filesystem and find. It's a known issue.
Dave Jones (Red Hat kernel guy) says an upgraded kernel should help: https://www.redhat.com/archives/fedora-list/2005-August/msg04746.html
[Tony Foster] I let Yum grab the most recent released kernel. I will investigate the pointer to new kernels. I bailed since I had not seen any responses and reloaded the system from FC4 install. I am in the process of updating again. Thanks for the info on "find" problem. Again I will investigate the pointers.
You should try to get a recent kernel working. Since you say you're on x86-64, try http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/x86_64/ Download and rpm -i some of the recent kernel-* packages, and see if you can find one that works. Presumably you've got hyperthreading on that CPU, so you should really use the kernel-smp-* packages, but you may find a non-SMP version works better.
[Tony Foster] Yes this CPU is a hyper threading unit. I did have to go back to a non SMP kernel to get the system through boot and stable.
Hope this helps,
James.
-- E-mail address: james | In the Royal Air Force a landing's OK, @westexe.demon.co.uk | If the pilot gets out and can still walk away. | But in the Fleet Air Arm the outlook is grim, | If your landings are duff and you've not learnt to swim.
[Tony Foster]
Tony Foster
Tony_Foster@surewest.net
"Any sufficiently advanced technology is virtually indistinguishable from magic." (Arthur C. Clarke)
On Mon, 2005-12-05 at 21:27 +0000, James Wilkinson wrote:
Try "ping google.com" for several hours, and see how many packets you drop.
I hope you don't mean continuously. That would constitute abuse.
I suggested:
Try "ping google.com" for several hours, and see how many packets you drop.
Tim wrote:
I hope you don't mean continuously. That would constitute abuse.
That's a fairly harsh definition of abuse you've got.
They've made the ping service available in the same way as they make the HTTP service available. Accessing Google's web pages once a second would not be OTT for a suitably busy site.
Continuous pinging *is* necessary occasionally as a form of network diagnostic: it tells the network administrator whether (and in conjunction with traceroute, where) to complain about network timeouts.
I selected Google partly because of the size and capacity of their servers and network connections.
I don't think I'm abusing Google. I'm using the facilities they make available in the way they're supposed to be used. And I'm not taking anywhere *near* unreasonably large amounts of resources to do so.
So why do you think it's abuse?
James.
someone suggested:
Try "ping google.com" for several hours, and see how many packets you drop.
Tim:
I hope you don't mean continuously. That would constitute abuse.
James Wilkinson:
That's a fairly harsh definition of abuse you've got.
They've made the ping service available in the same way as they make the HTTP service available. Accessing Google's web pages once a second would not be OTT for a suitably busy site.
What makes you think that Google has provided you with a ping responder? Many systems respond to ping, but that's often a default behaviour, most of them won't have deliberately provided you with something for doing ping tests with. It's a bit like saying most ISPs will let spam through their systems, so sending spam is okay.
I think that you'd find that many would consider such pinging to be an abuse of their services, I certainly would.
Continuous pinging *is* necessary occasionally as a form of network diagnostic: it tells the network administrator whether (and in conjunction with traceroute, where) to complain about network timeouts.
Fair enough, but do such things with the consent of the equipment owners. If you're testing your equipment, do so against someone that doesn't mind it.
I selected Google partly because of the size and capacity of their servers and network connections.
I don't think I'm abusing Google. I'm using the facilities they make available in the way they're supposed to be used. And I'm not taking anywhere *near* unreasonably large amounts of resources to do so.
As before, what makes you think that Google has provided you with a ping responder for such tests?
Tim wrote:
someone suggested:
Try "ping google.com" for several hours, and see how many packets you drop.
Tim:
I hope you don't mean continuously. That would constitute abuse.
James Wilkinson:
That's a fairly harsh definition of abuse you've got.
It fits mine. It's not an attack, but it is an abuse. Having a ping test for 30 sec or so probably wouldn't bother anyone, but running it "for several hours" would sure fit my definition of "abuse".
They've made the ping service available in the same way as they make the HTTP service available. Accessing Google's web pages once a second would not be OTT for a suitably busy site.
What makes you think that Google has provided you with a ping responder?
Exactly, right on the mark, correct.
[snip continuous pinging sometimes necessary]
Fair enough, but do such things with the consent of the equipment owners. If you're testing your equipment, do so against someone that doesn't mind it.
Yep. Or buy your own.
This guy sounds like "it doesn't matter that I broke into the car repair shop and used the tools there, because I put them all back when I was through with them."
I suggest this: do you have a router? Try pinging that. I use a router between my DSL modem and my machine. It responds to pings. So does my DSL modem, for that matter.
$ ping dslmodem PING dslmodem (192.168.0.1) 56(84) bytes of data. 64 bytes from dslmodem (192.168.0.1): icmp_seq=0 ttl=63 time=2.60 ms 64 bytes from dslmodem (192.168.0.1): icmp_seq=1 ttl=63 time=1.26 ms 64 bytes from dslmodem (192.168.0.1): icmp_seq=2 ttl=63 time=1.19 ms
--- dslmodem ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 1.194/1.689/2.606/0.649 ms, pipe 2
$ ping router PING router (172.17.100.199) 56(84) bytes of data. 64 bytes from router (172.17.100.199): icmp_seq=0 ttl=127 time=0.562 ms 64 bytes from router (172.17.100.199): icmp_seq=1 ttl=127 time=0.579 ms 64 bytes from router (172.17.100.199): icmp_seq=2 ttl=127 time=0.569 ms 64 bytes from router (172.17.100.199): icmp_seq=3 ttl=127 time=0.570 ms 64 bytes from router (172.17.100.199): icmp_seq=4 ttl=127 time=0.571 ms 64 bytes from router (172.17.100.199): icmp_seq=5 ttl=127 time=0.565 ms
--- router ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 4999ms rtt min/avg/max/mdev = 0.562/0.569/0.579/0.020 ms, pipe 2
[snip]
Mike
I tend to agree that more then a couple of minutes would be abusive. I was not planning on trying that test model. I can understand some value in pointing out that this could be abusive and easily traced back to the sender. So for others viewing this string the discussion was necessary. Bottom line if you are using others equipment to trouble shoot your problems make sure you have agreement/permission.
Status of the original problem I reinstalled the FC4 core system on a clean disk AGAIN. I instaalled the desktop environment instead of the server environment and ran a find immediately. The issue with find and the /proc directory tree was present.
I updated the system with Yum and in this case it booted fine. Kernel id 2.6.11-1.1644SMP So I reran find and now I get the error in the /sys directory tree so I still do not have a kernel that is robust. Does anyone have a kernel ID that is known to resolve this issue. I can run find from / as long as I exclude the /sys directory tree.
Tony Foster
Cell 916 300 7701 Tony_Foster@surewest.net
"Any sufficiently advanced technology is virtually indistinguishable from magic." (Arthur C. Clarke)
I suggested:
Try "ping google.com" for several hours, and see how many packets you drop.
in response to a post implying intermittent network problems.
Tim objected:
I hope you don't mean continuously. That would constitute abuse.
I said:
That's a fairly harsh definition of abuse you've got.
Mike McCarty wrote:
It fits mine. It's not an attack, but it is an abuse.
OK. Two people have told me "it's abuse". So I should at least take the objection seriously. You're telling me it's not a denial of service attack (which is reasonable), or an attempt to harm Google. You're telling me I'm suggesting using a service Google provides in a way that is not reasonable.
I maintain that * it's necessary in the particular case to which I was responding (at least to do this to somewhere in the Internet)
* Google are competent enough to understand that if they provide a ping service, people are likely to use it for the normal, expected purposes of that service.
* Google are competent enough to know they're providing a ping service.
* if someone provides a public service (e.g. a footpath), in the absence of any contrary signs or an attempt to keep the public out, there is an implied license to use that service in a reasonable manner.
Unfortunately, in order to diagnose certain sorts of network problems, this sort of activity is necessary. Especially when you have intermittent problems when only a few packets get dropped. Sometimes you will get about 20% packet drops over a few minutes in a period of a couple of hours.
Ping is the standard network tool for this sort of diagnosis, along with traceroute. They're about *the* standard TCP/IP diagnostic tool, and every version of ping I've seen has helpfully given you at the end figures for how many and what proportion of packets were dropped. It's reasonable that if people are interested in how many packets are dropped, they'll run the tool and look at the output.
I maintain that from the original posting, implying transient and intermittent network problems, something like this would have been necessary for diagnosis (if only to rule out low-level network problems).
I suppose I could have suggested his ISP's main web site instead.
This guy sounds like "it doesn't matter that I broke into the car repair shop and used the tools there, because I put them all back when I was through with them."
I'm sorry, I don't think this analogy works. It implies I "broke through" some sort of technical or signposted barrier.
A better one might be that someone provided a water fountain, and I suggested one might fill a few water bottles from it, in the absence of any signs to the contrary, and in such a way as not to deny the use of the fountain to anyone else.
In this case, the question really becomes "how many is too much"?
I suggest this: do you have a router? Try pinging that. I use a router between my DSL modem and my machine. It responds to pings. So does my DSL modem, for that matter.
I don't think you read the original post. It was reasonable to suspect intermittent networking problems anywhere between the Original Poster and the rest of the Internet, but not certain.
In particular, it was quite reasonable (and turned out to be the case) that the problem was on the far side of the router. In which case, pinging the router would not have shown much.
Sometimes, in troubleshooting, especially when each step has to be reported back over e-mail to a list for further instructions, it helps to test several things at once, and then drill down to see exactly which one was at fault.
James.
James Wilkinson wrote:
I suggested:
Try "ping google.com" for several hours, and see how many packets you drop.
[snip]
OK. Two people have told me "it's abuse". So I should at least take the objection seriously. You're telling me it's not a denial of service attack (which is reasonable), or an attempt to harm Google. You're telling me I'm suggesting using a service Google provides in a way that is not reasonable.
Umm, ping response is not a service, in the sense you are using it. They may have it there only to check their equipment, not yours. In order to find out why Google has ping response running, you'd have to ask them.
I maintain that
- it's necessary in the particular case to which I was responding (at least to do this to somewhere in the Internet)
Possibly. Tell you what, how about *you* "provide a ping service" to this fellow, and let him ping you for a few hours? That way, everyone (especially the folks at Google) will be happy.
[snip]
Unfortunately, in order to diagnose certain sorts of network problems, this sort of activity is necessary. Especially when you have intermittent problems when only a few packets get dropped. Sometimes you will get about 20% packet drops over a few minutes in a period of a couple of hours.
Yep. So how about you offer to let this guy ping you for a few hours straight?
[snip]
This guy sounds like "it doesn't matter that I broke into the car repair shop and used the tools there, because I put them all back when I was through with them."
I'm sorry, I don't think this analogy works. It implies I "broke through" some sort of technical or signposted barrier.
Ok, that's reasonable. I withdraw the analogy.
A better one might be that someone provided a water fountain, and I suggested one might fill a few water bottles from it, in the absence of any signs to the contrary, and in such a way as not to deny the use of the fountain to anyone else.
In this case, the question really becomes "how many is too much"?
Yes. As I pointed out 30 or so pings would probably be ok, and perhaps not even noticed. Hours on end is a very different thing.
There's a difference between filling a few water bottles, and watering your lawn using your next door neighbor's faucet.
So I agree, it's a matter of degree.
[snip]
Mike
On Thu, 2005-12-08 at 17:37 +0000, James Wilkinson wrote:
I maintain that
- it's necessary in the particular case to which I was responding (at least to do this to somewhere in the Internet)
What makes you think you need to ping continuously for a few hours? Ping for a bit, fiddle with settings, ping a bit more, but not continuously. This sounds like uneducated fiddling that you're proposing to do something so prolonged.
- Google are competent enough to understand that if they provide a ping service, people are likely to use it for the normal, expected purposes of that service.
Perhaps they might expect that people mightn't abuse the privilege and only ping to an acceptable amount.
- if someone provides a public service (e.g. a footpath), in the absence of any contrary signs or an attempt to keep the public out, there is an implied license to use that service in a reasonable manner.
Try reading some etiquette, etc., guides. No doubt you'll find advice about pinging (don't abuse ping responders, ask permission, etc.). It's incumbent upon you to use what's available sensibly and appropriately.
Unfortunately, in order to diagnose certain sorts of network problems, this sort of activity is necessary. Especially when you have intermittent problems when only a few packets get dropped. Sometimes you will get about 20% packet drops over a few minutes in a period of a couple of hours.
So do the tests between people you have permission to do so with. The first test should be between the client and their first connection to the internet (their ISP, generally), anyway. If that's fine, then the problem's out of their hands; if it's not fine, then you're dealing with the only people who will be able to do something to help you.
-
David G. Miller (aka DaveAtFraud) -
James Wilkinson -
Mike McCarty -
Tim -
Tony Foster