chicken-Egg problem in booting sequence
 

Kindly Explain me the chicken-Egg problem in
booting sequence.......

This looks like one in a long string of homework questions.

Do you have Linux installed? If so, what version?
What bootloader are you using?

And......If you tell us what is the "chicken-Egg problem" in this context, we might be able to help.

Never boot a chicken when it's laying eggs, unless you want them ready-scrambled.

brian*;
Why do I think that you are a candidate for: http://badpuns.com/

:D I must bookmark that page.

While booting, the Kernel has to mount the root file system, and the root file system can be accessed by modules. But these modules are present inside the Root file system itself. Now the question here is, how can the root file system be mounted when the modules, that are responsible for mounting this root file system, are within the root file system itself. This is something like 'How do you get a chicken when you do not have an egg? And how do you get an egg when you do not have a chicken?' Hence, it is called the Chicken-Egg problem.

So, we use 'initrd' image file. This is an image file that consists of necessary modules to mount the root file system, in read-only module. Once the RFS is mounted, then the modules are invoked and then the RFS is again mounted in RW mode.

Let me know, anybody, if I am wrong.

Hi,

Yes, http://badpuns.com/ would add to your scholarly position(s). :) Barking seems to fit!

:hattip:

need details
 

Can somebody delve deep into booting . I know that
first 512 bytes of hard disk form MBR which points to partition to boot from . From that address bootloader is loaded . What next ?

This post is almost 3yrs old, why not start a new thread so as to get the help you need.

Acer? I thought the Dell Latitude laptops are very robust for installing Linux and also Vmware.

You've been registered here for FIVE YEARS...by now, you should know not to hijack someone elses thread, or re-open old ones. And if you put "how does linux boot" into Google, the VERY FIRST HIT is:
http://www.ibm.com/developerworks/library/l-linuxboot/

I would say, incomplete. The problem is that you move the location of the question to the initrd...

When the kernel is loaded, it usually has two mandatory drivers. ramfs for a memory resident filesystem, and a console.

The way thing go, is the when the kernel is loaded (by grub, lilo...) it is also loaded with a compressed cpio archive of a mini-root filesystem (the initrd). The kernel level init process mounts the ramfs, and then copies (memory to filesystem) the initrd passing it through a cpio (also built in) to create a memory resident filesystem, after which the initrd is deallocated. This memory resident filesystem is used as root, so the kernel level init process executes a startup shell script on that filesystem. The script is used to load modules as needed (it has a udev service on board that builds another memory resident filesystem, devfs, than ends up mounted as /dev ).

Once the device scan is finished, the script goes through all partitions looking for the partition designated on the kernel command line (the "root=" parameter). It mounts the identified partition on /mnt. Once this is completed, the script exits...

Now the kernel init uses the /mnt mounted disk based root and invokes a little used system call "piviot_root" - which exchanges the /mnt data stucture describing the mount, and the mini-root mount. After this is completed, the mini-root (now located on /mnt) is dismounted (memory reclaimed) and the kernel init execs the /usr/sbin/init executable from disk.

After that, the rest of the system is brought up- /dev is mounted, other disk mounts, and then any services.

Note: it IS possible to bypass this. But to do so requires the kernel to have the driver for the disk built in and the root filesystem type builtin, and to have the root device specified by driver name. I'm not sure that even the partition UUIDs and labels are yet known.