The Saturday 2006-11-25 at 20:47 +1100, Basil Chupin wrote:
Suddenly I cannot boot into 10.1 with GRUB coming up with, "Error 18" as soon as it starts to execute on bootup.
Does anyone know what this error means and how to get grub working correctly again?
info grub, Troubleshooting, Stage2 errors: | 18 : Selected cylinder exceeds maximum supported by BIOS | This error is returned when a read is attempted at a linear | block address beyond the end of the BIOS translated area. This | generally happens if your disk is larger than the BIOS can handle | (512MB for (E)IDE disks on older machines or larger than 8GB in | general).
Can you view the menu.lst file at the grub prompt(grub>) and do the entries match your current partitioning setup?
grub> cat (hd0,0)/boot/grub/menu.lst
Yes.
where (hd0,0) represents (drive#,partition#) with numbering starting at zero and pointing to the partition holding menu.lst which should be your separate boot partition assuming grub was installed there originally and not to the root partition. (hd0,0) would point to the 1st partition on the 1st drive. (hd1,3) would point to the 4th partition on the second drive, etc...
grub> geometry (hdx)
will show existing partitions(x=0,1,2 etc.) .
Geometry OK. All partitions correctly shown (both HDs, btw).
Can you boot from the grub prompt manually?
ie. grub> root (hdx,x)
This is OK.
grub> kernel /vmlinuz root=/dev/hdx <other options>
This is OK.
grub> initrd /initrd
This comes up with an error, "Error 28: Selected item cannot fit into memory" which is a bit strange as I have 1.5GB of RAM and even right at the moment I have 58.5MB free.
grub> boot
Of course this does not happen :-) .
What does all of the above mean? Do I need a grease and oil change or a new set of spark plugs? :-)
On Saturday 25 November 2006 21:33, Joe Morris (NTM) wrote:
Joe Morris (NTM) wrote:
It would be basically grub, then root (hd0,8), then setup (hd0), which should find everything and install it, the quit to leave grub, exit to leave the chroot, then shutdown -r now to reboot and check. HTH.
One more idea, since at least once it appeared you had a problem with the initrd, while you are in the chroot, you could rerun the mkinitrd command and make sure it finishes without error. HTH.
As Joe suggests, rerunning mkinitrd is worth a try based on what you see. After the upgrade to beta1, I ran into a case where the upgrade somehow removed the initrd image completely and had to recreate it. Using the installation disk allowed me to boot the system even with this image missing. If you haven't already done something else that would render this next portion nonapplicable, try the following after booting into the system w/ the installation disk to create a new initrd image: cd /boot mv initrd-2.6.18.2-4-default initrd-2.6.18.2-4-default.notworking.old Modify "2.6.18.2-4-default" above(10.2 beta2 version) to match your current version which you can view with the output of "uname -a". rm initrd (or mv initrd initrd.notworking.old) mkinitrd -k vmlinuz-2.6.18.2-4-default -i initrd-2.6.18.2-4-default (your new initd-2.6.18.2-4 image should now be present) and/or for the xen image mkinitrd -k vmlinuz-2.6.18.2-4-xen -i initrd-2.6.18.2-4-xen Note that running just 'mkinitrd' with no options will create the default image that matches your current kernel vmlinuz image. recreate symbolic link(s) ln -s /boot/initrd-2.6.18.x-y /boot/initrd where "2.6.18.x-y" above is the version number you just created Verify that the symbolic links named /boot/initrd & /boot/vmlinuz point to matching version numbers . # ll initrd initrd -> initrd-2.6.18.2-4-default and confirm that this version matches the vmlinuz image version # ll vmlinuz vmlinuz -> vmlinuz-2.6.18.2-4-default You could also check for matching versions this before rerunning mkinitrd and if they don't match, it might be the problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org