This has baffled me, and a few of some linux users I know:

The kernel generally has built in support for ext2, ext3, reiserfs.... and if it dosen't, the proper modules come from initrd. It is my understanding that a drive must first be mounted before anything can be done to it (read, write, execute.) Yet here is the dilemma: the kernel and initrd reside on hard disks. In order to mount hard drives, the kernel must be running. Where does the kernel come from? The unmounted hard drive!

This is somewhat theological question, too. Where did advanced humans come from? We have the ability to procreate (mount additional file systems) but we have no idea how the first file system got mounted (how the first human came about). See the parallel? Lol, I'm not suggesting that God mounts hard drives for the kernel, but it sure as hell seems that way, because I can't comprehend how something on an unmounted hard drive can mount itself. Maybe the answer to that question can be ported to theology. =) Linux, solving the questions of the universe!

I'm su... err, so curious!
Travers

My guess would be that Simply put: Grub Bios etc streams the Kernel via hard disk into memory

Yapp Thanks for helping me to fresh my knowledge up on this

http://penguinppc.org/embedded/howto/x525.html

1.

Processor comes out of reset and branches to the ROM startup code.
2.

The ROM startup code initializes the CPU and memory controller, performing only minimal initialization of on-chip devices, such as the console serial port (typically SMC1 on 8xx devices) to provide boot diagnostic messages. It also sets up the memory map for the kernel to use in a format that is consistent across platforms, and then jumps to the boot loader.
3.

The boot loader decompresses the kernel into RAM, and jumps to it.
4.

The kernel sets up the caches, initializes each of the hardware devices via the init function in each driver, mounts the root filesystem and execs the init process, which is the ultimate parent of all user mode processes, typically /sbin/initd.
5.

Executing the first program linked against the shared C runtime library (often init) causes the shared runtime library to be loaded.
6.

In a typical Linux system, init reads /etc/inittab to execute the appropriate run control script from /etc/rc.d, which execute the start scripts to initialize networking and other system services.

In minimal embedded systems, init is commonly replaced with a simple C program or shell script to start the appropriate services and application programs, since the conventional rc scripts are often overkill.

3.

The boot loader decompresses the kernel into RAM, and jumps to it.

So Bios calls Grub Grub streams Kernel in (in old DOS things Io.SYS etc had to be at the beginning of a disk) so the command is go to cluster x and stream in data no file system needed. Like a music cd maybe as comparison.
As you know you still have to partition etc and low level partition. These can maybe described as initial "file systems". There is some order therefore a structured way to access .

Essentially the bootloader jumps to some memory adress 0000:0000 or whatever, where then the processor starts executing the commands there: jump push etc. Like you see in Assembler code

Remember always that there is already a program running from the Basic Input Output System aka BIOS So Bios is your God I would assume

I remember from my old assembler days you could call either sometimes BIOS routines or DOS routines.

http://www.pcguide.com/ref/mbsys/bio...ervices-c.html

And I have the sad news to report Wendys does it in a similar way Even Bill has to use the BIOS

Rumours that Wendys uses not a Kernel but only Bills evil essence are being looked into though.

So essentially GRUB can put the kernel into RAM without knowlege of a file system on the hard disk. Cool.

How is it that the BIOS is God and not Grub? I'm not farmiliar with the BIOS except the setup... please explain.

Travers

Well the BIOS is essentially a program that does your hardware checks. Its just another program that is closer to the machine. It has interrupts etc that you can call to your devices

http://www.xaff.org/GI/biosref.html

* Int 10h, function 0Eh : write a character
* Int 13h, function 00h : reset drive
* Int 13h, function 02h : read from disk
* Int 13h, function 03h : write to disk
* Int 13h, error codes
* Int 16h, function 00h : read a character
* Int 18h : call BASIC
* Int 19h : reboot


etc etc

Its what gives you all the neat messages about you disks etc when you boot up.

i.e
Int 13h, function 02h : read from disk

"This function reads data from one or more sectors of a floppy disk or a hard drive to a buffer. The first floppy drive has number 00h, the second 01h. The first hard disk has number 80h, the second 81h.
The content of the registers BX, CX, DX, SI, DI, BP and the segment registers is not modified by this function. The content of the other registers may have been altered."

so the bios basically says look for Bootloader at place/disk bla at sector x then bootloader says read data from place bloe and put into memory then

Ok, that makes sense. We're getting down to a hardware level now. BIOS ---> GRUB ---> KERNEL