How does a kernel mount the root partition?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
23
down vote

favorite
22












My question is with regards to booting a Linux system from a separate /boot partition. If most configuration files are located on a separate / partition, how does the kernel correctly mount it at boot time?



Any elaboration on this would be great. I feel as though I am missing something basic. I am mostly concerned with the process and order of operations.



Thanks!



EDIT: I think what I needed to ask was more along the lines of the dev file that is used in the root kernel parameter. For instance, say I give my root param as root=/dev/sda2. How does the kernel have a mapping of the /dev/sda2 file?










share|improve this question























  • Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
    – Faheem Mitha
    Mar 26 '11 at 18:32










  • You can't mount /boot without having / mounted first, since there is no /boot directory without /.
    – psusi
    Aug 4 '11 at 15:02














up vote
23
down vote

favorite
22












My question is with regards to booting a Linux system from a separate /boot partition. If most configuration files are located on a separate / partition, how does the kernel correctly mount it at boot time?



Any elaboration on this would be great. I feel as though I am missing something basic. I am mostly concerned with the process and order of operations.



Thanks!



EDIT: I think what I needed to ask was more along the lines of the dev file that is used in the root kernel parameter. For instance, say I give my root param as root=/dev/sda2. How does the kernel have a mapping of the /dev/sda2 file?










share|improve this question























  • Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
    – Faheem Mitha
    Mar 26 '11 at 18:32










  • You can't mount /boot without having / mounted first, since there is no /boot directory without /.
    – psusi
    Aug 4 '11 at 15:02












up vote
23
down vote

favorite
22









up vote
23
down vote

favorite
22






22





My question is with regards to booting a Linux system from a separate /boot partition. If most configuration files are located on a separate / partition, how does the kernel correctly mount it at boot time?



Any elaboration on this would be great. I feel as though I am missing something basic. I am mostly concerned with the process and order of operations.



Thanks!



EDIT: I think what I needed to ask was more along the lines of the dev file that is used in the root kernel parameter. For instance, say I give my root param as root=/dev/sda2. How does the kernel have a mapping of the /dev/sda2 file?










share|improve this question















My question is with regards to booting a Linux system from a separate /boot partition. If most configuration files are located on a separate / partition, how does the kernel correctly mount it at boot time?



Any elaboration on this would be great. I feel as though I am missing something basic. I am mostly concerned with the process and order of operations.



Thanks!



EDIT: I think what I needed to ask was more along the lines of the dev file that is used in the root kernel parameter. For instance, say I give my root param as root=/dev/sda2. How does the kernel have a mapping of the /dev/sda2 file?







linux kernel boot mount






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 23 '11 at 18:34

























asked Mar 23 '11 at 12:26









Mr. Shickadance

2,19961825




2,19961825











  • Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
    – Faheem Mitha
    Mar 26 '11 at 18:32










  • You can't mount /boot without having / mounted first, since there is no /boot directory without /.
    – psusi
    Aug 4 '11 at 15:02
















  • Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
    – Faheem Mitha
    Mar 26 '11 at 18:32










  • You can't mount /boot without having / mounted first, since there is no /boot directory without /.
    – psusi
    Aug 4 '11 at 15:02















Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
– Faheem Mitha
Mar 26 '11 at 18:32




Though people below cover initrd, there is little discussion about why initrd is used. My impression is that is because distributions like Debian want to use one kernel on many different machines of the same architecture, but possibly widely different hardware. This is made possible by modularizing hardware support via kernel modules. The initrd does not require much hardware support to boot, and once it does, it loads the necessary hardware modules to proceed. Elaborations/corrections to this are appreciated.
– Faheem Mitha
Mar 26 '11 at 18:32












You can't mount /boot without having / mounted first, since there is no /boot directory without /.
– psusi
Aug 4 '11 at 15:02




You can't mount /boot without having / mounted first, since there is no /boot directory without /.
– psusi
Aug 4 '11 at 15:02










6 Answers
6






active

oldest

votes

















up vote
17
down vote



accepted










Linux initially boots with a ramdisk (called an initrd, for "INITial RamDisk") as /. This disk has just enough on it to be able to find the real root partition (including any driver and filesystem modules required). It mounts the root partition onto a temporary mount point on the initrd, then invokes pivot_root(8) to swap the root and temporary mount points, leaving the initrd in a position to be umounted and the actual root filesystem on /.






share|improve this answer


















  • 1




    What if you don't have an initrd like LFS (linuxfromscratch.org)?
    – Mr. Shickadance
    Mar 23 '11 at 12:38










  • @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
    – geekosaur
    Mar 23 '11 at 12:55







  • 3




    @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
    – jonescb
    Mar 23 '11 at 19:44






  • 1




    @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
    – geekosaur
    Mar 26 '11 at 18:41







  • 1




    The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
    – psusi
    Aug 4 '11 at 14:32

















up vote
37
down vote













In ancient times, the kernel was hard coded to know the device major/minor number of the root fs and mounted that device after initializing all device drivers, which were built into the kernel. The rdev utility could be used to modify the root device number in the kernel image without having to recompile it.



