crashing linux using lilo?

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 ???

<rxl124@hehe.com> wrote in message
news:8a1229a0.0307160936.5f7e6a7a@posting.google.c om...
> 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 ???

I can't imagine why you would want booting to fail, but what you need to do
is relatively simple.

login
su -
cd /etc
edit lilo.conf to offer no boot options for linux
save lilo.conf
run lilo
exit (back to login)
logout
reboot

If you retained any bootable options (e.g. memtest) that will be offered.
NOTE: you will now need a boot floppy or recovery disk to boot linux.

If what you're wanting is a way to completely keep lilo from running, boot a
DOS disk and run "fdisk /mbr" to re-write the master boot record of the
disk. Again, you'll need a boot floppy or recovery disk to boot Linux.

JW

On 16 Jul 2003 10:36:07 -0700, rxl124@hehe.com
<rxl124@hehe.com> wrote:
> 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
distros.

--
Here I am, fifty-eight, and I still don't know what I want to be when
I grow up.
-- Peter Drucker

"Jacob Westenbach" <westy528@yahoo.com> wrote in message news:<hsgRa.79778$xg5.27257@twister.austin.rr.com> ...
> <rxl124@hehe.com> wrote in message
> news:8a1229a0.0307160936.5f7e6a7a@posting.google.c om...
> > 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 ???
>
> I can't imagine why you would want booting to fail, but what you need to do
> is relatively simple.
>
> login
> su -
> cd /etc
> edit lilo.conf to offer no boot options for linux
> save lilo.conf
> run lilo
> exit (back to login)
> logout
> reboot
>
> If you retained any bootable options (e.g. memtest) that will be offered.
> NOTE: you will now need a boot floppy or recovery disk to boot linux.
>
> If what you're wanting is a way to completely keep lilo from running, boot a
> DOS disk and run "fdisk /mbr" to re-write the master boot record of the
> disk. Again, you'll need a boot floppy or recovery disk to boot Linux.
>
> JW

I guess the reason I am doing is I want to learn about the boot
process.

Now, my question is, I went ahead and did mess w/ lilo.conf(even
removed it) and then ran /sbin/lilo -v -v. which would not compile.
Does lilo program look at /etc/lilo.conf when it boots?
Also does lilo program(when in booting process), look at /boot
directory?

I guess above would be more valid question.

Please let me know.

thank you.

<rxl124@hehe.com> wrote in message
news:8a1229a0.0307170705.21c53ae2@posting.google.c om...
> "Jacob Westenbach" <westy528@yahoo.com> wrote in message
news:<hsgRa.79778$xg5.27257@twister.austin.rr.com> ...
> > <rxl124@hehe.com> wrote in message
> > news:8a1229a0.0307160936.5f7e6a7a@posting.google.c om...
> > > 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
> >
> > If what you're wanting is a way to completely keep lilo from running,
boot a
> > DOS disk and run "fdisk /mbr" to re-write the master boot record of the
> > disk. Again, you'll need a boot floppy or recovery disk to boot Linux.
> >
> I guess the reason I am doing is I want to learn about the boot
> process.
>
> Now, my question is, I went ahead and did mess w/ lilo.conf(even
> removed it) and then ran /sbin/lilo -v -v. which would not compile.
> Does lilo program look at /etc/lilo.conf when it boots?
> Also does lilo program(when in booting process), look at /boot
> directory?
>
> I guess above would be more valid question.

OK, now it makes a little more sense. I'll attempt an explanation of the
lilo/boot actions.

First, lilo only reads the /etc/lilo.conf when it is executed as root while
the system is running. Lilo reads each stanza (paragraph) of the .conf file
and effectively creates a boot menu from that data which is written to the
location you specify (generally to the mbr of the boot disk). The first
stanza in the list becomes the default (fall-through) action for booting.

When the machine is next booted, the "menu" created by lilo is activated by
the boot process presenting the various options created from the lilo.conf
stanzas. The selection of an option tells the boot process which partition
to mount in order to see the rest of the code necessary for the machine to
reach a useable state. That code can be stored anywhere you prefer, but the
most frequently used is the mountpoint of /boot which is also usually an
ext2 partition to aid in the use of utilities without having to load modules
to support other filesystem types (ext3, reiserfs, jfs, etc.).

More detailed info can be obtained from :

http://www.togaware.com/linux/surviv...ing_Linux.html

JW

Bill Marcum <bmarcum@iglou.com> wrote in message news:<l0chu-7ka.ln1@don.localnet>...
> On 16 Jul 2003 10:36:07 -0700, rxl124@hehe.com
> <rxl124@hehe.com> wrote:
> > 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
> distros.

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
overlook something?

On 17 Jul 2003 rxl124@hehe.com wrote:

> Bill Marcum <bmarcum@iglou.com> wrote in message news:<l0chu-7ka.ln1@don.localnet>...
> > On 16 Jul 2003 10:36:07 -0700, rxl124@hehe.com
> > <rxl124@hehe.com> wrote:
> > > 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
> > distros.
>
> 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
> overlook something?

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.



>

Whoever wrote:
> On 17 Jul 2003 rxl124@hehe.com wrote:
>
>
>>Bill Marcum <bmarcum@iglou.com> wrote in message news:<l0chu-7ka.ln1@don.localnet>...
>>
>>>On 16 Jul 2003 10:36:07 -0700, rxl124@hehe.com
>>> <rxl124@hehe.com> wrote:
>>>
>>>>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
>>>distros.
>>
>>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
>>overlook something?
>
>
> 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.

Alex