Re: boot/repair floppy or CD

On Thu, 12 Jan 2006 16:24:41 +0100, mayayana <mayayanaXX1a@xxxxxxxxxxxxxxxx> wrote:

Hello, mayayana,

At this point I have seen Peter's response, which I find humurous.
Implicated, but not involved.  It is like a riddle you have to solve.

I know Peter wants that people learn to read manpages and how to investigate
everything themselves. So go and read man lilo, and see if you can find where
it says that lilo.conf is not involved during boot. I haven't read that
manpage for many years, and it has likely changed a bit since, but I guess
you won't find anything on first reading. Perhaps on third.

The information you put in lilo.conf is used by lilo when you run lilo.
Clear? Don't you see the difference? Blind? lilo, lilo, one runs under
Linux and installs a boot loader in the mbr (or where lilo.conf says),
the other runs without any kernel, but boots a kernel.  Everybody
sees that, don't you?  Guess which of the two reads the config file.
Lilo? Wrong! Lilo!

Lilo patches some numbers into the mbr, telling mbr where to find
the rest of lilo. That is, the other lilo.  It also stores somewhere the
sector numbers (addresses) of the sectors that contain the kernel.  In
this way, when you boot, lilo does not need to understand file system
data structures.  It just loads the sectors listed.

You changed the partition table, but I guess lilo didn't care much about
the partition table.  It just loads the sectors listed.  The sector numbers
are relative to the start of the disk anyway, Lilo loads the same sectors as
before and thereby loads the same kernel as before.  It also provides the
same command line options to the kernel as before.  Ooops!

 The /etc/fstab does not come into play until after the
kernel proper is booted, the root file system mounted, and "init" reads
/etc/inittab, and finds instructions to run the script
/etc/rc.d/rc.sysinit.



    Having thought about your explanation of the boot
sequence, could I ask you for a clarification?
    Would it be accurate to guess that boot
failed due to the wrong data in lilo.conf? Lilo started
OK, (from the root partition after being booted by
my main bootloader in the MBR). I then got:

mounting root /dev/root 

But which device is this, really?

no init found. Try passing init= option to kernel 

init is not initrd. init is the first program linux runs, appart
from the kernel itself.  It used to be the **only** program the kernel
would run by itself, all other programs used to be started by init,
or by programs started by init. Nowadays this is no longer quite
true, but it is still a usefull "lie".  See if you have a program
called /sbin/init. Linux looks for init a couple of places, /etc/init,
/bin/init, /sbin/init, /init, ... I don't know the exact list by heart,
so I am making it up a little, but the real list does not look all that
different - execpt I believe the real list ends with /bin/sh, so in
an emergency, the kernel tries to run a shell, if it cannot find any
init. But I guess the kernel did not find /bin/sh either.

How come?

Notice that if you have an initrd in your setup (it is not required if
your kernel has all it needs to moun the real root file system),
the kernel starts the init program it finds on the initrd, and this
init program eventually issues the commands to the kernel to mount
the real root, and then "pivots" the two file systems so the
real one becomes the top file system.  After that the provisional
init stops.  Exits.  The kernel is not really aware that the
ramdisk is something provisonal.  From the kernel's perspective
the system is up and running, and init is doing its things, and...
oops, "init" exited! Restart it! But this time, the strings /bin/init,
/sbin/init, etc., point the kernel to directories on the real root
file system. If and when the kernel eventually finds init a second
time, it is not the same provisional init. It's the real one.

umount2: device or resource not ready
kernel panic - not syncing: attempted to kill init!

  Init is initrd (or the longer-named file it points to)
I assume?


No

Which then loads the kernel? 

No

Which is
vmlinuz?


Yes -- /boot/vmlinuz-2.6.blah.blah

So apparently Lilo looks for a local conf file,
then uses that to proceed?


Lilo has finished its task and is happy. The kernel is running.
Lilo doesn't run any more.

  That would explain why lilo did not find initrd but still
had information about what it thought it should boot.


Would it?  Grub does something similar to what you suggest, but
lilo does not understand files.

So the message onscreen (above) was from lilo and not
from the Linux boot process?


No - yes - no - argh, what do you say in English, no or yes?
No, the message above was NOT from lilo.
No, the message above was NOT from the process of booting the kernel.
(I.e. not from loading the kernel into memory, and not even from
the kernel's initialization of its data structures.)
Yes, it is from booting, the kernel boots the userspace programs
by starting init. Init would take the booting further by running
the boot scripts as instructed to in /etc/inittab.

And it was confused
because it was searching on the FAT32 partition
for initrd?


Getting hotter. There was a game in my infancy which I believe
exists identically in many countries. You have to search for something
hidden, and everybody else knows where it is.  As you approach it,
you are told it's getting hotter.

The initrd is a file system image that the boot loader loads
into memory. The boot loader passes an extra command line option to the
kernel, and the kernel uses the initrd as a ram disk.  Initrd = Initial
ram disk.

The kernel mounts it as a provisional root file system, runs a provisional
init program (which used to be called "linuxrc", but nowadays... I don't
remember.)  The purpose is to load kernel modules needed to access the
real root file system.  This is so the kernel proper can be made slim.
When the real root file system has been mounted, the initrd is discarded.

To learn the details here, you need to mount the initrd again, using
the -o loop option (and a few more tricks), and look at the program
there. It is a script written for a rather special "shell" called
"nash". Man nash. On RedHat/Fedora, anyway. YMMV.

-Enrique
.

Relevant Pages

  • RE: Fedora Core 2 boot problems
    ... I am going to experiment with some kernel ... Given the above about lilo, ... boot loader after booting with the rescue disk. ... probably installed using ext3 for the file system type and those modules ...
    (Fedora)
  • Re: boot/repair floppy or CD
    ... > no init found. ... Try passing init= option to kernel ... name the correct root partition! ... So apparently Lilo looks for a local conf file, ...
    (comp.os.linux.misc)
  • re: no init found
    ... I have the same problem with lilo upgrading from a 2.6 kernel from Mandrake ... There is an init, but it isn't finding it for some reason, it ...
    (alt.os.linux.redhat)
  • 2.6.27-rc7 no init found on the root partition?
    ... but the kernel is unable to boot. ... XFS file system but no init found. ... it complains that root file system not found and I have ... # Input Device Drivers ...
    (Linux-Kernel)
  • v2.6.25-4569-gb69d398: Section mismatch in reference from the function uniq_ioapic_id() to t
    ... Section mismatch detected in this mornings build of kernel v2.6.25-4569-gb69d398. ... The function uniq_ioapic_idreferences ... This is often because uniq_ioapic_id lacks a __init ... CHK include/linux/utsrelease.h ...
    (Linux-Kernel)