Timeline for When can Linux boot with a Read-Only Root Filesystem
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 28, 2018 at 7:03 | comment | added | telcoM | That flag is for determining what to do when the filesystem is already mounted and an error is encountered. It is for when it is important that the system stays up, even if it might output corrupted data as a result. Conversely, if it's absolutely important that the system never outputs corrupted data, you can set errors=panic to make the system crash when it detects a disk error. But when you're mounting a filesystem, the situation is different: if the system crashed and rebooted, the damage is already done and you might as well take the time to recover properly. | |
| Apr 28, 2018 at 4:17 | comment | added | dDebug | Its is a journaled fs (ext3). But as far as I understand the fs superblock has a error flag to let fsck know what to do under a error condition, and if errors=continue, then the remount should be RW irrespective of the error, is it correct that I understand from the man page, also here unix.stackexchange.com/questions/97915/… | |
| Apr 26, 2018 at 21:19 | comment | added | telcoM | Basically, the checking for unsafe unmounting is done for a good reason. If you use a journaling filesystem, the necessary checking after a crash shutdown can be done completely automatically in at least about 99.9% of cases. But trying to routinely skip it and force mounting a filesystem that might be in an inconsistent state is a bad idea. | |
| Apr 26, 2018 at 21:14 | comment | added | telcoM | It depends on the filesystem type used. A filesystem metadata on the disc might record something like a timestamp of last mounting and last unmounting. If mount timestamp > unmount timestamp, the disk was not unmounted safely and would need checking. On journaled filesystems, if at mount time the journal area contains records that are not marked as committed to the actual filesystem, same thing. | |
| Apr 26, 2018 at 10:41 | comment | added | dDebug | The answer is very helpful. The rootfs mount is handled by the kernel and I found systemd-remount-fs.service which probably remount the root fs. But how does the fsck decide that the filesystem has error or improperly powered off? Is there a flag that can be set to reproduce this event and test? One more suggestion I want is, how do I prevent the root fs to remain RO or how do I force remount as RW even if the shutdown was not proper, or there is a fs error flag... | |
| Apr 26, 2018 at 8:11 | vote | accept | dDebug | ||
| Apr 24, 2018 at 12:27 | history | answered | telcoM | CC BY-SA 3.0 |