Unable to mount any filesystems on SuSE 9.3 machine
I've just been asked to have a look at a SuSE 9.3 machine which hasn't been rebooted in 188 days. It seems to have lost the ability to mount filesystems (sorry for the poor description), although the machine is running and appears otherwise healthy. ~ # tail /var/log/messages Nov 10 07:56:56 box1 modprobe: FATAL: Could not load /lib/modules/2.6.11.4-20a-smp/modules.dep: No such file or directory ~ # fdisk -l /dev/sdb Disk /dev/sdb: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 24319 195342336 83 Linux (this is an ext3 partition) ~ # mount /dev/sdb1 /two mount: unknown filesystem type 'ext3' (I've also tried mounting xfs and reiserfs filesystems and that doesn't work either). ~ # uname -a Linux box1 2.6.11.4-20a-smp #1 SMP Wed Mar 23 21:52:37 UTC 2005 i686 i686 i386 GNU/Linux ~ # mount /dev/sda2 on / type reiserfs (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) usbfs on /proc/bus/usb type usbfs (rw) /dev/fd0 on /media/floppy type subfs (rw,nosuid,nodev,sync,fs=floppyfss,procuid) /dev/fd0 on /media/floppy_1 type subfs (rw,nosuid,nodev,sync,fs=floppyfss,procuid) Why is /lib/modules/2.6.11.4-20a-smp/modules.dep apparently missing? If I go to yast2 and check for updates it seems some were applied ten days ago - I would imagine that includes kernel updates, but the machine obviously wasn't rebooted after patching. Is there a detailed log file of what's been applied via yast online update? Could it be that a kernel update has been done and the machine simply needs a reboot, or is this a sign of something far more serious? Thanks in advance for any suggestions James
Sbs Bofh wrote:
I've just been asked to have a look at a SuSE 9.3 machine which hasn't been rebooted in 188 days.
It seems to have lost the ability to mount filesystems (sorry for the poor description), although the machine is running and appears otherwise healthy.
~ # tail /var/log/messages Nov 10 07:56:56 box1 modprobe: FATAL: Could not load /lib/modules/2.6.11.4-20a-smp/modules.dep: No such file or directory
Kernel update without reboot. The standard config excludes kernel updates via YOU. If you configured automatic updates and you have included the kernel updates you have set yourself up for automatic trouble. (^-^)
If I go to yast2 and check for updates it seems some were applied ten days ago - I would imagine that includes kernel updates, but the machine obviously wasn't rebooted after patching.
Is there a detailed log file of what's been applied via yast online update?
I do not delete the updates after they are applied and they are stored in /var/lib/YaST2/you/mnt/i386/update/9.2/patches. Also check /var/lib/YaST2/you/youlog for the applied changes.
Could it be that a kernel update has been done and the machine simply needs a reboot, or is this a sign of something far more serious?
I think it was a kernel update. Though I would have the rescue cd at hand just in case. (^-^) Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On 11/10/05, Sandy Drobic <suse-linux-e@japantest.homelinux.com> wrote:
I've just been asked to have a look at a SuSE 9.3 machine which hasn't been rebooted in 188 days.
It seems to have lost the ability to mount filesystems (sorry for the
Sbs Bofh wrote: poor
description), although the machine is running and appears otherwise healthy.
~ # tail /var/log/messages Nov 10 07:56:56 box1 modprobe: FATAL: Could not load /lib/modules/2.6.11.4-20a-smp/modules.dep: No such file or directory
Kernel update without reboot. The standard config excludes kernel updates via YOU. If you configured automatic updates and you have included the kernel updates you have set yourself up for automatic trouble. (^-^)
If I go to yast2 and check for updates it seems some were applied ten days ago - I would imagine that includes kernel updates, but the machine obviously wasn't rebooted after patching.
Is there a detailed log file of what's been applied via yast online update?
I do not delete the updates after they are applied and they are stored in /var/lib/YaST2/you/mnt/i386/update/9.2/patches.
There are lots and lots of files in this directory - including three called kernel-<something> -rw-r--r-- 1 root root 28382 2005-06-12 20:54 kernel-52256 -rw-r--r-- 1 root root 31163 2005-08-08 19:30 kernel-52370 -rw-r--r-- 1 root root 32169 2005-09-21 13:39 kernel-52414 Also check /var/lib/YaST2/you/youlog for the applied changes. It looks like a new kernel has been installed at least twice in the last six months and the machine was definitely not rebooted afterwards.
Could it be that a kernel update has been done and the machine simply needs a reboot, or is this a sign of something far more serious?
I think it was a kernel update. Though I would have the rescue cd at hand just in case. (^-^)
I'm in slightly tricky situation - I'm working on the server from 400 miles away via ssh. If it reboot it and it doesn't come back up then in a heap of trouble. relative to a dead server, not being able to mount is a relatively minor problem :-) it looks like the automatic updates were NOT configured, so the previous admin must have applied the kernel updates through interactive update. does Yast always tell you to reboot if an update requires it? I'm a bit ignorant on patching linux, more used to the windows world where even a update for notepad.exe requires a reboot :-) in general is it only kernel updates on SuSE that need a reboot? James
Sbs Bofh wrote:
Also check /var/lib/YaST2/you/youlog for the applied changes.
It looks like a new kernel has been installed at least twice in the last six months and the machine was definitely not rebooted afterwards.
That would indeed explain your trouble.
I think it was a kernel update. Though I would have the rescue cd at hand just in case. (^-^)
I'm in slightly tricky situation - I'm working on the server from 400 miles away via ssh. If it reboot it and it doesn't come back up then in a heap of trouble. relative to a dead server, not being able to mount is a relatively minor problem :-)
Included in the kernel are the modules (or drivers for windows users;), that is the root of the problem. Please check if you are using lilo or grub as a bootloader. If you use lilo you might need to execute /sbin/lilo to write the updated config into the boot loader. That is indeed a message you receive when you update. Normally you should not have a problem rebooting the machine though I would never promise that. (^-^) Nevertheless I would take a good look at the hardware of the machine and google to research if there were any reports for trouble.
it looks like the automatic updates were NOT configured, so the previous admin must have applied the kernel updates through interactive update. does Yast always tell you to reboot if an update requires it?
I think so, any kernel update will only take effect after a reboot, so you either do not apply a kernel update or you reboot afterwards.
I'm a bit ignorant on patching linux, more used to the windows world where even a update for notepad.exe requires a reboot :-) in general is it only kernel updates on SuSE that need a reboot?
Generally a kernel update should be the only update that really requires a reboot. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On Thu, 2005-11-10 at 10:56 +0100, Sbs Bofh wrote:
On 11/10/05, Sandy Drobic <suse-linux-e@japantest.homelinux.com> wrote:
I've just been asked to have a look at a SuSE 9.3 machine which hasn't been rebooted in 188 days.
It seems to have lost the ability to mount filesystems (sorry for the
Sbs Bofh wrote: poor
description), although the machine is running and appears otherwise healthy.
~ # tail /var/log/messages Nov 10 07:56:56 box1 modprobe: FATAL: Could not load /lib/modules/2.6.11.4-20a-smp/modules.dep: No such file or directory
Kernel update without reboot. The standard config excludes kernel updates via YOU. If you configured automatic updates and you have included the kernel updates you have set yourself up for automatic trouble. (^-^)
If I go to yast2 and check for updates it seems some were applied ten days ago - I would imagine that includes kernel updates, but the machine obviously wasn't rebooted after patching.
Is there a detailed log file of what's been applied via yast online update?
I do not delete the updates after they are applied and they are stored in /var/lib/YaST2/you/mnt/i386/update/9.2/patches.
There are lots and lots of files in this directory - including three called kernel-<something>
-rw-r--r-- 1 root root 28382 2005-06-12 20:54 kernel-52256 -rw-r--r-- 1 root root 31163 2005-08-08 19:30 kernel-52370 -rw-r--r-- 1 root root 32169 2005-09-21 13:39 kernel-52414
Also check /var/lib/YaST2/you/youlog for the applied changes.
It looks like a new kernel has been installed at least twice in the last six months and the machine was definitely not rebooted afterwards.
Could it be that a kernel update has been done and the machine simply needs a reboot, or is this a sign of something far more serious?
I think it was a kernel update. Though I would have the rescue cd at hand just in case. (^-^)
I'm in slightly tricky situation - I'm working on the server from 400 miles away via ssh. If it reboot it and it doesn't come back up then in a heap of trouble. relative to a dead server, not being able to mount is a relatively minor problem :-)
it looks like the automatic updates were NOT configured, so the previous admin must have applied the kernel updates through interactive update. does Yast always tell you to reboot if an update requires it?
I'm a bit ignorant on patching linux, more used to the windows world where even a update for notepad.exe requires a reboot :-) in general is it only kernel updates on SuSE that need a reboot?
James
Was does ls -a /lib/modules show? This should tell you whether or not any kernel updates have been applied through YOU. also look at /boot to see what version the currently installed kernel is. The error you have about no modules.dep usually means that there has been a kernel update and the system has not been rebooted. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On 11/10/05, Ken Schneider <suse-list@bout-tyme.net> wrote:
Was does ls -a /lib/modules show? This should tell you whether or not any kernel updates have been applied through YOU.
2.6.11.4-20a-smp 2.6.11.4-21.7-smp 2.6.11.4-21.8-smp 2.6.11.4-21.9-smp 2.6.11.4-override-smp precompiled scripts also look at /boot to
see what version the currently installed kernel is.
backup_mbr boot config-2.6.11.4-21.9-smp grub initrd initrd-2.6.11.4-21.9-smp message README.vmlinux-2.6.11.4-21.9-smp.gz symvers-2.6.11.4-21.9-i386-smp.gz System.map-2.6.11.4-21.9-smp vmlinuz vmlinuz-2.6.11.4-21.9-smp The error you have about no modules.dep usually means that there has
been a kernel update and the system has not been rebooted.
OK. I will probably try a reboot next week once I pluck up the courage :-) James
On Thu, 2005-11-10 at 14:52 +0100, Sbs Bofh wrote:
On 11/10/05, Ken Schneider <suse-list@bout-tyme.net> wrote:
Was does ls -a /lib/modules show? This should tell you whether or not any kernel updates have been applied through YOU.
2.6.11.4-20a-smp 2.6.11.4-21.7-smp 2.6.11.4-21.8-smp 2.6.11.4-21.9-smp 2.6.11.4-override-smp precompiled scripts
also look at /boot to
see what version the currently installed kernel is.
backup_mbr boot config-2.6.11.4-21.9-smp grub initrd initrd-2.6.11.4-21.9-smp message README.vmlinux-2.6.11.4-21.9-smp.gz symvers-2.6.11.4-21.9-i386-smp.gz System.map-2.6.11.4-21.9-smp vmlinuz vmlinuz-2.6.11.4-21.9-smp
The error you have about no modules.dep usually means that there has
been a kernel update and the system has not been rebooted.
OK. I will probably try a reboot next week once I pluck up the courage :-)
James
This shows that the kernel has been updated three times without a reboot in between. (from previous post from you) ~ # tail /var/log/messages Nov 10 07:56:56 box1 modprobe: FATAL: Could not load /lib/modules/2.6.11.4-20a-smp/modules.dep: No such file or directory This shows that the running kernel is 2.6.11.4-20a and there have been updates since. If you are using lilo, unlikely since the default for 9.3 was grub, just run mkinitrd as root and reboot. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On 11/10/05, Ken Schneider <suse-list@bout-tyme.net> wrote:
This shows that the running kernel is 2.6.11.4-20a and there have been updates since. If you are using lilo, unlikely since the default for 9.3 was grub, just run mkinitrd as root and reboot.
it's using grub. from what i understand that means i don't need to worry about mkinitrd - is that right? James PS thank you for taking the time to give a detailed explanation of what the various bits mean!
On Thursday 10 November 2005 11:11 am, Sbs Bofh wrote:
On 11/10/05, Ken Schneider <suse-list@bout-tyme.net> wrote:
This shows that the running kernel is 2.6.11.4-20a and there have been updates since. If you are using lilo, unlikely since the default for 9.3 was grub, just run mkinitrd as root and reboot.
it's using grub. from what i understand that means i don't need to worry about mkinitrd - is that right?
Yes you do.... initrd is for the kernel to use while booting and has nothing to do with which loader you use to get the kernel going.
On Thu, 2005-11-10 at 17:11 +0100, Sbs Bofh wrote:
On 11/10/05, Ken Schneider <suse-list@bout-tyme.net> wrote:
This shows that the running kernel is 2.6.11.4-20a and there have been updates since. If you are using lilo, unlikely since the default for 9.3 was grub, just run mkinitrd as root and reboot.
it's using grub. from what i understand that means i don't need to worry about mkinitrd - is that right?
James
PS thank you for taking the time to give a detailed explanation of what the various bits mean!
You might want to run mkinitrd just to make sure. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
participants (4)
-
Bruce Marshall -
Ken Schneider -
Sandy Drobic -
Sbs Bofh