Is `/etc/fstab` used to remount drives?












9















I have a device installed with Ubuntu 14.04.5 which has a single hard drive with an ext4 file system.



By reading the document Ext4 Filesystem I learned that the default data mode is ordered which only protects the metadata. In my project, we want to change it to journal to also protect file data because the data safety is of higher value.



The first thing I tried was to modify the /etc/fstab file. I tried to change



UUID=<UUID> / ext4 errors=remount-ro 0 1


to



UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1


by appending data=journal to the option field.



However, when I reboot the device, I ended up with an error message saying cannot change data mode on remount. I checked the dmesg and saw an earlier message about mounting the drive with ordered data mode.



For an embarrassingly long time, I thought /etc/fstab is used to override the default mounting options so the drives are only mounted once. But now it looks wrong: the drive is mounted using its default mount options, then /etc/fstab is picked up to remount it.



My questions are:





  • Is this "mount-remout" process the design of the system? I read the Fstab wiki page but didn't see it mentions the "mount-remount" thing.

  • If /etc/fstab is truly used for remounting, in which step of the booting process is the drive mounted for the first time? Is it implemented in /etc/init.d? I did see some scripts in /etc/init.d called umountfs and umountroot, but, skimming their content, they don't look relevant.










share|improve this question




















  • 2





    I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

    – steeldriver
    Jan 9 at 15:48
















9















I have a device installed with Ubuntu 14.04.5 which has a single hard drive with an ext4 file system.



By reading the document Ext4 Filesystem I learned that the default data mode is ordered which only protects the metadata. In my project, we want to change it to journal to also protect file data because the data safety is of higher value.



The first thing I tried was to modify the /etc/fstab file. I tried to change



UUID=<UUID> / ext4 errors=remount-ro 0 1


to



UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1


by appending data=journal to the option field.



However, when I reboot the device, I ended up with an error message saying cannot change data mode on remount. I checked the dmesg and saw an earlier message about mounting the drive with ordered data mode.



For an embarrassingly long time, I thought /etc/fstab is used to override the default mounting options so the drives are only mounted once. But now it looks wrong: the drive is mounted using its default mount options, then /etc/fstab is picked up to remount it.



My questions are:





  • Is this "mount-remout" process the design of the system? I read the Fstab wiki page but didn't see it mentions the "mount-remount" thing.

  • If /etc/fstab is truly used for remounting, in which step of the booting process is the drive mounted for the first time? Is it implemented in /etc/init.d? I did see some scripts in /etc/init.d called umountfs and umountroot, but, skimming their content, they don't look relevant.










share|improve this question




















  • 2





    I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

    – steeldriver
    Jan 9 at 15:48














9












9








9


2






I have a device installed with Ubuntu 14.04.5 which has a single hard drive with an ext4 file system.



By reading the document Ext4 Filesystem I learned that the default data mode is ordered which only protects the metadata. In my project, we want to change it to journal to also protect file data because the data safety is of higher value.



The first thing I tried was to modify the /etc/fstab file. I tried to change



UUID=<UUID> / ext4 errors=remount-ro 0 1


to



UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1


by appending data=journal to the option field.



However, when I reboot the device, I ended up with an error message saying cannot change data mode on remount. I checked the dmesg and saw an earlier message about mounting the drive with ordered data mode.



For an embarrassingly long time, I thought /etc/fstab is used to override the default mounting options so the drives are only mounted once. But now it looks wrong: the drive is mounted using its default mount options, then /etc/fstab is picked up to remount it.



My questions are:





  • Is this "mount-remout" process the design of the system? I read the Fstab wiki page but didn't see it mentions the "mount-remount" thing.

  • If /etc/fstab is truly used for remounting, in which step of the booting process is the drive mounted for the first time? Is it implemented in /etc/init.d? I did see some scripts in /etc/init.d called umountfs and umountroot, but, skimming their content, they don't look relevant.










share|improve this question
















I have a device installed with Ubuntu 14.04.5 which has a single hard drive with an ext4 file system.



By reading the document Ext4 Filesystem I learned that the default data mode is ordered which only protects the metadata. In my project, we want to change it to journal to also protect file data because the data safety is of higher value.



The first thing I tried was to modify the /etc/fstab file. I tried to change



UUID=<UUID> / ext4 errors=remount-ro 0 1


to



UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1


by appending data=journal to the option field.



However, when I reboot the device, I ended up with an error message saying cannot change data mode on remount. I checked the dmesg and saw an earlier message about mounting the drive with ordered data mode.



For an embarrassingly long time, I thought /etc/fstab is used to override the default mounting options so the drives are only mounted once. But now it looks wrong: the drive is mounted using its default mount options, then /etc/fstab is picked up to remount it.



My questions are:





  • Is this "mount-remout" process the design of the system? I read the Fstab wiki page but didn't see it mentions the "mount-remount" thing.

  • If /etc/fstab is truly used for remounting, in which step of the booting process is the drive mounted for the first time? Is it implemented in /etc/init.d? I did see some scripts in /etc/init.d called umountfs and umountroot, but, skimming their content, they don't look relevant.







boot partitioning mount hard-drive fstab






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 19 at 9:19









