>>>>I have redhat 8.0
>>>>I am experimenting w/ lilo and see if I can make it
>>>>actually, i am tring to make it that lilo boot up sequence will fail
>>>>I tried few things
>>>>1)messing w/ lilo.conf
>>>>2)removing lilo.conf all toghether
>>>>3)moving or messing w/ /boot folder
>>>>NONE of them make it fail to boot up linux.
>>>>What is going on?
>>>>Can someone tell me what's going on w/ this ???
>>>Lilo.conf is only read when you run /sbin/lilo. The lilo boot loader
>>>does not read the file system, it reads information that was stored by
>>>the /sbin/lilo program. If you "mv" a file or folder within the same
>>>filesystem, you only rename it, and the physical location of the data
>>>stays the same. Look for the lilo documentation. On a Debian system it
>>>is in /usr/share/doc/lilo. The exact location might vary in other
>>Thank you guys. Now, I have skimped over the share doc and i
>>understand now the structure of /boot and lilo
>>However, I still don't understand how my machine was able to boot up,
>>AFTER I removed /boot folder altogether..? Is it possible? or did I
> It depends what yo mean by "removed". I saw this very same behaviour very
> recently and came up with the solution: At boot time, Lilo does not care
> about what is mounted or not. In fact, nothing is mounted at that time.
> Lilo looks for the file in the specified PARTITION. THe partition for
> /boot is defined when /sbin/lilo is run.
> So, if you removed /boot by merely removing the mount of a /boot
> partition, you did nothing that affects lilo's boot process. Once booted
> up, the system will appear to have no kernel or files from which to boot,
> but really they are in the unmounted /boot partition.
Actually, the lilo boot loager (as poopsed to the config program called
lilo) doesn't know anything about partitions even. It just knows "I can
find the kernel at this block on the disk. If you delete the kernel
file, the filesystem removes the links to it, and marks the space as
available, but it doesn't actually wipe the data, hence as long as it
doesn't get overwritten, the boot loader on boot reads the blocks it
know about, and there's still a valid kernel there.