[opensuse] Grub strangeness
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 thempstead@gmail.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Dec 20, 2007 5:37 AM, Tim Hempstead <thempstead@gmail.com> 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 thempstead@gmail.com
Never had a problem like yours. Perhaps the update script is confused about the RAID setup? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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 <chuacheehow@gmail.com> wrote:
On Dec 20, 2007 5:37 AM, Tim Hempstead <thempstead@gmail.com> 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 thempstead@gmail.com
Never had a problem like yours. Perhaps the update script is confused about the RAID setup? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- Tim Hempstead thempstead@gmail.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 19 December 2007 21:37:23 Tim Hempstead 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 thempstead@gmail.com
Have you checked your device.map file in /boot/grub ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Dec 23, 2007 8:56 AM, eddie <eddieleprince@dsl.pipex.com> wrote:
On Wednesday 19 December 2007 21:37:23 Tim Hempstead 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.
... snip ...
Tim
-- Tim Hempstead thempstead@gmail.com
Have you checked your device.map file in /boot/grub ? --
Took a look at the current state of this file. What's in there looked consistent with what I saw grub try to do when it updated menu.lst the last time after patching, i.e. the boot drive (sdc) was listed in there as hd2 not the hd0 which is needed for the system to actually boot. I tried creating a new map file (to a temporary file) but that had the same results too ... so I have manually edited the file to match what is needed to work and will have to check next time a patch is applied which requires a new entry in menu.lst to be generated. Thanks Tim -- Tim Hempstead thempstead@gmail.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2007/12/23 09:57 (GMT) Tim Hempstead apparently typed:
On Dec 23, 2007 8:56 AM, eddie <eddieleprince@dsl.pipex.com> wrote:
On Wednesday 19 December 2007 21:37:23 Tim Hempstead wrote:
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.
Have you checked your device.map file in /boot/grub ?
Took a look at the current state of this file. What's in there looked consistent with what I saw grub try to do when it updated menu.lst the last time after patching, i.e. the boot drive (sdc) was listed in there as hd2 not the hd0 which is needed for the system to actually boot.
I tried creating a new map file (to a temporary file) but that had the same results too ... so I have manually edited the file to match what is needed to work and will have to check next time a patch is applied which requires a new entry in menu.lst to be generated.
Make sure /etc/grub.conf is consistent with your expectations. Most distros I've used, unlike SUSE, have no such file. -- Jesus Christ, the reason for the season. Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Chee How Chua -
eddie -
Felix Miata -
Tim Hempstead