|
Lilo
Summary
Lilo is a prettier boot loader than grub, but it's a bit more
finnicky. Libranet uses grub, and I didn't switch the
Libranet-installed machines to lilo until late July 2003. Currently all
my systems are booting lilo, including all the machines at the KFA.
Guides
Instructions
The key points for a successful lilo installation are as follows:
- just install lilo
- scp spello:/etc/lilo.conf /etc
- pico /etc/lilo.conf
- make a few changes to the menu at the bottom:
- default=Linux_2.x.xx ==> set x to the value of the current kernel(s)
- image=/boot/vmlinuz-2.x.xx ==> ditto
- append="xx" ==> make any changes necessary
- root = /dev/hdx ==> set x to the value of the root partition
- initrd = /boot/initrd-2.x.xx.img ==> if you've made an initrd image, uncomment
- save /etc/lilo.conf
- liloconfig ==> use defaults -- basically it just implements what you set up in lilo.conf
- make any corrections as necessary
- lilo ==> run lilo and make sure you get no errors
- reboot
You can delete the symlinks to /vmlinuz in the / directory -- lilo specifies the kernels are in /boot.
The little secret to lilo is that you have to let it take over the MBR,
so in lilo.conf, you need the line "boot=/dev/hda". Once you have that,
you can put the / directory anywhere, not to mention the /boot
directory -- afaict, neither of them needs to be a primary partition
(they can both be logical).
[Now, if you write lilo into a partition, such as /dev/hda3, it needs
to be primary, and it must be within something like the first 1000
cylinders -- don't do this; just take over the MBR.]
To return the Master boot record (MBR) to Windows, boot from a floppy to windows
and enter fdisk /mbr. Cf. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q69013
2.6 assigns incorrect disk geometry
15 August 2004
Working on Tord's muhammed I discovered that the 2.6 kernel assigns an
incorrect disk geometry to the hard drive, rendering WinXP unbootable.
It turns out there is a very simple fix for this, though you wouldn't
know from the convoluted debates: just tell lilo the correct disk
geometry, which a 2.4 kernel will tell you.
Here are the gory details. The trouble started on muhammed:
root@muhammed:~# lilo
Warning: COMPACT may conflict with LBA32 on some systems
Added Linux_2.6.7 *
Added Linux_2.4.26
Added Linux_2.4.20
Added Linux_2.4.19
Device 0x0300: Invalid partition table, 2nd entry
3D address: 1/0/4 (4032)
Linear address: 1/12/63 (64260)
2.6.7 dmesg
hda: 58605120 sectors (30005 MB) w/2048KiB Cache, CHS=58140/16/63
2.4.26 dmesg
hda: 58605120 sectors (30006 MB) w/2048KiB Cache, CHS=3648/255/63
The latter is the correct one -- add hda=3648,255,63 to lilo as a boot parameter.
For comparison, here is what Sigillo produces
in 2.4.20:
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63
in 2.6.6:
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=65535/16/63
in 2.4.20:~# sfdisk -l /dev/hda
Disk /dev/hda: 4864 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from
0
Device Boot Start End #cyls #blocks Id System
/dev/hda1 * 0+ 636 637- 5116671 7 HPFS/NTFS
/dev/hda2 637 2037 1401 11253532+ f W95 Ext'd (LBA)
/dev/hda3 * 2038 2043 6 48195 83 Linux
/dev/hda4 2044 4863 2820 22651650 c W95 FAT32 (LBA)
/dev/hda5 637+ 1273 637- 5116671 83 Linux
/dev/hda6 1274+ 1400 127- 1020096 82 Linux swap
/dev/hda7 1401+ 2037 637- 5116671 83 Linux
in 2.6.6:~# sfdisk -l /dev/hda
Disk /dev/hda: 77520 cylinders, 16 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 77520/16/63).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/hda1 * 0+ 636 637- 5116671 7 HPFS/NTFS
/dev/hda2 637 2037 1401 11253532+ f W95 Ext'd (LBA)
/dev/hda3 * 2038 2043 6 48195 83 Linux
/dev/hda4 2044 4863 2820 22651650 c W95 FAT32 (LBA)
/dev/hda5 637+ 1273 637- 5116671 83 Linux
/dev/hda6 1274+ 1400 127- 1020096 82 Linux swap
/dev/hda7 1401+ 2037 637- 5116671 83 Linux
Note that this table is correct -- sfdisk knows how to recover from the wrong information produced by the kernel.
<>Parted also handles it, with a big fat and very helpful
warning. To see parted's opinion of the disk geometry, issue
parted /dev/hda print
Sigillo in 2.6.6 gives this:
Error: The partition table on /dev/hda is inconsistent. There are many
reasons why this might be the case. However, the most likely reason is
that Linux detected the BIOS geometry for /dev/hda incorrectly. GNU
Parted suspects the real geometry should be 4864/255/63 (not
77520/16/63). You should check with your BIOS first, as this may not be
correct. You can inform Linux by adding the parameter hda=4864,255,63
to the command line. See the LILO or GRUB documentation for more
information. If you think Parted's suggested geometry is correct, you
may select Ignore to continue (and fix Linux later). Otherwise, select
Cancel (and fix Linux and/or the BIOS now).
I verified that the 2.4 kernel agreed that this is indeed the
correct disk geometry and added hda=4864,255,63 as a boot parameter in
lilo. I got this new and correct line in dmesg:
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=4864/255/63
parted /dev/hda print in 2.6.6 now gives me this clear result on Sigillo:
Disk geometry for /dev/hda: 0.000-38154.375 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 4996.779 primary ntfs boot
2 4996.780 15986.557 extended lba
5 4996.811 9993.559 logical ext3
6 9993.590 10989.777 logical linux-swap
7 10989.809 15986.557 logical ext2
3 15986.558 16033.623 primary ext3 boot
4 16033.623 38154.375 primary fat32 lba
<>No
error messages, problem fixed. What a weird bug to leave in the kernel
-- and people are not treating it as a bug but as normal technological
change. It's been known since 2.6.0.
|
