How to Properly Configure LILO?

0

I want to use LILO instead of GRUB, got some questions about configuring it nicely. I have only one OS on my machine, so there is no need for prompting me to choose a boot entry; here is my lilo.conf:

compact
lba32

boot = /dev/sda
map = /boot/map

image = /boot/vmlinuz-4.19.44-gentoo
    root = /dev/sda3
    read-only

What option lba32 does and do I need it? Is it okay that I did not label a boot entry (since there is only one)?

Will it actually work? Here is my HDD:

sda    931.5G disk 
├─sda1    12M part 
├─sda2   500M part /boot
├─sda3    64G part /
├─sda4   864G part /home
└─sda5     3G part [SWAP]

Will lilo wipe out MBR before actual install process or should I do it by myself with dd first?


Here is my boot directory:

grub/
System.map-4.19.44-gentoo
System.map-4.19.44-gentoo.old
config-4.19.44-gentoo
config-4.19.44-gentoo.old
vmlinuz-4.19.44-gentoo
vmlinuz-4.19.44-gentoo.old

Are System.map* and config* files belong to the GRUB installation? Can I delete them?

I guess I can remove lilo package after it will write itself on MBR, am I right?


Why people say it good to have a boot partition for 500M while my vmlinuz takes only 8M? Do they just store a lot of linux images or there are some other reasons to have a vast boot partition?

Pierre Dunn

Posted 2019-10-21T20:07:56.043

Reputation: 117

1Are you configuring this for an UEFI or IBM PC BIOS system? – user1686 – 2019-10-21T20:30:32.967

@grawity second. – Pierre Dunn – 2019-10-21T20:31:39.930

Answers

0

Note: Half of this was written purely based on the LILO documentation.

What option lba32 does and do I need it?

It tells LILO to use 32-bit "Logical Block Addressing" when reading disk sectors (LBA is the method modern systems use); this way it can reach locations up to 2 GiB when the disk provides 512-byte logical sectors.

The default method is to use Cylinder/Head/Sector addressing, which is from early MS-DOS era and has a limit of approximately 8 GB. (And modern disks only pretend that the CHS numbers have anything to do with the physical layout, anyway.)

Is it okay that I didn't labeled a boot entry (since there is only one)?

According to LILO manual, the label field is optional – the default label will be taken from the kernel filename.

Will lilo wipe out MBR before actual install process or should I do it by myself with dd first?

If you choose to install LILO into the MBR, it will will write its own MBR boot code as part of its install process. (That is actually the point of LILO's install process.)

If you choose to install LILO into the partition only, you will need to provide your own MBR. In this mode you'll need to write a generic MBR that just boots the active partition's VBR – the manual talks about MS-DOS MBR, but you can equally well use a Windows MBR from ms-sys, or even the Syslinux MBR, as they all do the same thing.

Note that in any case only the "boot code" area of the MBR (440 bytes) is overwritten. The "partition table" area is not overwritten, even though it is in the same sector.

Are System.map* and config* files belong to the GRUB installation? Can I delete them?

No, they belong to the kernel itself.

  • System.map* is mostly used for debugging (and is made redundant by CONFIG_KALLSYMS which makes the same information available through /proc).
  • config* just contains a copy of the kernel config you used (and is also made redundant by CONFIG_IKCONFIG, which makes the information available through /proc/config.gz).

So deleting them technically shouldn't hurt anything. However, the next time you upgrade your kernel, new files will be installed anyway.

I guess I can remove lilo package after it will write itself on MBR, am I right?

No – you'll need to re-run lilo every time you edit the configuration file. The reason is that LILO doesn't understand filesystems, so it just remembers the exact sector number where its config file is located.

Once you edit the file, it might get saved to a new location, which requires LILO to be reinstalled. (And as you can see the file refers to your kernel using a versioned filename, it will have to be edited, and quite often at that.)

Why people say to have a 500M boot partition if my vmlinuz takes only 8M?

I think the 500 MB or 512 MB number likely comes from a Microsoft recommendation for EFI system partitions. Dedicated Linux /boot partitions on BIOS systems hold fewer files, so they could definitely be smaller. But it's a nice round number, and it means you never run out of space in it, and never need to repartition if you ever convert the system to UEFI boot mode.

(Really even on UEFI, 500 MB is perhaps a bit too much, but 100 MB often ends up being quite tight, so at least 250 MB is definitely a good idea.)

On any Linux system, frequently the partition holds an initramfs image or two (~20–40 MB each), or the user might want to build in all the drivers into the vmlinuz image itself. One might want to have the mainline kernel and the LTS kernel installed at the same time – so multiply everything by two. One might want to use GRUB2, whose modules occupy another ~15 MB.

Specifically on UEFI, one might want to dual-boot or even triple-boot with Windows (~30 MB) or another operating system. Some manufacturers also use the EFI system partition to place files for firmware updates, which might occupy a few megabytes.

user1686

Posted 2019-10-21T20:07:56.043

Reputation: 283 655

I suddenly recalled that I'm using GPT. Is it okay? – Pierre Dunn – 2019-10-21T21:11:35.310

Yes: GPT and UEFI are like peanut butter and jam. – K7AAY – 2019-10-21T21:23:49.090

@undefined: ...It might be okay if you install LILO into the partition (VBR), and use e.g. Syslinux's gptmbr.bin as your MBR, and set the correct flag on the /boot partition. – user1686 – 2019-10-21T21:32:15.950