On 11 Oct, Terry Collins wrote: > I think the original comparison was that lilo squarks when it can not > understand something, so you have a chance of fixing minor problems > before you end up with an non-bootable machine.
Thanks, Terry. Yes, that was precisely my point. I confess I didn't understand James' comment: > EG you've screwed up your grub config, end of world ? No just edit it and > make > it right and then try to boot again. > > All you need to do is install it correctly once ever! Since it seemed to say "if you messed up and rebooted to discover the machine won't boot, then boot up and fix it". But I certainly welcome his comment that: > Grub DOES use the bios to access the disk. Easy check: bios without beyond1024 > extentions, /boot above 1024 (whatever) and it WONT boot. EG RH9 install > warns you about this if disk>1024 is used. I think the bios is old (AMIBIOS (C) 2000), so probably doesn't have the extensions. Yet other sluggers and the grub doco, says that doesn't matter. E.g.: http://www.redat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/ch-grub.html GRUB supports Logical Block Addressing (LBA) mode. LBA places the addressing conversion used to find files on the drive in the drive's firmware, and it is used on many IDE and all SCSI hard disks. Before LBA, hard drives could encounter a 1024-cylinder limit, where the BIOS could not find a file after that point, such as a boot loader or kernel files. LBA support allows GRUB to boot operating systems from partitions beyond the 1024-cylinder limit, so long as the system BIOS supports LBA mode (most do). So now I'm a bit confused, even though the evidence seems to be in your favour. :-) BTW, I have told the BIOS a figure for the number of cylinders for the big drive so as to get a figure of 250GB (its stated capacity). How perfect does that have to be? If it's a bit less than the true size of the drive, it will just mean I'm wasting some space, I assume? After all, the system booted up from the 13GB drive when it thought the secondary drive was only 137GB. At least I've worked out why grub doesn't do proper consistency checking - they assume that when the system won't boot, then anyone using grub is enough of an expert to be able to use the grub commandline to get themselves out of trouble. (They say as much in their doco.) That assumption would sometimes be true. Of course, if the user removed the kernel file, even grub's facilities wouldn't help, whereas lilo would report that the kernel was gone, giving you a chance to build a fresh one. I'm discovering some interesting stuff from this exercise. Like fdisk doesn't report partitions after the 16th one. You need cfdisk for that. cfdisk doesn't seem to be part of the default Fedora core 4. Having just booted up from a FC4 rescue CD, done a chroot /mnt/sysimage, and run grub from the commandline like this: root (hd1,5) kernel /boot/vmlinuz-2.6.11-1.1369_FC4 initrd /boot/initrd-2.6.11-1.1369_FC4.img boot I expected the system to boot into FC4. All that happened was that grub exited and I got a shell prompt. (Grub exit status was 0.) Is that normal? I'm switching back to lilo for now. Though I get this very worrying message now when I run lilo just after it adds the image for Fedora: Device 0x300: Inconsistent partition table, 2nd entry CHS address in PT: 26:0:1 --> LBA (26208) LBA address in PT: 417690 --> CHS (414:6:1) The partition table is *NOT* being adjusted. Which is obviously saying that it's using a C,H,S scheme in the partition table and elsewhere using an LBA addressing scheme. The Lilo user guide says this means: "The 3D and linear addresses of the first sector of the specified partition don't correspond. This is typically caused by partitioning a disk with a program that doesn't align partitions to tracks [I used Mandrake 9.0's cfdisk] and later using PC/MS-DOS or OS/2 on that disk. [I didn't, I only booted various Linux distros from CD] Lilo can attempt to correct the problem, see page 22." Unfortunately, adding the "fix-table" global option as described on page 22 made no difference. Page 22 says the real fix is to: "re-partition the drive with a program that does align partitions to tracks. Also, with some disks(e.g. some large EIDE disks with address translation enabled), under some circumstances, it may be unavoidable to have conflicting partition table entries." I note that fdisk reported the big drive (primary slave) as 16 heads, 63 sectors, and 484521 cylinders whereas I have set it to 255 heads, 63 sectors, and 29000 cylinders. I have also turned LBA on in the bios for the big drive for a while. Does changing these settings in the bios mess up the partition table? At least now I can boot up Mandrake again from the 13GB primary drive. Oh! And I just tried booting up FC4 using lilo, and it's working fine. Interesting. luke -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