Eventually boot loaders came along and could pass a command line to the kernel. If the root= argument was passed, that told the kernel where the root fs was instead of the built in value. The drivers needed to access that still had to be built into the kernel. While the argument looks like a normal device node in the /dev directory, there obviously is no /dev directory before the root fs is mounted, so the kernel can not look up a dev node there. Instead, certain well known device names are hard coded into the kernel so the string can be translated to the device number. Because of this, the kernel can recognize things like /dev/sda1, but not more exotic things like /dev/mapper/vg0-root or a volume UUID.



Later, the initrd came into the picture. Along with the kernel, the boot loader would load the initrd image, which was some kind of compressed filesystem image (gzipped ext2 image, gzipped romfs image, squashfs finally became dominant). The kernel would decompress this image into a ramdisk and mount the ramdisk as the root fs. This image contained some additional drivers and boot scripts instead of a real init. These boot scripts performed various tasks to recognize hardware, activate things like raid arrays and LVM, detect UUIDs, and parse the kernel command line to find the real root, which could now be specified by UUID, volume label and other advanced things. It then mounted the real root fs in /initrd, then executed the pivot_root system call to have the kernel swap / and /initrd, then exec /sbin/init on the real root, which would then unmount /initrd and free the ramdisk.



Finally, today we have the initramfs. This is similar to the initrd, but instead of being a compressed filesystem image that is loaded into a ramdisk, it is a compressed cpio archive. A tmpfs is mounted as the root, and the archive is extracted there. Instead of using pivot_root, which was regarded as a dirty hack, the initramfs boot scripts mount the real root in /root, delete all files in the tmpfs root, then chroot into /root, and exec /sbin/init.






share|improve this answer


















  • 1




    After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
    – jiggunjer
    Jan 17 '17 at 3:54










  • @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
    – psusi
    Jan 18 '17 at 13:43










  • I learned something new about every iteration of root fs that you mentioned. Great answer!
    – jpaugh
    Sep 2 '17 at 1:04

















up vote
3
down vote













Sounds like you're asking how does the kernel "know" which partition is the root partition, without access to configuration files on /etc.



The kernel can accept command line arguments like any other program. GRUB, or most other bootloaders can accept command line arguments as user input, or store them and make various combinations of command line arguments available via a menu. The bootloader passes the command line arguments to the kernel when it loads it (I don't know the name or mechanics of this convention but it's probably similar to how an application receives command line arguments from a calling process in a running kernel).



One of those command line options is root, where you can specify the root filesystem, i.e. root=/dev/sda1.



If the kernel uses an initrd, the bootloader is responsible for telling the kernel where it is, or putting the initrd in a standard memory location (I think) - that's at least the way it works on my Guruplug.



It's entirely possible to not specify one and then have your kernel panic immediately after starting complaining that it can't find a root filesystem.



There might be other ways of passing this option to the kernel.






share|improve this answer
















  • 3




    This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
    – Gilles
    Mar 23 '11 at 20:44










  • @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
    – jiggunjer
    Jan 17 '17 at 4:00






  • 1




    @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
    – Gilles
    Jan 17 '17 at 13:41

















up vote
1
down vote













Grub mounts the /boot partition and then executes the kernel. In Grub's configuration, it tells the kernel what to use as the root device.



For example in Grub's menu.lst:



kernel /boot/linux root=/dev/sda2





