You may have read in another thread that I now have a NAS. The NAS supports NFS so it seemed completely natural to NFS mount a directory tree from the NAS on a desktop PC and to put this mount in the /etc/fstab file so it is mounted whenever the desktop PC is started. I did this and specified the 'bg' option so that if the file system concerned is not available the mount is retried in the background.
Upon the next reboot of the PC it got stuck in the boot process in such a way that all I could see was the Ubuntu logo and no text. Using the Ctrl-Alt combinations to switch virtual console did not make any difference (no text appeared) and Ctrl-Alt-Backspace to kill a running X server did not make any difference either. In the end I used the magic SysReq to reboot the PC.
Upon choosing the "recovery mode" from GRUB I found that the NFS mount was not working because the network card was not up. It seems that when you use the helpful GNOME-based network configuration to configure a network connection it then does not get started early enough in the boot process to support the NFS mount which is rather different than if it had been configured in the /etc/network/interfaces file.
At this point I also found that one RAID array was failing to start which, after some investigation turned out to be a zeroed-out RAID superblock on one of the partitions which I will discuss in another thread.
I now do not know if the failing NFS mount was responsible for the hung boot process and the superblock got corrupted by the magic SysReq reboot or if the superblock was corrupted by a failing drive and the NFS mount was a red herring but it was certainly somewhat surprising.
Steve.
Steve Fosdick wrote:
Upon choosing the "recovery mode" from GRUB I found that the NFS mount was not working because the network card was not up. It seems that when you use the helpful GNOME-based network configuration to configure a network connection it then does not get started early enough in the boot process to support the NFS mount which is rather different than if it had been configured in the /etc/network/interfaces file.
Yes it is worth remembering that connections set up by Gnome's network manager don't happen until after gdm starts. This has caught me out for other reasons as well. I think the only place for network manager is on roaming machines like laptops etc...otherwise you are far better off with a real config.
At this point I also found that one RAID array was failing to start which, after some investigation turned out to be a zeroed-out RAID superblock on one of the partitions which I will discuss in another thread.
I now do not know if the failing NFS mount was responsible for the hung boot process and the superblock got corrupted by the magic SysReq reboot or if the superblock was corrupted by a failing drive and the NFS mount was a red herring but it was certainly somewhat surprising.
Have you tried running smartmontools against the drive that dropped the superblock ?
smartctl -a /dev/sda7 , there are several guides that will tell you how to correctly interpret the results..but anything involving reallocated sectors, reallocated events, pending offline or offline uncorrectable is potentially bad.
Going one step further you might want to try a smartctl -t long /dev/sda7. then checking back after the reported finish time for the test results using -a again. Near the top (or bottom depending on the drive) there will be a log of tests with a progress percentage and a pass/fail. Don't worry about the man pages saying this is an offline test...the drive doesn't actually go offline...although you will notice a distinct lack of performance on the array.
On Sun, Feb 14, 2010 at 08:18:07PM +0000, Steve Fosdick wrote:
You may have read in another thread that I now have a NAS. The NAS supports NFS so it seemed completely natural to NFS mount a directory tree from the NAS on a desktop PC and to put this mount in the /etc/fstab file so it is mounted whenever the desktop PC is started. I did this and specified the 'bg' option so that if the file system concerned is not available the mount is retried in the background.
Upon the next reboot of the PC it got stuck in the boot process in such a way that all I could see was the Ubuntu logo and no text. Using the Ctrl-Alt combinations to switch virtual console did not make any difference (no text appeared) and Ctrl-Alt-Backspace to kill a running X server did not make any difference either. In the end I used the magic SysReq to reboot the PC.
Upon choosing the "recovery mode" from GRUB I found that the NFS mount was not working because the network card was not up. It seems that when you use the helpful GNOME-based network configuration to configure a network connection it then does not get started early enough in the boot process to support the NFS mount which is rather different than if it had been configured in the /etc/network/interfaces file.
At this point I also found that one RAID array was failing to start which, after some investigation turned out to be a zeroed-out RAID superblock on one of the partitions which I will discuss in another thread.
I now do not know if the failing NFS mount was responsible for the hung boot process and the superblock got corrupted by the magic SysReq reboot or if the superblock was corrupted by a failing drive and the NFS mount was a red herring but it was certainly somewhat surprising.
I have a somewhat similar setup though I no longer mount the NAS drives by NFS. I've not seen issues like yours whenever I have booted my system, it always seems to 'just work'.
-
Chris G -
Steve Fosdick -
Wayne Stallwood