Zanna

50.6k13134241




50.6k13134241










asked Jan 9 at 15:21









yaobinyaobin

1787




1787








  • 2





    I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

    – steeldriver
    Jan 9 at 15:48














  • 2





    I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

    – steeldriver
    Jan 9 at 15:48








2




2





I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

– steeldriver
Jan 9 at 15:48





I think it's the "chicken and egg" problem mentioned here (/etc/fstab resides on the root filesystem, but it can't be read until after the filesytem has been mounted): Does initramfs use /etc/fstab?

– steeldriver
Jan 9 at 15:48










2 Answers
2






active

oldest

votes


















8














From man ext4:



data={journal|ordered|writeback}
Specifies the journaling mode for file data. Metadata is always
journaled. To use modes other than ordered on the root filesys‐
tem, pass the mode to the kernel as boot parameter, e.g. root‐
flags=data=journal.


Remove data=ordered from your fstab-line and edit /etc/default/grub instead.
In /etc/default/grub change the line



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


to



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"


run sudo update-grub and reboot.






share|improve this answer































    5














    When /etc/fstab is used



    If you run sudo strace -e open,openat mount -o remount,rw / you will see that the command does in fact open /etc/fstab. This is the most common command you will see, often referenced in articles on working from recovery shell.



    To also quote sourcejedi's answer (which comes from mount(8) manual):




    mount -o remount,rw /dir



    After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.




    However, that doesn't mean that /etc/fstab is always used. In particular, when you also specify the device file; reference to the mount(8) manual:




    The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.



    mount -o remount,rw /dev/foo /dir



    After this call all old mount options are replaced and arbitrary
    stuff from fstab is ignored
    , except the loop= option which is
    internally generated and maintained by the mount command.




    This makes sense, since /dir could be arbitrary - remounting a device to different mountpoint.



    The /etc/fstab is also not referenced when mounting / filesystem at boot time kernel knows nothing of /etc/fstab. To quote psusi's answer:




    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



    ...



    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




    Filesystems which don't need fstab



    Note also, that Linux kernel has other filesystems which reside in memory - these are not available to users normally, some of which do not have a mountpoint at all, while some are exposed to the users. Kernel doesn't have to reference /etc/fstab for those. Example of that is /proc - it's a virtual filesystem that exposes mostly information about processes, and some stuff about hardware and system that should really be in /sys - another virtual filesystem.






    share|improve this answer

























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      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',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      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%2faskubuntu.com%2fquestions%2f1108320%2fis-etc-fstab-used-to-remount-drives%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      8














      From man ext4:



      data={journal|ordered|writeback}
      Specifies the journaling mode for file data. Metadata is always
      journaled. To use modes other than ordered on the root filesys‐
      tem, pass the mode to the kernel as boot parameter, e.g. root‐
      flags=data=journal.


      Remove data=ordered from your fstab-line and edit /etc/default/grub instead.
      In /etc/default/grub change the line



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


      to



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"


      run sudo update-grub and reboot.






      share|improve this answer




























        8














        From man ext4:



        data={journal|ordered|writeback}
        Specifies the journaling mode for file data. Metadata is always
        journaled. To use modes other than ordered on the root filesys‐
        tem, pass the mode to the kernel as boot parameter, e.g. root‐
        flags=data=journal.


        Remove data=ordered from your fstab-line and edit /etc/default/grub instead.
        In /etc/default/grub change the line



        GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


        to



        GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"


        run sudo update-grub and reboot.






        share|improve this answer


























          8












          8








          8







          From man ext4:



          data={journal|ordered|writeback}
          Specifies the journaling mode for file data. Metadata is always
          journaled. To use modes other than ordered on the root filesys‐
          tem, pass the mode to the kernel as boot parameter, e.g. root‐
          flags=data=journal.


          Remove data=ordered from your fstab-line and edit /etc/default/grub instead.
          In /etc/default/grub change the line



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


          to



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"


          run sudo update-grub and reboot.






          share|improve this answer













          From man ext4:



          data={journal|ordered|writeback}
          Specifies the journaling mode for file data. Metadata is always
          journaled. To use modes other than ordered on the root filesys‐
          tem, pass the mode to the kernel as boot parameter, e.g. root‐
          flags=data=journal.


          Remove data=ordered from your fstab-line and edit /etc/default/grub instead.
          In /etc/default/grub change the line



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


          to



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"


          run sudo update-grub and reboot.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 9 at 15:57









          mook765mook765

          3,96421330




          3,96421330

























              5














              When /etc/fstab is used



              If you run sudo strace -e open,openat mount -o remount,rw / you will see that the command does in fact open /etc/fstab. This is the most common command you will see, often referenced in articles on working from recovery shell.



              To also quote sourcejedi's answer (which comes from mount(8) manual):




              mount -o remount,rw /dir



              After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.




              However, that doesn't mean that /etc/fstab is always used. In particular, when you also specify the device file; reference to the mount(8) manual:




              The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.



              mount -o remount,rw /dev/foo /dir



              After this call all old mount options are replaced and arbitrary
              stuff from fstab is ignored
              , except the loop= option which is
              internally generated and maintained by the mount command.




              This makes sense, since /dir could be arbitrary - remounting a device to different mountpoint.



              The /etc/fstab is also not referenced when mounting / filesystem at boot time kernel knows nothing of /etc/fstab. To quote psusi's answer:




              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



              ...



              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




              Filesystems which don't need fstab



              Note also, that Linux kernel has other filesystems which reside in memory - these are not available to users normally, some of which do not have a mountpoint at all, while some are exposed to the users. Kernel doesn't have to reference /etc/fstab for those. Example of that is /proc - it's a virtual filesystem that exposes mostly information about processes, and some stuff about hardware and system that should really be in /sys - another virtual filesystem.






              share|improve this answer






























                5














                When /etc/fstab is used



                If you run sudo strace -e open,openat mount -o remount,rw / you will see that the command does in fact open /etc/fstab. This is the most common command you will see, often referenced in articles on working from recovery shell.



                To also quote sourcejedi's answer (which comes from mount(8) manual):




                mount -o remount,rw /dir



                After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.




                However, that doesn't mean that /etc/fstab is always used. In particular, when you also specify the device file; reference to the mount(8) manual:




                The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.



                mount -o remount,rw /dev/foo /dir



                After this call all old mount options are replaced and arbitrary
                stuff from fstab is ignored
                , except the loop= option which is
                internally generated and maintained by the mount command.




                This makes sense, since /dir could be arbitrary - remounting a device to different mountpoint.



                The /etc/fstab is also not referenced when mounting / filesystem at boot time kernel knows nothing of /etc/fstab. To quote psusi's answer:




                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



                ...



                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




                Filesystems which don't need fstab



                Note also, that Linux kernel has other filesystems which reside in memory - these are not available to users normally, some of which do not have a mountpoint at all, while some are exposed to the users. Kernel doesn't have to reference /etc/fstab for those. Example of that is /proc - it's a virtual filesystem that exposes mostly information about processes, and some stuff about hardware and system that should really be in /sys - another virtual filesystem.






                share|improve this answer




























                  5












                  5








                  5







                  When /etc/fstab is used



                  If you run sudo strace -e open,openat mount -o remount,rw / you will see that the command does in fact open /etc/fstab. This is the most common command you will see, often referenced in articles on working from recovery shell.



                  To also quote sourcejedi's answer (which comes from mount(8) manual):




                  mount -o remount,rw /dir



                  After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.




                  However, that doesn't mean that /etc/fstab is always used. In particular, when you also specify the device file; reference to the mount(8) manual:




                  The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.



                  mount -o remount,rw /dev/foo /dir



                  After this call all old mount options are replaced and arbitrary
                  stuff from fstab is ignored
                  , except the loop= option which is
                  internally generated and maintained by the mount command.




                  This makes sense, since /dir could be arbitrary - remounting a device to different mountpoint.



                  The /etc/fstab is also not referenced when mounting / filesystem at boot time kernel knows nothing of /etc/fstab. To quote psusi's answer:




                  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



                  ...



                  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




                  Filesystems which don't need fstab



                  Note also, that Linux kernel has other filesystems which reside in memory - these are not available to users normally, some of which do not have a mountpoint at all, while some are exposed to the users. Kernel doesn't have to reference /etc/fstab for those. Example of that is /proc - it's a virtual filesystem that exposes mostly information about processes, and some stuff about hardware and system that should really be in /sys - another virtual filesystem.






                  share|improve this answer















                  When /etc/fstab is used



                  If you run sudo strace -e open,openat mount -o remount,rw / you will see that the command does in fact open /etc/fstab. This is the most common command you will see, often referenced in articles on working from recovery shell.



                  To also quote sourcejedi's answer (which comes from mount(8) manual):




                  mount -o remount,rw /dir



                  After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.




                  However, that doesn't mean that /etc/fstab is always used. In particular, when you also specify the device file; reference to the mount(8) manual:




                  The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.



                  mount -o remount,rw /dev/foo /dir



                  After this call all old mount options are replaced and arbitrary
                  stuff from fstab is ignored
                  , except the loop= option which is
                  internally generated and maintained by the mount command.




                  This makes sense, since /dir could be arbitrary - remounting a device to different mountpoint.



                  The /etc/fstab is also not referenced when mounting / filesystem at boot time kernel knows nothing of /etc/fstab. To quote psusi's answer:




                  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



                  ...



                  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




                  Filesystems which don't need fstab



                  Note also, that Linux kernel has other filesystems which reside in memory - these are not available to users normally, some of which do not have a mountpoint at all, while some are exposed to the users. Kernel doesn't have to reference /etc/fstab for those. Example of that is /proc - it's a virtual filesystem that exposes mostly information about processes, and some stuff about hardware and system that should really be in /sys - another virtual filesystem.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 9 at 17:26

























                  answered Jan 9 at 15:54









                  Sergiy KolodyazhnyySergiy Kolodyazhnyy

                  71.4k9147313




                  71.4k9147313






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108320%2fis-etc-fstab-used-to-remount-drives%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

                      數位音樂下載

                      When can things happen in Etherscan, such as the picture below?

                      格利澤436b