Chee, I don't think it's due to the RAID configuration as the OS is not running on that and it is a simple RAID setup, (single md0 with all disks except system)
Tim On Dec 20, 2007 5:37 AM, Chee How Chua <[EMAIL PROTECTED]> wrote: > > On Dec 20, 2007 5:37 AM, Tim Hempstead <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've been fighting about with my 10.3 system today and have been > > having a few issues with Grub and I was wondering if anyone knew why > > they were happening. > > > > I have a server running 32bit 10.3. This system has a Gigabyte Intel > > chipset motherboard with 6 SATA ports on the Intel controller and 2 > > SATA ports and a PATA port on a JMicron controller. Controllers are > > running in their basic IDE mode (i.e. not AHCI(?) or RAID modes). On > > the 6 Intel SATA ports there is a DVDRW, an ESATA port and 4 500GB > > disk and on the JMicron ports there are 2 500GB (SATA) disks and a 160 > > PATA disk. The 6 500GB disks are a RAID5 array (md0) and the 160GB > > disk is used for the OS. > > > > Now today I had to replace a failing 500GB drive, (which I asked about > > on here previously) ... this went ok and once it was complete I > > started on some other maintenance tasks. This included patching the > > OS using online update which went wrong, badly wrong. The update > > screwed up in some way and left the system in a non-bootable state > > with a lot of corruption of the root filesystem and fsck basically > > ended up killing the system completely, (could not even get into it in > > single user mode) ... fortunately the content of the RAID array > > appears unaffected. > > > > Hence I had to reinstall and I've been having problems with Grub. At > > the end of the install process, (with the Grub configuration in the > > install screen looking correct), the system was unable to do it's > > first reboot without manual intervention. The references it had put > > in the menu.lst file were (hd6,0) instead of (hd0,0); the former did > > not work but interacting with Grub to change to the latter allowed the > > system to come up. Once the system was up and running menu.lst was > > edited to show (hd0,0) and then rebooted fine. Now I can see this > > happening if the installer is picking up disks in a different order or > > something. > > > > But I've just finished patching the new install up to date and, > > fortunately, I looked at the menu.lst before rebooting as for some > > reason it put in the new kernel boot entries with references to > > (hd2,0). These, as i had looked, were changed manually to (hd0,0) and > > this system rebooted fine but I was wondering has anyone else seen > > this / know what is causing this and how to stop it happening so I > > don't have to risk a non-bootable system after a future update. I > > would have thought that any future updates would use the existing > > entries as a base for future ones? > > > > Tim > > > > > > -- > > Tim Hempstead > > [EMAIL PROTECTED] > > Never had a problem like yours. Perhaps the update script is confused > about the RAID setup? > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Hempstead [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
