File System Type Unknown after RUG update

[dcollings]

You are not the only one. The exact same thing happened to me today The fix was the same. Funny thing, I updated the kernel last night to 2.6.16.60-0.37.x-smp. It upgraded fine. Today I had to downgrade to the original SLES 10 SP2 Kernel to install the adpatec 1045 driver. I did the rug update and picked up 2.6.15.60-0.39.3-smp. The upgrade rewrote my menu.lst with (hd 0,0). I selected e for edit and changed it back and it worked like magic. I wonder why that would do that?


>>> Matt Schlawin<MSchlawin@FVLHS.ORG> 5/6/2009 7:33 AM >>>


You were right, kind of. :)

I double checked what you suggested, and I made certain that /dev/sda1 was indeed swap and /dev/sda2 was my root partition. I verified in fdisk that sda1 was type 82 and sda2 was type 83 and bootable. By comparing them to two different servers, I also verified that all of the lines that showed up in the error message were correct. I was able to identify each file in the /boot directory.

The problem was in /boot/grub/menu.lst there is a line that says root(hd0,0) All my other servers said root(hd0,1) I made that one change and everything worked.

I have never edited any of the boot stuff before, because it has always worked. This server is a clean build about two years old and has been running great through many updates. I wonder if I am the only guy in the world this happened to? :)

Thanks for your help!

Matt


>>> On 5/6/2009 at 2:30 AM, in message <80bMl.6477$s8.3086@kovat.provo.novell.com>, Franz Sirl<franz.Sirl-news@lauterbach.com> wrote:


Matt Schlawin schrieb:

> Hello!
> I am running SLES 10sp2 OES2 SP1 on a server with a single SATA drive
> for swap and root (yeah I know) and a SATA array for data. I applied
> the latest RUG patches today and it said it was successful but because
> of the kernel update, it needed a reboot. When I rebooted I get:
>
> root (hd0,0)
> File system type unknown, partition type 0x82
> kernel /boot/vmlinuz-2.6.16.60-0.37_f594963d-smp
> root=/dev/disk/by-id/scsi-SATA_ST380013AS_4MR473ZA-part1 vga=0x317
> resume=/dev/sda1 splash=silent
>
> This server has had driver issues with the 3Ware SATA array before, but
> it has always booted, but just not loaded the SATA array until I updated
> the driver. This time, I cannot get it to boot even in failsafe. The
> older kernel is listed, but I get a "file not found" error if I try to
> boot from that.
>
> So I booted from the SLES10 SP2 DVD in rescue mode. I can mount
> /dev/sda2 and see all of the files on the root partition. I can mount
> /dev/sdb1 and see all the files on the SATA array.
>
> I modified /etc/fstab to remove the SATA array, but I still get the same
> error.
>
> I ran fdisk on both disks and they show them as linux partitions
>
> Is the type 0x82 the problem? How do I fix that when fdisk shows them
> correctly?


Hi,

your problem is probably the
'root=/dev/disk/by-id/scsi-SATA_ST380013AS_4MR473ZA-part1' part of your
grub boot command line. Try to set it to the 2nd partition like
'root=/dev/disk/by-id/scsi-SATA_ST380013AS_4MR473ZA-part2' or maybe
'root=/dev/sda2'. That is what I get from your writings above. It seems
the install somehow mixed up the root and the swap (0x82=swap)partition
(maybe also a typo from hand-editing fstab previously). I don't remember
the trick to enter the grub editor during boot right now, maybe it's as
simple as pressing 'e'?

On a side note, I really share your pain of often not being able to
properly go back to the previous kernel. I really miss the RedHat/CentOS
way here, you can go back an configurable amount of kernels and it
usually works.

Franz