share|improve this answer



























    up vote
    1
    down vote













    C'mon, GRUB doesn't "mount" /boot, it just reads 'menu.lst' and some modules, it isn't part of LINUX kernel either. When you call the kernel, you will pass a "root" argument with the root partition. At worst, the kernel knows that just /boot has been mounted (LOL).



    Next: geekosaur is right, Linux uses an initial ramdisk in compressed image format, and then mounts the real root filesystem by calling pivot_root. So Linux starts running from an image, and then from your local disk drive.






    share|improve this answer




















    • Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
      – Shadur
      Mar 23 '11 at 12:55







    • 5




      ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
      – jsbillings
      Mar 23 '11 at 12:58







    • 2




      @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
      – D4RIO
      Mar 23 '11 at 13:02






    • 1




      @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
      – D4RIO
      Mar 23 '11 at 13:10










    • @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
      – Shadur
      Mar 23 '11 at 13:21

















    up vote
    1
    down vote













    The boot loader, be it grub or lilo or whatever, tells the kernel where to look with the root= flag, and optionally loads an initial ramdisk into memory via initrd before booting the kernel.



    The kernel then loads, tests its hardware and device drivers and looks around the system for what it can see (you can review this diagnostic info by typing dmesg; nowadays it likely scrolls by way too fast to see) then attempts to mount the partition mentioned in the root= parameter.



    If an initrd is present, it's mounted first and any modules/device drivers on it are loaded and probed out before the root filesystem is mounted. This way you can compile the drivers for your hard drives as modules and still be able to boot.






    share|improve this answer




















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f9944%2fhow-does-a-kernel-mount-the-root-partition%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      6 Answers
      6






      active

      oldest

      votes








      6 Answers
      6






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      17
      down vote



      accepted










      Linux initially boots with a ramdisk (called an initrd, for "INITial RamDisk") as /. This disk has just enough on it to be able to find the real root partition (including any driver and filesystem modules required). It mounts the root partition onto a temporary mount point on the initrd, then invokes pivot_root(8) to swap the root and temporary mount points, leaving the initrd in a position to be umounted and the actual root filesystem on /.






      share|improve this answer


















      • 1




        What if you don't have an initrd like LFS (linuxfromscratch.org)?
        – Mr. Shickadance
        Mar 23 '11 at 12:38










      • @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
        – geekosaur
        Mar 23 '11 at 12:55







      • 3




        @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
        – jonescb
        Mar 23 '11 at 19:44






      • 1




        @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
        – geekosaur
        Mar 26 '11 at 18:41







      • 1




        The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
        – psusi
        Aug 4 '11 at 14:32














      up vote
      17
      down vote



      accepted










      Linux initially boots with a ramdisk (called an initrd, for "INITial RamDisk") as /. This disk has just enough on it to be able to find the real root partition (including any driver and filesystem modules required). It mounts the root partition onto a temporary mount point on the initrd, then invokes pivot_root(8) to swap the root and temporary mount points, leaving the initrd in a position to be umounted and the actual root filesystem on /.






      share|improve this answer


















      • 1




        What if you don't have an initrd like LFS (linuxfromscratch.org)?
        – Mr. Shickadance
        Mar 23 '11 at 12:38










      • @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
        – geekosaur
        Mar 23 '11 at 12:55







      • 3




        @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
        – jonescb
        Mar 23 '11 at 19:44






      • 1




        @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
        – geekosaur
        Mar 26 '11 at 18:41







      • 1




        The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
        – psusi
        Aug 4 '11 at 14:32












      up vote
      17
      down vote



      accepted







      up vote
      17
      down vote



      accepted






      Linux initially boots with a ramdisk (called an initrd, for "INITial RamDisk") as /. This disk has just enough on it to be able to find the real root partition (including any driver and filesystem modules required). It mounts the root partition onto a temporary mount point on the initrd, then invokes pivot_root(8) to swap the root and temporary mount points, leaving the initrd in a position to be umounted and the actual root filesystem on /.






      share|improve this answer














      Linux initially boots with a ramdisk (called an initrd, for "INITial RamDisk") as /. This disk has just enough on it to be able to find the real root partition (including any driver and filesystem modules required). It mounts the root partition onto a temporary mount point on the initrd, then invokes pivot_root(8) to swap the root and temporary mount points, leaving the initrd in a position to be umounted and the actual root filesystem on /.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Mar 26 '11 at 17:57









      Kevin M

      1,71211212




      1,71211212










      answered Mar 23 '11 at 12:31









      geekosaur

      22.2k25853




      22.2k25853







      • 1




        What if you don't have an initrd like LFS (linuxfromscratch.org)?
        – Mr. Shickadance
        Mar 23 '11 at 12:38










      • @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
        – geekosaur
        Mar 23 '11 at 12:55







      • 3




        @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
        – jonescb
        Mar 23 '11 at 19:44






      • 1




        @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
        – geekosaur
        Mar 26 '11 at 18:41







      • 1




        The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
        – psusi
        Aug 4 '11 at 14:32












      • 1




        What if you don't have an initrd like LFS (linuxfromscratch.org)?
        – Mr. Shickadance
        Mar 23 '11 at 12:38










      • @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
        – geekosaur
        Mar 23 '11 at 12:55







      • 3




        @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
        – jonescb
        Mar 23 '11 at 19:44






      • 1




        @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
        – geekosaur
        Mar 26 '11 at 18:41







      • 1




        The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
        – psusi
        Aug 4 '11 at 14:32







      1




      1




      What if you don't have an initrd like LFS (linuxfromscratch.org)?
      – Mr. Shickadance
      Mar 23 '11 at 12:38




      What if you don't have an initrd like LFS (linuxfromscratch.org)?
      – Mr. Shickadance
      Mar 23 '11 at 12:38












      @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
      – geekosaur
      Mar 23 '11 at 12:55





      @Mr. Shickadance: Not having looked into how LFS does things, I would guess that they make sure the kernel has all necessary modules compiled into it (or loaded via GRUB 2, which possibility is new enough that not many distributions have noticed it yet) so it can start on the actual root partition.
      – geekosaur
      Mar 23 '11 at 12:55





      3




      3




      @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
      – jonescb
      Mar 23 '11 at 19:44




      @mr. Shickadance. It's not just LFS that doesn't have an initrd. Anyone who compiles their own kernel has the option of not using an initrd, which is what I do on Gentoo.
      – jonescb
      Mar 23 '11 at 19:44




      1




      1




      @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
      – geekosaur
      Mar 26 '11 at 18:41





      @Faheem: grub2 modules are not the same as kernel modules. I see some ability for grub2 to load kernel modules, but one thing I don't know is whether that will work for the Linux kernel or only for *BSD (where the bootloader loading kernel modules is normal). I suspect the kernel needs to be taught where to find the address map for loaded modules, and everyone needs to move to grub2 (grub1 is still standard in some distributions).
      – geekosaur
      Mar 26 '11 at 18:41





      1




      1




      The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
      – psusi
      Aug 4 '11 at 14:32




      The initrd has been replaced by initramfs, since pivot_root was regarded as a dirty hack.
      – psusi
      Aug 4 '11 at 14:32












      up vote
      37
      down vote













      In ancient times, the kernel was hard coded to know the device major/minor number of the root fs and mounted that device after initializing all device drivers, which were built into the kernel. The rdev utility could be used to modify the root device number in the kernel image without having to recompile it.



      Eventually boot loaders came along and could pass a command line to the kernel. If the root= argument was passed, that told the kernel where the root fs was instead of the built in value. The drivers needed to access that still had to be built into the kernel. While the argument looks like a normal device node in the /dev directory, there obviously is no /dev directory before the root fs is mounted, so the kernel can not look up a dev node there. Instead, certain well known device names are hard coded into the kernel so the string can be translated to the device number. Because of this, the kernel can recognize things like /dev/sda1, but not more exotic things like /dev/mapper/vg0-root or a volume UUID.



      Later, the initrd came into the picture. Along with the kernel, the boot loader would load the initrd image, which was some kind of compressed filesystem image (gzipped ext2 image, gzipped romfs image, squashfs finally became dominant). The kernel would decompress this image into a ramdisk and mount the ramdisk as the root fs. This image contained some additional drivers and boot scripts instead of a real init. These boot scripts performed various tasks to recognize hardware, activate things like raid arrays and LVM, detect UUIDs, and parse the kernel command line to find the real root, which could now be specified by UUID, volume label and other advanced things. It then mounted the real root fs in /initrd, then executed the pivot_root system call to have the kernel swap / and /initrd, then exec /sbin/init on the real root, which would then unmount /initrd and free the ramdisk.



      Finally, today we have the initramfs. This is similar to the initrd, but instead of being a compressed filesystem image that is loaded into a ramdisk, it is a compressed cpio archive. A tmpfs is mounted as the root, and the archive is extracted there. Instead of using pivot_root, which was regarded as a dirty hack, the initramfs boot scripts mount the real root in /root, delete all files in the tmpfs root, then chroot into /root, and exec /sbin/init.






      share|improve this answer


















      • 1




        After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
        – jiggunjer
        Jan 17 '17 at 3:54










      • @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
        – psusi
        Jan 18 '17 at 13:43










      • I learned something new about every iteration of root fs that you mentioned. Great answer!
        – jpaugh
        Sep 2 '17 at 1:04














      up vote
      37
      down vote













      In ancient times, the kernel was hard coded to know the device major/minor number of the root fs and mounted that device after initializing all device drivers, which were built into the kernel. The rdev utility could be used to modify the root device number in the kernel image without having to recompile it.



      Eventually boot loaders came along and could pass a command line to the kernel. If the root= argument was passed, that told the kernel where the root fs was instead of the built in value. The drivers needed to access that still had to be built into the kernel. While the argument looks like a normal device node in the /dev directory, there obviously is no /dev directory before the root fs is mounted, so the kernel can not look up a dev node there. Instead, certain well known device names are hard coded into the kernel so the string can be translated to the device number. Because of this, the kernel can recognize things like /dev/sda1, but not more exotic things like /dev/mapper/vg0-root or a volume UUID.



      Later, the initrd came into the picture. Along with the kernel, the boot loader would load the initrd image, which was some kind of compressed filesystem image (gzipped ext2 image, gzipped romfs image, squashfs finally became dominant). The kernel would decompress this image into a ramdisk and mount the ramdisk as the root fs. This image contained some additional drivers and boot scripts instead of a real init. These boot scripts performed various tasks to recognize hardware, activate things like raid arrays and LVM, detect UUIDs, and parse the kernel command line to find the real root, which could now be specified by UUID, volume label and other advanced things. It then mounted the real root fs in /initrd, then executed the pivot_root system call to have the kernel swap / and /initrd, then exec /sbin/init on the real root, which would then unmount /initrd and free the ramdisk.



      Finally, today we have the initramfs. This is similar to the initrd, but instead of being a compressed filesystem image that is loaded into a ramdisk, it is a compressed cpio archive. A tmpfs is mounted as the root, and the archive is extracted there. Instead of using pivot_root, which was regarded as a dirty hack, the initramfs boot scripts mount the real root in /root, delete all files in the tmpfs root, then chroot into /root, and exec /sbin/init.






      share|improve this answer


















      • 1




        After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
        – jiggunjer
        Jan 17 '17 at 3:54










      • @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
        – psusi
        Jan 18 '17 at 13:43










      • I learned something new about every iteration of root fs that you mentioned. Great answer!
        – jpaugh
        Sep 2 '17 at 1:04












      up vote
      37
      down vote










      up vote
      37
      down vote









      In ancient times, the kernel was hard coded to know the device major/minor number of the root fs and mounted that device after initializing all device drivers, which were built into the kernel. The rdev utility could be used to modify the root device number in the kernel image without having to recompile it.



      Eventually boot loaders came along and could pass a command line to the kernel. If the root= argument was passed, that told the kernel where the root fs was instead of the built in value. The drivers needed to access that still had to be built into the kernel. While the argument looks like a normal device node in the /dev directory, there obviously is no /dev directory before the root fs is mounted, so the kernel can not look up a dev node there. Instead, certain well known device names are hard coded into the kernel so the string can be translated to the device number. Because of this, the kernel can recognize things like /dev/sda1, but not more exotic things like /dev/mapper/vg0-root or a volume UUID.



      Later, the initrd came into the picture. Along with the kernel, the boot loader would load the initrd image, which was some kind of compressed filesystem image (gzipped ext2 image, gzipped romfs image, squashfs finally became dominant). The kernel would decompress this image into a ramdisk and mount the ramdisk as the root fs. This image contained some additional drivers and boot scripts instead of a real init. These boot scripts performed various tasks to recognize hardware, activate things like raid arrays and LVM, detect UUIDs, and parse the kernel command line to find the real root, which could now be specified by UUID, volume label and other advanced things. It then mounted the real root fs in /initrd, then executed the pivot_root system call to have the kernel swap / and /initrd, then exec /sbin/init on the real root, which would then unmount /initrd and free the ramdisk.



      Finally, today we have the initramfs. This is similar to the initrd, but instead of being a compressed filesystem image that is loaded into a ramdisk, it is a compressed cpio archive. A tmpfs is mounted as the root, and the archive is extracted there. Instead of using pivot_root, which was regarded as a dirty hack, the initramfs boot scripts mount the real root in /root, delete all files in the tmpfs root, then chroot into /root, and exec /sbin/init.






      share|improve this answer














      In ancient times, the kernel was hard coded to know the device major/minor number of the root fs and mounted that device after initializing all device drivers, which were built into the kernel. The rdev utility could be used to modify the root device number in the kernel image without having to recompile it.



      Eventually boot loaders came along and could pass a command line to the kernel. If the root= argument was passed, that told the kernel where the root fs was instead of the built in value. The drivers needed to access that still had to be built into the kernel. While the argument looks like a normal device node in the /dev directory, there obviously is no /dev directory before the root fs is mounted, so the kernel can not look up a dev node there. Instead, certain well known device names are hard coded into the kernel so the string can be translated to the device number. Because of this, the kernel can recognize things like /dev/sda1, but not more exotic things like /dev/mapper/vg0-root or a volume UUID.



      Later, the initrd came into the picture. Along with the kernel, the boot loader would load the initrd image, which was some kind of compressed filesystem image (gzipped ext2 image, gzipped romfs image, squashfs finally became dominant). The kernel would decompress this image into a ramdisk and mount the ramdisk as the root fs. This image contained some additional drivers and boot scripts instead of a real init. These boot scripts performed various tasks to recognize hardware, activate things like raid arrays and LVM, detect UUIDs, and parse the kernel command line to find the real root, which could now be specified by UUID, volume label and other advanced things. It then mounted the real root fs in /initrd, then executed the pivot_root system call to have the kernel swap / and /initrd, then exec /sbin/init on the real root, which would then unmount /initrd and free the ramdisk.



      Finally, today we have the initramfs. This is similar to the initrd, but instead of being a compressed filesystem image that is loaded into a ramdisk, it is a compressed cpio archive. A tmpfs is mounted as the root, and the archive is extracted there. Instead of using pivot_root, which was regarded as a dirty hack, the initramfs boot scripts mount the real root in /root, delete all files in the tmpfs root, then chroot into /root, and exec /sbin/init.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 23 '17 at 10:06









      Benoit Duffez

      236211




      236211










      answered Aug 4 '11 at 14:58









      psusi

      13.4k22439




      13.4k22439







      • 1




        After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
        – jiggunjer
        Jan 17 '17 at 3:54










      • @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
        – psusi
        Jan 18 '17 at 13:43










      • I learned something new about every iteration of root fs that you mentioned. Great answer!
        – jpaugh
        Sep 2 '17 at 1:04












      • 1




        After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
        – jiggunjer
        Jan 17 '17 at 3:54










      • @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
        – psusi
        Jan 18 '17 at 13:43










      • I learned something new about every iteration of root fs that you mentioned. Great answer!
        – jpaugh
        Sep 2 '17 at 1:04







      1




      1




      After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
      – jiggunjer
      Jan 17 '17 at 3:54




      After the chroot, is the tmpfs automatically unmounted? Does it just disappear?
      – jiggunjer
      Jan 17 '17 at 3:54












      @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
      – psusi
      Jan 18 '17 at 13:43




      @jiggunjer, no, it is still there, it is just empty ( aside from containing the /root directory ), and no longer used.
      – psusi
      Jan 18 '17 at 13:43












      I learned something new about every iteration of root fs that you mentioned. Great answer!
      – jpaugh
      Sep 2 '17 at 1:04




      I learned something new about every iteration of root fs that you mentioned. Great answer!
      – jpaugh
      Sep 2 '17 at 1:04










      up vote
      3
      down vote













      Sounds like you're asking how does the kernel "know" which partition is the root partition, without access to configuration files on /etc.



      The kernel can accept command line arguments like any other program. GRUB, or most other bootloaders can accept command line arguments as user input, or store them and make various combinations of command line arguments available via a menu. The bootloader passes the command line arguments to the kernel when it loads it (I don't know the name or mechanics of this convention but it's probably similar to how an application receives command line arguments from a calling process in a running kernel).



      One of those command line options is root, where you can specify the root filesystem, i.e. root=/dev/sda1.



      If the kernel uses an initrd, the bootloader is responsible for telling the kernel where it is, or putting the initrd in a standard memory location (I think) - that's at least the way it works on my Guruplug.



      It's entirely possible to not specify one and then have your kernel panic immediately after starting complaining that it can't find a root filesystem.



      There might be other ways of passing this option to the kernel.






      share|improve this answer
















      • 3




        This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
        – Gilles
        Mar 23 '11 at 20:44










      • @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
        – jiggunjer
        Jan 17 '17 at 4:00






      • 1




        @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
        – Gilles
        Jan 17 '17 at 13:41














      up vote
      3
      down vote













      Sounds like you're asking how does the kernel "know" which partition is the root partition, without access to configuration files on /etc.



      The kernel can accept command line arguments like any other program. GRUB, or most other bootloaders can accept command line arguments as user input, or store them and make various combinations of command line arguments available via a menu. The bootloader passes the command line arguments to the kernel when it loads it (I don't know the name or mechanics of this convention but it's probably similar to how an application receives command line arguments from a calling process in a running kernel).



      One of those command line options is root, where you can specify the root filesystem, i.e. root=/dev/sda1.



      If the kernel uses an initrd, the bootloader is responsible for telling the kernel where it is, or putting the initrd in a standard memory location (I think) - that's at least the way it works on my Guruplug.



      It's entirely possible to not specify one and then have your kernel panic immediately after starting complaining that it can't find a root filesystem.



      There might be other ways of passing this option to the kernel.






      share|improve this answer
















      • 3




        This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
        – Gilles
        Mar 23 '11 at 20:44










      • @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
        – jiggunjer
        Jan 17 '17 at 4:00






      • 1




        @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
        – Gilles
        Jan 17 '17 at 13:41












      up vote
      3
      down vote










      up vote
      3
      down vote









      Sounds like you're asking how does the kernel "know" which partition is the root partition, without access to configuration files on /etc.



      The kernel can accept command line arguments like any other program. GRUB, or most other bootloaders can accept command line arguments as user input, or store them and make various combinations of command line arguments available via a menu. The bootloader passes the command line arguments to the kernel when it loads it (I don't know the name or mechanics of this convention but it's probably similar to how an application receives command line arguments from a calling process in a running kernel).



      One of those command line options is root, where you can specify the root filesystem, i.e. root=/dev/sda1.



      If the kernel uses an initrd, the bootloader is responsible for telling the kernel where it is, or putting the initrd in a standard memory location (I think) - that's at least the way it works on my Guruplug.



      It's entirely possible to not specify one and then have your kernel panic immediately after starting complaining that it can't find a root filesystem.



      There might be other ways of passing this option to the kernel.






      share|improve this answer












      Sounds like you're asking how does the kernel "know" which partition is the root partition, without access to configuration files on /etc.



      The kernel can accept command line arguments like any other program. GRUB, or most other bootloaders can accept command line arguments as user input, or store them and make various combinations of command line arguments available via a menu. The bootloader passes the command line arguments to the kernel when it loads it (I don't know the name or mechanics of this convention but it's probably similar to how an application receives command line arguments from a calling process in a running kernel).



      One of those command line options is root, where you can specify the root filesystem, i.e. root=/dev/sda1.



      If the kernel uses an initrd, the bootloader is responsible for telling the kernel where it is, or putting the initrd in a standard memory location (I think) - that's at least the way it works on my Guruplug.



      It's entirely possible to not specify one and then have your kernel panic immediately after starting complaining that it can't find a root filesystem.



      There might be other ways of passing this option to the kernel.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Mar 23 '11 at 15:19









      LawrenceC

      8,41222240




      8,41222240







      • 3




        This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
        – Gilles
        Mar 23 '11 at 20:44










      • @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
        – jiggunjer
        Jan 17 '17 at 4:00






      • 1




        @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
        – Gilles
        Jan 17 '17 at 13:41












      • 3




        This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
        – Gilles
        Mar 23 '11 at 20:44










      • @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
        – jiggunjer
        Jan 17 '17 at 4:00






      • 1




        @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
        – Gilles
        Jan 17 '17 at 13:41







      3




      3




      This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
      – Gilles
      Mar 23 '11 at 20:44




      This is the right explanation when there's no initrd/initramfs, but it's missing a piece of the puzzle. Normally the kernel identifies a device such as /dev/sda1 because it's an entry in a filesystem. You could do cp -p /dev/sda1 /tmp/foo and /tmp/foo would represent the same device. On the kernel command line, the kernel uses a built-in parser that follows the usual device naming convention: sda1 means the first partition of the first SCSI-like disk.
      – Gilles
      Mar 23 '11 at 20:44












      @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
      – jiggunjer
      Jan 17 '17 at 4:00




      @Gilles so modern kernels still can't handle mounting a volume based on UUID? without initrd or initramfs I mean. It has to be a "simple" partition in the /dev/sdx form?
      – jiggunjer
      Jan 17 '17 at 4:00




      1




      1




      @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
      – Gilles
      Jan 17 '17 at 13:41




      @jiggunjer Modern kernels do support searching for a volume by UUID. See init/do_mounts.c.
      – Gilles
      Jan 17 '17 at 13:41










      up vote
      1
      down vote













      Grub mounts the /boot partition and then executes the kernel. In Grub's configuration, it tells the kernel what to use as the root device.



      For example in Grub's menu.lst:



      kernel /boot/linux root=/dev/sda2





      share|improve this answer
























        up vote
        1
        down vote













        Grub mounts the /boot partition and then executes the kernel. In Grub's configuration, it tells the kernel what to use as the root device.



        For example in Grub's menu.lst:



        kernel /boot/linux root=/dev/sda2





        share|improve this answer






















          up vote
          1
          down vote










          up vote
          1
          down vote









          Grub mounts the /boot partition and then executes the kernel. In Grub's configuration, it tells the kernel what to use as the root device.



          For example in Grub's menu.lst:



          kernel /boot/linux root=/dev/sda2





          share|improve this answer












          Grub mounts the /boot partition and then executes the kernel. In Grub's configuration, it tells the kernel what to use as the root device.



          For example in Grub's menu.lst:



          kernel /boot/linux root=/dev/sda2






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 23 '11 at 12:29









          jonescb

          1,60811120




          1,60811120




















              up vote
              1
              down vote













              C'mon, GRUB doesn't "mount" /boot, it just reads 'menu.lst' and some modules, it isn't part of LINUX kernel either. When you call the kernel, you will pass a "root" argument with the root partition. At worst, the kernel knows that just /boot has been mounted (LOL).



              Next: geekosaur is right, Linux uses an initial ramdisk in compressed image format, and then mounts the real root filesystem by calling pivot_root. So Linux starts running from an image, and then from your local disk drive.






              share|improve this answer




















              • Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
                – Shadur
                Mar 23 '11 at 12:55







              • 5




                ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
                – jsbillings
                Mar 23 '11 at 12:58







              • 2




                @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
                – D4RIO
                Mar 23 '11 at 13:02






              • 1




                @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
                – D4RIO
                Mar 23 '11 at 13:10










              • @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
                – Shadur
                Mar 23 '11 at 13:21














              up vote
              1
              down vote













              C'mon, GRUB doesn't "mount" /boot, it just reads 'menu.lst' and some modules, it isn't part of LINUX kernel either. When you call the kernel, you will pass a "root" argument with the root partition. At worst, the kernel knows that just /boot has been mounted (LOL).



              Next: geekosaur is right, Linux uses an initial ramdisk in compressed image format, and then mounts the real root filesystem by calling pivot_root. So Linux starts running from an image, and then from your local disk drive.






              share|improve this answer




















              • Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
                – Shadur
                Mar 23 '11 at 12:55







              • 5




                ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
                – jsbillings
                Mar 23 '11 at 12:58







              • 2




                @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
                – D4RIO
                Mar 23 '11 at 13:02






              • 1




                @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
                – D4RIO
                Mar 23 '11 at 13:10










              • @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
                – Shadur
                Mar 23 '11 at 13:21












              up vote
              1
              down vote










              up vote
              1
              down vote









              C'mon, GRUB doesn't "mount" /boot, it just reads 'menu.lst' and some modules, it isn't part of LINUX kernel either. When you call the kernel, you will pass a "root" argument with the root partition. At worst, the kernel knows that just /boot has been mounted (LOL).



              Next: geekosaur is right, Linux uses an initial ramdisk in compressed image format, and then mounts the real root filesystem by calling pivot_root. So Linux starts running from an image, and then from your local disk drive.






              share|improve this answer












              C'mon, GRUB doesn't "mount" /boot, it just reads 'menu.lst' and some modules, it isn't part of LINUX kernel either. When you call the kernel, you will pass a "root" argument with the root partition. At worst, the kernel knows that just /boot has been mounted (LOL).



              Next: geekosaur is right, Linux uses an initial ramdisk in compressed image format, and then mounts the real root filesystem by calling pivot_root. So Linux starts running from an image, and then from your local disk drive.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Mar 23 '11 at 12:46









              D4RIO

              8771613




              8771613











              • Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
                – Shadur
                Mar 23 '11 at 12:55







              • 5




                ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
                – jsbillings
                Mar 23 '11 at 12:58







              • 2




                @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
                – D4RIO
                Mar 23 '11 at 13:02






              • 1




                @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
                – D4RIO
                Mar 23 '11 at 13:10










              • @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
                – Shadur
                Mar 23 '11 at 13:21
















              • Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
                – Shadur
                Mar 23 '11 at 12:55







              • 5




                ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
                – jsbillings
                Mar 23 '11 at 12:58







              • 2




                @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
                – D4RIO
                Mar 23 '11 at 13:02






              • 1




                @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
                – D4RIO
                Mar 23 '11 at 13:10










              • @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
                – Shadur
                Mar 23 '11 at 13:21















              Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
              – Shadur
              Mar 23 '11 at 12:55





              Grub most definitely does have the ability to 'mount' a filesystem, especially in grub2. Of course, all it's capable of /doing/ with it is look for bootable kernels of one stripe or another, but that's still mounting. Also, linux doesn't require an initrd unless your kernel compiled drivers crucial to your hard drive as modules.
              – Shadur
              Mar 23 '11 at 12:55





              5




              5




              ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
              – jsbillings
              Mar 23 '11 at 12:58





              ibm.com/developerworks/linux/library/l-linuxboot This is a fairly concise summary of what the Linux Kernel does when booting.
              – jsbillings
              Mar 23 '11 at 12:58





              2




              2




              @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
              – D4RIO
              Mar 23 '11 at 13:02




              @Shadur, from the mount manpage: All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These files can be spread out over several devices. The mount command serves to attach the file system found on some device to the big file tree. - Since filesystems used by GRUB aren't attached to the file hierarchy, it's NOT mounting.
              – D4RIO
              Mar 23 '11 at 13:02




              1




              1




              @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
              – D4RIO
              Mar 23 '11 at 13:10




              @Shadur, BTW: It's obvious that initrd isn't necessary since it's just another root filesystem, but it's generally used as small boot-time root, since kernel loads the necessary to boot, then boots, and finally loads everything else.
              – D4RIO
              Mar 23 '11 at 13:10












              @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
              – Shadur
              Mar 23 '11 at 13:21




              @d4rio They're mounted by GRUB, not linux -- it gets easier to comprehend when you regard grub as a microkernel OS of its own rather than just a bootloader.
              – Shadur
              Mar 23 '11 at 13:21










              up vote
              1
              down vote













              The boot loader, be it grub or lilo or whatever, tells the kernel where to look with the root= flag, and optionally loads an initial ramdisk into memory via initrd before booting the kernel.



              The kernel then loads, tests its hardware and device drivers and looks around the system for what it can see (you can review this diagnostic info by typing dmesg; nowadays it likely scrolls by way too fast to see) then attempts to mount the partition mentioned in the root= parameter.



              If an initrd is present, it's mounted first and any modules/device drivers on it are loaded and probed out before the root filesystem is mounted. This way you can compile the drivers for your hard drives as modules and still be able to boot.






              share|improve this answer
























                up vote
                1
                down vote













                The boot loader, be it grub or lilo or whatever, tells the kernel where to look with the root= flag, and optionally loads an initial ramdisk into memory via initrd before booting the kernel.



                The kernel then loads, tests its hardware and device drivers and looks around the system for what it can see (you can review this diagnostic info by typing dmesg; nowadays it likely scrolls by way too fast to see) then attempts to mount the partition mentioned in the root= parameter.



                If an initrd is present, it's mounted first and any modules/device drivers on it are loaded and probed out before the root filesystem is mounted. This way you can compile the drivers for your hard drives as modules and still be able to boot.






                share|improve this answer






















                  up vote
                  1
                  down vote










                  up vote
                  1
                  down vote









                  The boot loader, be it grub or lilo or whatever, tells the kernel where to look with the root= flag, and optionally loads an initial ramdisk into memory via initrd before booting the kernel.



                  The kernel then loads, tests its hardware and device drivers and looks around the system for what it can see (you can review this diagnostic info by typing dmesg; nowadays it likely scrolls by way too fast to see) then attempts to mount the partition mentioned in the root= parameter.



                  If an initrd is present, it's mounted first and any modules/device drivers on it are loaded and probed out before the root filesystem is mounted. This way you can compile the drivers for your hard drives as modules and still be able to boot.






                  share|improve this answer












                  The boot loader, be it grub or lilo or whatever, tells the kernel where to look with the root= flag, and optionally loads an initial ramdisk into memory via initrd before booting the kernel.



                  The kernel then loads, tests its hardware and device drivers and looks around the system for what it can see (you can review this diagnostic info by typing dmesg; nowadays it likely scrolls by way too fast to see) then attempts to mount the partition mentioned in the root= parameter.



                  If an initrd is present, it's mounted first and any modules/device drivers on it are loaded and probed out before the root filesystem is mounted. This way you can compile the drivers for your hard drives as modules and still be able to boot.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 23 '11 at 12:54









                  Shadur

                  19.1k64357




                  19.1k64357



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f9944%2fhow-does-a-kernel-mount-the-root-partition%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown






                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?