Is `/etc/fstab` used to remount drives?
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 theFstab
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
calledumountfs
andumountroot
, but, skimming their content, they don't look relevant.
boot partitioning mount hard-drive fstab
add a comment |
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 theFstab
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
calledumountfs
andumountroot
, but, skimming their content, they don't look relevant.
boot partitioning mount hard-drive fstab
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
add a comment |
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 theFstab
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
calledumountfs
andumountroot
, but, skimming their content, they don't look relevant.
boot partitioning mount hard-drive fstab
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 theFstab
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
calledumountfs
andumountroot
, but, skimming their content, they don't look relevant.
boot partitioning mount hard-drive fstab
boot partitioning mount hard-drive fstab
edited Jan 19 at 9:19
Zanna
50.6k13136241
50.6k13136241
asked Jan 9 at 15:21
yaobinyaobin
1837
1837
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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.
add a comment |
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 9 at 15:57
mook765mook765
4,14921332
4,14921332
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Jan 9 at 17:26
answered Jan 9 at 15:54
Sergiy KolodyazhnyySergiy Kolodyazhnyy
72.1k9148314
72.1k9148314
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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