LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Do we need a ramdisk when boot from IDE disk and why? (https://www.linuxquestions.org/questions/linux-newbie-8/do-we-need-a-ramdisk-when-boot-from-ide-disk-and-why-4175471390/)

hilou 07-29-2013 08:46 PM

Do we need a ramdisk when boot from IDE disk and why?
 
Hi,

I'm a linux newbie and recently I read from a book on which said when linux do not need a ramdisk when booting from IDE disk. Could you please tell me why and also why we need ramdisk when boot from other disk?

Thanks in advance.

rknichols 07-29-2013 08:59 PM

The requirement is that all drivers needed to boot and successfully mount the root file system must have been built into the kernel. If any needed driver was built as a loadable module, then the kernel needs somewhere from which to load that module, and that "somewhere" is a ramdisk.

jpollard 07-30-2013 04:47 AM

Quote:

Originally Posted by hilou (Post 4999276)
Hi,

I'm a linux newbie and recently I read from a book on which said when linux do not need a ramdisk when booting from IDE disk. Could you please tell me why and also why we need ramdisk when boot from other disk?

Thanks in advance.

It can avoid using a ramdisk only if the ide disk is built in. Most distributions don't include even IDE drivers. Just the ramdisk as it is as close to a zero cost code block as the entire data part can be discarded. Once the kernel itself boots, it mounts the ramdisk (empty), and loads the ramdisk from the initrd (and frees the memory the initrd used). So far, only memory is being manipulated (it is the only thing guaranteed to exist...), so once the root filesystem (the ramdisk) can be used, a device initialization scan can be done (in fedora, by udev) which builds the /dev directory tree and loads the other drivers as identified by the hardware. Many systems at this point only have rules for disks, as that is what it is looking for to mount the real root filesystem. The real root is usually identified on the boot command line (the "root=" kernel option, either by volume name or UUID).

The real root gets mounted in /mnt (which may use a loaded driver), a pivot_root system call is used to exchange the mount point of the existing root (the ramdisk) with /mnt. Once this is done, the /mnt (the ramdisk) is dismounted. The last step in the kernel init is to exec the /usr/sbin/init on the real root filesystem.

One advantage this has is that you can take a system on one disk (using some driver) and load it on any other system even if that new system uses a different controller for root. NOTE: this still means that the DRIVER for that different controller must be in the initrd used.

hilou 08-01-2013 08:49 PM

Quote:

Originally Posted by rknichols (Post 4999282)
The requirement is that all drivers needed to boot and successfully mount the root file system must have been built into the kernel. If any needed driver was built as a loadable module, then the kernel needs somewhere from which to load that module, and that "somewhere" is a ramdisk.

But the ramdisk file initrd is also located on the disk which means you cannot load initrd before you drive the disk. This sounds like paradox.

Ser Olmy 08-01-2013 08:59 PM

Quote:

Originally Posted by hilou (Post 5001281)
But the ramdisk file initrd is also located on the disk which means you cannot load initrd before you drive the disk. This sounds like paradox.

It's not. The initrd is loaded by the same bootloader that loads the kernel.

hilou 08-02-2013 03:55 AM

Hi All,

Let's assume our server only have one partition(/), then the initrd and vmlinz file should located at disk in /boot/ directory.

Now my question is how does boot loader find these files since the disk is not driven yet and we should drive the disk to get the initrd file to drive the disk which sounds like a paradox.

Br,

TimothyEBaldwin 08-02-2013 05:20 AM

The bootloader uses the firmware (eg UEFI or BIOS) device drivers which are stored in flash memory. This flash memory requires no drivers to read.

jpollard 08-02-2013 06:29 AM

In addition, the boot block identifies the disk it is for, using that information grub (the boot loader in question) can load the boot menu - which provides the list of kernels (and initrd files) that can be selected. When selected, that kernel is loaded into memory, then the initrd loaded immediately after. This way the kernel (when activated) can access the initrd directly (in memory) without the need for any driver initialization.

One of the confusing things that the current Fedora is doing though, is to copy the system /etc/fstab into the initrd (it fails if you change swap). Haven't seen any reason, but this would be useful ONLY if the system has insufficient memory to run the actual initrd root. Unfortunately, it made it mandatory so the initrd should be rebuilt if the /etc/fstab is modified.

Ser Olmy 08-02-2013 12:02 PM

Quote:

Originally Posted by hilou (Post 5001463)
Now my question is how does boot loader find these files since the disk is not driven yet and we should drive the disk to get the initrd file to drive the disk which sounds like a paradox.

You might as well ask "how can the computer display a picture on the screen, or indeed do anything when I turn on the power, when there's no operating system?" The answer is that every computer has a built-in program that starts automatically when you turn it on. This used to be called the BIOS, but Intel has been trying for the last 10 years or so (with some success) to replace this with a vastly more complex system called UEFI.

One of the tasks this program is responsible for performing, is to identify the boot device, load the bootloader, and provide a system call that the bootloader can use to read data from the boot device. That's how the bootloader gets loaded, and that's how the bootloader can access the disk to fetch the kernel and the initrd.

jpollard 08-02-2013 01:35 PM

Note, the following is based on grub 0.99 and not grub2. I find grub simpler and FAR easier to follow than the grub2 multiple files.. and script programming. It may be nice and all, but is way more bloated than necessary in my opinion.

The boot loader is directed during installation... If you look at the grub configuration file it will have a "root=", which is where grub itself is located (device and partition). Grub itself is loaded by the bios, so the device specified by the bios configuration is used to load grub.

The "root" option directs grub to the device. Note it doesn't use Linux device names. These names are defined by the bios, hence they will have "(hd<unit>,<partition>)". This device/partition has nothing to do with Linux. Grub then uses this device/partition and a built in filesystem handling to read the directories for files. By convention, this device is (as far as grub is concerned) the root filesystem. All grub needs is the filename for the kernel and the initrd.

The kernel line looks like "kernel /vmlinuz-3.9.0 ro root=UUID=<disk UUID hex value> rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet". Of these options, only the root= kernel option defines what filesystem is to be used for the Linux root. Using a UUID allows the filesystem to be identified in a very specific device, but in a way that is independent of device names. The file "/vmlinuz-3.9.0" is kernel to be loaded (remember that the path is interpreted by grub, not Linux, so "/" in this case is the device/partition specified by the "root" line).

The initrd is specified similarly, but there are no options there as the initrd is just a compressed cpio of the filesystem. The specification "initrd /initramfs-3.9.0.img" simply identifies the file to load.

grub itself uses the bios for all I/O, which is why the device names used have to follow the BIOS names. Once the kernel and initrd are loaded into memory, grub transfers to the starting address of the kernel (specified in the kernel image itself). After that, grub no longer has anything to do, and the memory it uses will get reclaimed.

hilou 08-04-2013 10:12 PM

Hi All,

Thanks very much for your patient explanation.

I've learned a lot.

Best Regards.


All times are GMT -5. The time now is 06:39 AM.