Ubuntu – the purpose of listing the rootfs in /etc/fstab

buildrootfstabroot-filesystemUbuntu

In BuildRoot 2015.08.1 /etc/fstab contains the following line.

/dev/root / ext2 rw,noauto 0 1

On my encrypted Ubuntu laptop /etc/fstab contains the following line.

/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1

Question: What is the purpose of listing the rootfs in /etc/fstab?

Not the answer:

The kernel mounts the rootfs read-only from the root= parameter or in initramfs. So /etc/fstab does not help mounting the rootfs read-only.
The init process remounts the rootfs read-write. This is done in /etc/inittab in BuildRoot, and /etc/rcS.d/S06checkroot.sh in Ubuntu. So /etc/fstab does not help remounting the rootfs read-write.

Background: I am building an embedded system with a fancy initramfs. It looks for different rootfs candidates on the network and locally until it finds a suitable one. It takes care of checking the filesystem and remounting it read-write before calling switch_root.

Bonus question: What would be the impact of not listing the rootfs in /etc/fstab?

It would be awesome if there was none. I don't want to maintain a different /etc/fstab for each rootfs. But then why would BuildRoot and Ubuntu keep it?

Spoiler: I tried and it seems to work, but I am wary of hidden consequences.

Best Answer

The options in fstab are supposed to be used to remount it, applying the options specified ( which may NOT include rw access ). A boot script that is hard coded to remount the root fs with rw without consulting fstab is broken. Thus, the only result of leaving it out of fstab is that it won't be remounted, and will remain ro with no other options applied.

Related Solutions

Ubuntu – /etc/fstab is mounting rw filesystem as read-only

Try to use UUID instead of using device name. Because the name of this device (/dev/sda3) depends on the order in which it was detected while booting, and this order can change. Type this command "blkid" without quote, the shell will display all the devices with UUID. Refer below:

[admin@localhost ~]$ blkid
/dev/sda2: UUID="2fc45c8c-7420-48af-8ad5-06cfeda8633b" TYPE="ext4" 
/dev/sda1: UUID="9a070d16-c6be-40a2-8f38-2e52b8010ef2" TYPE="ext4" 
/dev/sda3: UUID="212c65ba-f4bf-4840-8bcc-bb83c5fe63e6" TYPE="swap" 
/dev/sdb1: LABEL="USBtest" UUID="5f42b5d0-375d-4802-8c58-bd6c9c62481b" TYPE="ext4" 
[admin@localhost ~]$

Above is an example. Copy your device UUID, then replace with /dev/sda3. Then reboot your server. Hope this can solve your problem. Thank you.

Ubuntu – ext4 filesystems frequently corrupting

All three data journaling modes should leave the filesystem itself fully intact after a power failure. So it should always mount without errors. The difference is only in the data in your files; data=writeback mode may leave stale data (i.e., what was stored in the disk sectors before the writes your app did). data=ordered and data=journaled should not do this.

Most likely what you're seeing is that I/O barriers aren't working on your setup. First, make sure you're not mounting with barrier=0/nobarrier. That boosts performance, but will cause corruption on power failure.

If I/O barriers are on, it's also possible you're passing through a storage layer that doesn't support them. On older releases, LVM didn't and various mdraid levels didn't. (This was fixed in Linux 2.6.33; so only if you're running Lucid still.)

Finally, it's possible your disks are telling lies. Disks have write caches. Especially with NCQ, they're supposed to only tell the OS they've written data when they've actually done so, but they've been known to tell the OS its written when its only in the disk's write cache. Increases performance. At least as long as the power stays on. You can try disabling the write cache on the disks, though you'll take a performance hit for this.

Note also that flash-memory disks have a lot of work to do under the hood, and many of them don't handle power failure well. (For example, wear leveling sometimes requires that a full flash block of data be moved. If the power fails in the middle, bad things happen on some flash disks.)

Finally... have you considered an UPS?

Related Question

Linux – Unable to mount drive as read-write