Note: Half of this was written purely based on the LILO documentation.
What does the lba32 option do, and do I need it? Is it okay that I didn't label the boot entry?
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 installation or should I do it by myself?
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 do people say to have a 500M boot partition if my kernel image 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.
