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

Solution 1:

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.

Solution 2:

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.