Hi all,
After the latest lot of kernel security updates have come out, I updated one of my colo boxes and rebooted. It didn't come back up and fails when booting on: * CPU Microcode update * iptables * eth0
The booting process completes, however as you can imagine, there is no network connectivity at all. The only config changes were installing the new kernel. Booting back into 2.6.18-8.1.8.el5 make things work 100% again.
The system is a dual P3 1Ghz with an e100 network card.
Has anyone else come across this?
Sadly, this is a headless box in an unattended colo - so I can't sit down and reboot upon reboot to try and figure out the cause of the problem.
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
After the latest lot of kernel security updates have come out, I updated one of my colo boxes and rebooted. It didn't come back up and fails when booting on: * CPU Microcode update * iptables * eth0
The booting process completes, however as you can imagine, there is no network connectivity at all. The only config changes were installing the new kernel. Booting back into 2.6.18-8.1.8.el5 make things work 100% again.
I also got this type of probles once before. pls check initrd image. pls performe below steps.
gunzip -cd /boot/initrd-2.6.18-8.1.8.el5.img |cpio -t |more and see
then, check your newly installed kernel. as below
gunzip -cd /boot/initrd-2.6.18-53.1.13.el5.img |cpio -t |more and see
pls check what is missing. If found, All you have to make an initrd by using mkinitrd command.
pls check below URL
http://readlist.com/lists/centos.org/centos/2/13952.html
Indunil Jayasooriya wrote:
I also got this type of probles once before. pls check initrd image. pls performe below steps.
While it's always good to make sure your initrd is in a good state, the network drivers don't need to be in the initrd (unless your booting from NFS or something). They can be loaded fine from /lib/modules/`uname -r`
What kind of network chip(s) are in the system? What driver are they using?(/etc/modprobe.conf), it'd be helpful to have the output of dmesg as well from the kernel that doesn't provide networking support.
You could write a script for some person at the remote co-lo to execute when the system comes up w/o network, the results could be stored in a file on the disk and when the system is rebooted again under the old kernel you can examine them for possible causes.
Some commands to try: dmesg ifconfig -a mii-tool route -n ping -c 5 (IP of default gateway) arping -c 5 (IP of default gateway) arp -an lsmod
nate
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of nate Sent: Thursday, 14 February 2008 2:46 PM To: centos@centos.org Subject: Re: [CentOS] Kernel 2.6.18-53.1.13.el5 fails on network.
Indunil Jayasooriya wrote:
I also got this type of probles once before. pls check initrd image. pls performe below steps.
While it's always good to make sure your initrd is in a good state, the network drivers don't need to be in the initrd (unless your booting from NFS or something). They can be loaded fine from /lib/modules/`uname -r`
What kind of network chip(s) are in the system? What driver are they using?(/etc/modprobe.conf), it'd be helpful to have the output of dmesg as well from the kernel that doesn't provide networking support.
The network is an e100 - dmesg shows the following: # dmesg | grep e100: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation e100: eth0: e100_probe: addr 0xdfffe000, irq 169, MAC addr 00:02:B3:8B:BE:26 e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Of course, this doesn't give us the exact chip, however mii-tool is a bit more helpful: # mii-tool -v eth0 eth0: negotiated 100baseTx-FD, link ok product info: Intel 82555 rev 4 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
The interesting part for me however, is that certain things unrelated to the network also fail. I would expect iptables to come up as OK on boot - even if no network device was configured - as its independent of network configuration. It also doesn't explain how the firmware microcode update also fails.
You could write a script for some person at the remote co-lo to execute when the system comes up w/o network, the results could be stored in a file on the disk and when the system is rebooted again under the old kernel you can examine them for possible causes.
Some commands to try: dmesg ifconfig -a mii-tool route -n ping -c 5 (IP of default gateway) arping -c 5 (IP of default gateway) arp -an lsmod
I have a bit of trouble with this, as the only person that can do it is around 30 minutes travel from the colo. As the system boots, I'm thinking of writing a script that will gather this, then reboot the system after changing the default=x line in /etc/grub.conf - however obviously I want to make sure it works 100% before I tell the machine to reboot ;)
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
On Thu, Feb 14, 2008 at 03:08:54PM +1100, Steven Haigh wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of nate Sent: Thursday, 14 February 2008 2:46 PM To: centos@centos.org Subject: Re: [CentOS] Kernel 2.6.18-53.1.13.el5 fails on network.
Indunil Jayasooriya wrote:
I also got this type of probles once before. pls check initrd image. pls performe below steps.
While it's always good to make sure your initrd is in a good state, the network drivers don't need to be in the initrd (unless your booting from NFS or something). They can be loaded fine from /lib/modules/`uname -r`
What kind of network chip(s) are in the system? What driver are they using?(/etc/modprobe.conf), it'd be helpful to have the output of dmesg as well from the kernel that doesn't provide networking support.
The network is an e100 - dmesg shows the following: # dmesg | grep e100: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation e100: eth0: e100_probe: addr 0xdfffe000, irq 169, MAC addr 00:02:B3:8B:BE:26 e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Of course, this doesn't give us the exact chip, however mii-tool is a bit more helpful: # mii-tool -v eth0 eth0: negotiated 100baseTx-FD, link ok product info: Intel 82555 rev 4 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
The interesting part for me however, is that certain things unrelated to the network also fail. I would expect iptables to come up as OK on boot - even if no network device was configured - as its independent of network configuration. It also doesn't explain how the firmware microcode update also fails.
I had similar problem with a Linux system (Fedora) which was using SElinux in enforcing mode (like CentOS is doing by default) after I booted from a CD not supporting SElinux and editing some configuration files (like ifcfg-eth0) which has lost appropriate SElinux labels because of that. This is most probably different from what you see (one kernel working OK, the other not); no-one was tinkering with /lib/modules from not-SElinux CD, right?
You could write a script for some person at the remote co-lo to execute when the system comes up w/o network, the results could be stored in a file on the disk and when the system is rebooted again under the old kernel you can examine them for possible causes.
Some commands to try: dmesg ifconfig -a mii-tool route -n ping -c 5 (IP of default gateway) arping -c 5 (IP of default gateway) arp -an lsmod
I have a bit of trouble with this, as the only person that can do it is around 30 minutes travel from the colo. As the system boots, I'm thinking of writing a script that will gather this, then reboot the system after changing the default=x line in /etc/grub.conf - however obviously I want to make sure it works 100% before I tell the machine to reboot ;)
IP KVM device would be your friend (unfortunately they are not cheap...)
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
Best regards,
Wojtek
Steven Haigh wrote:
I have a bit of trouble with this, as the only person that can do it is around 30 minutes travel from the colo. As the system boots, I'm thinking of writing a script that will gather this, then reboot the system after changing the default=x line in /etc/grub.conf - however obviously I want to make sure it works 100% before I tell the machine to reboot ;)
I looked at your original email again, and if I read your previous kernel right it's over a year since you last updated the kernel? (2.6.18-8 was released 1/07 by RH, though I can't find 8.1.8)
I was browsing through the change log and saw several e100 related changes, which could be related to the network end of your problems. Without more detailed information as to error messages and stuff for the failures the best thing I can suggest at this point is to try a few kernels in between the one you were on and the latest and see if any of them break, likely they will as the latest kernel only has 1 change in it. Maybe you can narrow it down to a particular kernel rev that came out.
nate
There are a number of differences in the initrd, although nothing that I would call obvious as causing an issue..
--------------------- # gunzip -cd /boot/initrd-2.6.18-8.1.8.el5.img |cpio -t |more 6097 blocks bin bin/modprobe bin/insmod bin/nash dev dev/tty6 dev/zero dev/tty5 dev/console dev/ram1 dev/ttyS3 dev/tty0 dev/ttyS0 dev/null dev/tty3 dev/tty10 dev/ram0 dev/ptmx dev/rtc dev/tty dev/tty8 dev/ttyS1 dev/systty dev/ram dev/tty7 dev/tty1 dev/tty11 dev/tty4 dev/tty2 dev/tty12 dev/tty9 dev/ttyS2 dev/mapper proc lib lib/jbd.ko lib/uhci-hcd.ko lib/ext3.ko lib/ohci-hcd.ko lib/ehci-hcd.ko init sysroot sbin sys etc # --------------------- # gunzip -cd /boot/initrd-2.6.18-53.1.13.el5.img |cpio -t |more 9679 blocks bin bin/dmraid bin/modprobe bin/insmod bin/kpartx bin/nash dev dev/tty6 dev/zero dev/tty5 dev/console dev/ram1 dev/ttyS3 dev/tty0 dev/ttyS0 dev/null dev/tty3 dev/tty10 dev/ram0 dev/ptmx dev/rtc dev/tty dev/tty8 dev/ttyS1 dev/systty dev/ram dev/tty7 dev/tty1 dev/tty11 dev/tty4 dev/tty2 dev/tty12 dev/tty9 dev/ttyS2 dev/mapper proc lib lib/jbd.ko lib/uhci-hcd.ko lib/ext3.ko lib/firmware lib/ohci-hcd.ko lib/ehci-hcd.ko init sysroot sbin sys etc # ---------------------
The obvious additions in .53 are kpartx and dmraid - however as I'm using a plain HDD (hda) with no RAID, I don't really think that would cause an issue.
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Indunil Jayasooriya Sent: Thursday, 14 February 2008 2:34 PM To: CentOS mailing list Subject: Re: [CentOS] Kernel 2.6.18-53.1.13.el5 fails on network.
After the latest lot of kernel security updates have come out, I updated
one
of my colo boxes and rebooted. It didn't come back up and fails when
booting
on: * CPU Microcode update * iptables * eth0
The booting process completes, however as you can imagine, there is no network connectivity at all. The only config changes were installing the
new
kernel. Booting back into 2.6.18-8.1.8.el5 make things work 100% again.
I also got this type of probles once before. pls check initrd image. pls performe below steps.
gunzip -cd /boot/initrd-2.6.18-8.1.8.el5.img |cpio -t |more and see
then, check your newly installed kernel. as below
gunzip -cd /boot/initrd-2.6.18-53.1.13.el5.img |cpio -t |more and see
pls check what is missing. If found, All you have to make an initrd by using mkinitrd command.
pls check below URL
http://readlist.com/lists/centos.org/centos/2/13952.html
On Thu, 2008-02-14 at 14:57 +1100, Steven Haigh wrote:
There are a number of differences in the initrd, although nothing that I would call obvious as causing an issue..
# gunzip -cd /boot/initrd-2.6.18-8.1.8.el5.img |cpio -t |more 6097 blocks bin <snip> ...
sys etc
#
# gunzip -cd /boot/initrd-2.6.18-53.1.13.el5.img |cpio -t |more 9679 blocks bin bin/dmraid
<snip>
sys etc
#
Do yourself a favor, as you'll probably have several more comparisons to do.
When making the lists, sort the output, either piped to sort or make a sorted version afterward, and use comm (man comm). You can see a nice consolidated output, or select any combination of "only on file1", "only on file2", ... both, etc. Makes detecting differences much faster.
<snip>
If grub had a "one time" next boot like LILO, I'd have some more thoughts, but <*sigh*>
on 2/14/2008 2:25 AM William L. Maltby spake the following:
On Thu, 2008-02-14 at 14:57 +1100, Steven Haigh wrote:
There are a number of differences in the initrd, although nothing that I would call obvious as causing an issue..
# gunzip -cd /boot/initrd-2.6.18-8.1.8.el5.img |cpio -t |more 6097 blocks bin <snip> ...
sys etc
#
# gunzip -cd /boot/initrd-2.6.18-53.1.13.el5.img |cpio -t |more 9679 blocks bin bin/dmraid
<snip>
sys etc
#
Do yourself a favor, as you'll probably have several more comparisons to do.
When making the lists, sort the output, either piped to sort or make a sorted version afterward, and use comm (man comm). You can see a nice consolidated output, or select any combination of "only on file1", "only on file2", ... both, etc. Makes detecting differences much faster.
<snip>
If grub had a "one time" next boot like LILO, I'd have some more thoughts, but <*sigh*>
I have been hoping for that option for years. I have used other options like using sed or cp, but they are still susceptible to failures. All my new hardware has been HP's with the ILO feature, so I haven't had to worry about it for a while.
On Thu, 2008-02-14 at 08:44 -0800, Scott Silva wrote:
on 2/14/2008 2:25 AM William L. Maltby spake the following:
<snip>
If grub had a "one time" next boot like LILO, I'd have some more thoughts, but <*sigh*>
I have been hoping for that option for years. I have used other options like using sed or cp, but they are still susceptible to failures. All my new hardware has been HP's with the ILO feature, so I haven't had to worry about it for a while.
<*chuckle*> So I'm not the only one that thinks their self-aggrandizing naming as Grand Unified Boot... is not entirely accurate yet? It certainly is not G or U IMO. I was *very* comfy w/LILO and I did some neat tricks with it.
Makes me want to go back and look at LILO some more and see what other new features are in it now. But time prohibits that. <*sigh*>
<snip sig stuff>
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, 15 February 2008 4:19 AM To: CentOS General List Subject: Re: [CentOS] Re: Kernel 2.6.18-53.1.13.el5 fails on network.
On Thu, 2008-02-14 at 08:44 -0800, Scott Silva wrote:
on 2/14/2008 2:25 AM William L. Maltby spake the following:
<snip>
If grub had a "one time" next boot like LILO, I'd have some more thoughts, but <*sigh*>
I have been hoping for that option for years. I have used other
options like
using sed or cp, but they are still susceptible to failures. All my new hardware has been HP's with the ILO feature, so I haven't
had to
worry about it for a while.
<*chuckle*> So I'm not the only one that thinks their self-aggrandizing naming as Grand Unified Boot... is not entirely accurate yet? It certainly is not G or U IMO. I was *very* comfy w/LILO and I did some neat tricks with it.
Makes me want to go back and look at LILO some more and see what other new features are in it now. But time prohibits that. <*sigh*>
Yeah, having the ability to do this would rock. The box in question is on a remote power switch, however I don't have an IP KVM there (but would love one!). The box does hosting for a number of community wireless sites in Australia - none of which make any money to put towards buying equipment! I looked at a single port IP KVM, but this was around $480AUD :(
As the box goes to a command prompt - even after failures - I was thinking of putting a simple script at the end of /etc/rc.d/rc.local which will launch in the background (/root/bin/bootinfo &)
----------------------- Begin script --------------------- #!/bin/bash sleep 30
# Gather some system info: echo "System booted at `date`." > /root/bootinfo cat /proc/version >> /root/bootinfo echo "------ Dmesg start ------" >> /root/bootinfo dmesg >> /root/bootinfo echo "------ lsmod start ------" >> /root/bootinfo lsmod >> /root/bootinfo echo "------ ifconfig start ------" >> /root/bootinfo ifconfig >> /root/bootinfo echo "------ route info ------" >> /root/bootinfo route -n >> /root/bootinfo echo "------ mii-tool start ------" >> /root/bootinfo mii-tool -v -i eth0 >> /root/bootinfo echo "------ End troubleshooting ------" >> /root/bootinfo
# Test if we have network connectivity. ping -c 1 -n <gateway> if [ $? -eq "0" ]; then # We can ping the gateway! exit 0 else # We have no network connectivity :( cp -f /etc/grub.conf-good /etc/grub.conf reboot fi ----------------------- End script ---------------------
Does anyone have any additions or insight into this? Maybe something I'm forgetting?
Obviously I'd have to make sure /etc/grub.conf-good is a working copy of the config for grub....
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
Just replying to myself for this - I realised that after a 'failed' boot, it would also overwrite the boot logs when the system came back up with the correct kernel/grub config ;)
I've made a few changes and added a bit more to the script - and I think its about ready to use.
----------------------- Begin script --------------------- #!/bin/bash sleep 30
# Gather some system info: echo "System booted at `date`." > /root/bootinfo cat /proc/version >> /root/bootinfo echo "------ Dmesg start ------" >> /root/bootinfo dmesg >> /root/bootinfo echo "------ lsmod start ------" >> /root/bootinfo lsmod >> /root/bootinfo echo "------ ifconfig start ------" >> /root/bootinfo ifconfig >> /root/bootinfo echo "------ route info ------" >> /root/bootinfo route -n >> /root/bootinfo echo "------ mii-tool start ------" >> /root/bootinfo mii-tool -v eth0 >> /root/bootinfo echo "------ mounted drives ------" >> /root/bootinfo mount >> /root/bootinfo echo "------ Disk space ------" >> /root/bootinfo df -h >> /root/bootinfo echo "------ End troubleshooting ------" >> /root/bootinfo
# Test if we have network connectivity. ping -c 1 -n <gateway> > /dev/null if [ $? -eq "0" ]; then # We can ping the gateway! echo "Network ok." exit 0 else # We have no network connectivity :( echo "No Network!" mv /root/bootinfo /root/bootinfo.failed cp -f /etc/grub.conf-good /etc/grub.conf reboot fi
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
I have found the issue with this - and now I feel quite dumb.
In this box, I keep a second HDD (/dev/hdc) which is mirrored nightly from the primary HDD (/dev/hda).
This is an exact copy - initially created via dd, then kept up to date via rsync on a nightly basis. This is so that if the primary HDD fails, I can change the system to use /dev/hdc and be up and running after a reboot/forced power cycle.
What was happening is that both /dev/hda3 and /dev/hdc3 have the LABEL=/ - which means it would be a random guess as to which one got mounted.
After changing the root=LABEL=/ in grub.conf to root=/dev/hda3, all works perfectly.
Man I miss the days when we used device names, not labels ;)
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
on 2/14/2008 10:38 AM Steven Haigh spake the following:
I have found the issue with this - and now I feel quite dumb.
In this box, I keep a second HDD (/dev/hdc) which is mirrored nightly from the primary HDD (/dev/hda).
This is an exact copy - initially created via dd, then kept up to date via rsync on a nightly basis. This is so that if the primary HDD fails, I can change the system to use /dev/hdc and be up and running after a reboot/forced power cycle.
What was happening is that both /dev/hda3 and /dev/hdc3 have the LABEL=/ - which means it would be a random guess as to which one got mounted.
After changing the root=LABEL=/ in grub.conf to root=/dev/hda3, all works perfectly.
Man I miss the days when we used device names, not labels ;)
--
Why not do a software raid with the drives? That way it is constantly up to date instead of a nightly rsync.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Scott Silva Sent: Friday, 15 February 2008 7:15 AM To: centos@centos.org Subject: [CentOS] Re: Kernel 2.6.18-53.1.13.el5 fails on network.
on 2/14/2008 10:38 AM Steven Haigh spake the following:
I have found the issue with this - and now I feel quite dumb.
In this box, I keep a second HDD (/dev/hdc) which is mirrored nightly
from
the primary HDD (/dev/hda).
This is an exact copy - initially created via dd, then kept up to
date via
rsync on a nightly basis. This is so that if the primary HDD fails, I
can
change the system to use /dev/hdc and be up and running after a reboot/forced power cycle.
What was happening is that both /dev/hda3 and /dev/hdc3 have the
LABEL=/ -
which means it would be a random guess as to which one got mounted.
After changing the root=LABEL=/ in grub.conf to root=/dev/hda3, all
works
perfectly.
Man I miss the days when we used device names, not labels ;)
--
Why not do a software raid with the drives? That way it is constantly up to date instead of a nightly rsync.
Software RAID doesn't help when a different admin installs a package that they shouldn't and overwrites critical files (say the glibc libraries) and hoses the entire system. During the many years of using linux, the most downtime has been caused by humans - not hardware failures.
Having a nightly rsync between drives allows me to restore the system to a snapshot in a simple reboot. I can then restore to within 6 hours from our remote tape backup system. RAID only helps against hardware failure - not human failure.
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
On Fri, 2008-02-15 at 07:23 +1100, Steven Haigh wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Scott Silva Sent: Friday, 15 February 2008 7:15 AM To: centos@centos.org Subject: [CentOS] Re: Kernel 2.6.18-53.1.13.el5 fails on network.
on 2/14/2008 10:38 AM Steven Haigh spake the following:
I have found the issue with this - and now I feel quite dumb.
In this box, I keep a second HDD (/dev/hdc) which is mirrored nightly
from
the primary HDD (/dev/hda).
This is an exact copy - initially created via dd, then kept up to
date via
rsync on a nightly basis. This is so that if the primary HDD fails, I
can
change the system to use /dev/hdc and be up and running after a reboot/forced power cycle.
What was happening is that both /dev/hda3 and /dev/hdc3 have the
LABEL=/ -
which means it would be a random guess as to which one got mounted.
After changing the root=LABEL=/ in grub.conf to root=/dev/hda3, all
works
perfectly.
Man I miss the days when we used device names, not labels ;)
--
Why not do a software raid with the drives? That way it is constantly up to date instead of a nightly rsync.
Software RAID doesn't help when a different admin installs a package that they shouldn't and overwrites critical files (say the glibc libraries) and hoses the entire system. During the many years of using linux, the most downtime has been caused by humans - not hardware failures.
Having a nightly rsync between drives allows me to restore the system to a snapshot in a simple reboot. I can then restore to within 6 hours from our remote tape backup system. RAID only helps against hardware failure - not human failure.
-- Steven Haigh
Yes, you are correct that RAID doesn't help with human failings. However, LVM[1], backups, and change control management do ;)
1: http://www.linux.org/docs/ldp/howto/LVM-HOWTO/snapshots_backup.html
--Tim _________________________________________________________________________ / If you make people think they're thinking, they'll love you; but if you \ \ really make them think they'll hate you. / ------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
How can i mount a nfs share with user and password
thanks Roilan
______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m�viles desde 1 c�ntimo por minuto. http://es.voice.yahoo.com
On 2/15/08, neptuno neptuno_000@yahoo.es wrote:
How can i mount a nfs share with user and password
thanks Roilan
http://www.google.com/search?q=mounting+nfs+share+centos+user+password
try the third link down and please remember that GOOGLE IS YOUR FRIEND when it comes to asking questions like this!
/me being very polite as it is both POETS day and beautiful weather outside
Dear Michael Simpson, I wrote to the list because i allready asked to google and I didn't found results, thenks anyway. regards Roilan
----- Original Message ----- From: "Michael Simpson" mikie.simpson@gmail.com To: "CentOS mailing list" centos@centos.org Sent: Friday, February 15, 2008 04:48 AM Subject: Re: [CentOS] NFS mount
On 2/15/08, neptuno neptuno_000@yahoo.es wrote:
How can i mount a nfs share with user and password
thanks Roilan
http://www.google.com/search?q=mounting+nfs+share+centos+user+password
try the third link down and please remember that GOOGLE IS YOUR FRIEND when it comes to asking questions like this!
/me being very polite as it is both POETS day and beautiful weather outside _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.20/1260 - Release Date: 2/5/2008 9:44 AM
______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
neptuno wrote:
How can i mount a nfs share with user and password
thanks Roilan
Please, when posting to the mailing list, don't hijack threads.
Hijack means to reply to another thread and to change the subject and replace the body of the mail to start a new thread.
What happens when you do this is that you mail shows up in the chain of the other mails because there is unseen metadata in the e-mail that says it is a "reply to" the other thread.
See here for a technical explanation:
http://en.wikipedia.org/wiki/Thread_hijacking
Welcome to the list ...
Thanks, Johnny Hughes
on 2/14/2008 10:06 AM Steven Haigh spake the following:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, 15 February 2008 4:19 AM To: CentOS General List Subject: Re: [CentOS] Re: Kernel 2.6.18-53.1.13.el5 fails on network.
On Thu, 2008-02-14 at 08:44 -0800, Scott Silva wrote:
on 2/14/2008 2:25 AM William L. Maltby spake the following:
<snip> If grub had a "one time" next boot like LILO, I'd have some more thoughts, but <*sigh*>
I have been hoping for that option for years. I have used other
options like
using sed or cp, but they are still susceptible to failures. All my new hardware has been HP's with the ILO feature, so I haven't
had to
worry about it for a while.
<*chuckle*> So I'm not the only one that thinks their self-aggrandizing naming as Grand Unified Boot... is not entirely accurate yet? It certainly is not G or U IMO. I was *very* comfy w/LILO and I did some neat tricks with it.
Makes me want to go back and look at LILO some more and see what other new features are in it now. But time prohibits that. <*sigh*>
Yeah, having the ability to do this would rock. The box in question is on a remote power switch, however I don't have an IP KVM there (but would love one!). The box does hosting for a number of community wireless sites in Australia - none of which make any money to put towards buying equipment! I looked at a single port IP KVM, but this was around $480AUD :(
As the box goes to a command prompt - even after failures - I was thinking of putting a simple script at the end of /etc/rc.d/rc.local which will launch in the background (/root/bin/bootinfo &)
----------------------- Begin script --------------------- #!/bin/bash sleep 30
# Gather some system info: echo "System booted at `date`." > /root/bootinfo cat /proc/version >> /root/bootinfo echo "------ Dmesg start ------" >> /root/bootinfo dmesg >> /root/bootinfo echo "------ lsmod start ------" >> /root/bootinfo lsmod >> /root/bootinfo echo "------ ifconfig start ------" >> /root/bootinfo ifconfig >> /root/bootinfo echo "------ route info ------" >> /root/bootinfo route -n >> /root/bootinfo echo "------ mii-tool start ------" >> /root/bootinfo mii-tool -v -i eth0 >> /root/bootinfo echo "------ End troubleshooting ------" >> /root/bootinfo
# Test if we have network connectivity. ping -c 1 -n <gateway> if [ $? -eq "0" ]; then # We can ping the gateway! exit 0 else # We have no network connectivity :( cp -f /etc/grub.conf-good /etc/grub.conf reboot fi ----------------------- End script ---------------------
Does anyone have any additions or insight into this? Maybe something I'm forgetting?
Obviously I'd have to make sure /etc/grub.conf-good is a working copy of the config for grub....
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
You can also send everything from the grub prompt on to a serial port. You can set up some kind of serial console with remote access and use serial crossovers. You can even make one out of old cast-off PC's.
-
Garrick Staples -
Indunil Jayasooriya -
Johnny Hughes -
Michael Simpson -
nate -
neptuno -
Scott Silva -
Steven Haigh -
Timothy Selivanow -
William L. Maltby -
Wojtek Pilorz