Lilo's second stage code loading
 

Hello:-)

As I know LILO is a two stages boot loader. Suppose we install it in the MBR so the first stage is loaded into MBR by "lilo"
command. But what about the second stage code? Some sources say that it's being written in the /root partition of the system from which lilo" command is executed and in such a case is loaded by looking through the partition table (located int MBR) for an active partition and then just executing the code in the partition's boot record. Other sources say the second stage code is "written somewhere on the hdd" and it's location is just hard-coded in the first stage code.
So which explanation is the correct one?

The second one.

It has been a while since I actively used LILO, and never used the EFI addition. But the MBR bootblock contains the block numbers where the rest of LILO resides. The lilo command identifies these block numbers from the filesystem it resides on to get those block numbers.

One of the early limitations of LILO was that those blocks had to reside within the area that the BIOS functions could load, and there were a limited number of them.

Note: The first stage is in the MBR, the second stage is is in the boot extension area. Both of these are loaded using the BIOS, the first is loaded, and started (where the L output comes from), That program (has to fit within 218 bytes) then directs the BIOS functions to load the extension area. NOTE: actual limitations depend on which boot format are being used... And it varies depending on the block size of the disk as well.
.
https://en.wikipedia.org/wiki/Master_boot_record

The above only gets LILO loaded, not the kernel. Once the two parts of lilo are loaded you have the option to select a kernel to load... each having its own list of blocks to be read into memory.

Much (or most?) of the complexity has been due to the original IBM layout. In the "good old days", the boot block was exactly 512 bytes, and had only the code to tell the disk controller what sector to start reading on, and the number of sectors to read. The kernel was in a contiguous sequence of blocks on disk, thus loading a kernel only took ONE read command. In the "not quite good old days" (meaning about 10 years advance) the kernel was replaced by a "boot" program that understood the filesystem enough to load a block list taken from a given files metadata. This "boot" program had to fit within one block (software defined block, usually 4k in size, or 8 sectors. And the BIOS took over most of these functions due to the complexity of various filesystems (different metadata, different storage...). And that extended strange coding for where the boot information could be stored...