How to mount a read-only rootfs?

Hi Sir/Madam,

I would like to use overlay rootfs and try to install overlayroot.
After installation, it seems not work.
Does anyone has experience?

One more thing, I try to mount read only root file system by modifying rw->ro in flash.sh.
cmdline is ro indeed but the root file system is still to be mounted rw.

cat /proc/cmdline 
root=/dev/mmcblk0p1 ro rootwait console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x800000@0xa0791000 lut_mem=0x2008@0xa078e000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 vpr=0x8000000@0xf0000000 sdhci_tegra.en_boot_part_access=1
/dev/mmcblk0p1 on / type ext4 (rw,relatime,data=ordered)

How to mount a read-only rootfs?

Thank you

I’m thinking that if you were able to do this with an initrd it could be made to work. However, Xavier doesn’t use U-Boot, and I’m uncertain what the procedure is for an initrd update using CBoot, or even if it is possible. That would be the first question for NVIDIA…under the most recent releases, how does one specify a custom initrd with CBoot?

My motivation is want to mount a read-only root file system at “/” and overlay another writable file system.

First I try “apt-get install” “overlayroot” but seems not work on Xavier R32.1. I also tried “mount -t overlay -o …” but I need to mount a read-only file system first to verify this mechanism.

I’m not sure if it is related to initrd. Just guess root file system seems to be mounted by initrd? So even I modify kernel cmdline from “rw” to “ro” in flash.sh, it still doesn’t work?

The boot code prior to running Linux has to understand the initial filesystem. Basically boot code understands (has drivers for) ext4 and initrd. Initrd is more or less a self-contained mini filesystem.

Imagine the case of needing to boot to another filesystem type, e.g., XFS, and XFS isn’t understood by Linux without a kernel module (sure, you could compile it in, but this is for illustration)…then Linux would need the driver in the form of a module, but the module to understand XFS has to be read from XFS. A “chicken and the egg” dilemma.

Boot has a similar issue in handing over to a filesystem type it doesn’t understand. That understanding is required because it needs to load “/boot/Image” into RAM. This is why an initrd is used if Image isn’t on ext4…the filesystem type of initrd will always be a readable ext2/3/4, and then if Linux understands booting to overlayfs due to having all it needs, either integrated with the kernel or as modules, then boot code does not need to have that understanding (at this point Linux is running and understands overlayfs so CBoot does not need to). The initrd in this case adds content which gives the kernel Image whatever it needs to understand overlayfs and do the switch to the new filesystem type instead of making CBoot do this. It’s either an initrd, or writing/porting a driver for CBoot.

An initial ramdisk is just a compressed tar file of a small self-contained root filesystem. Xavier makes this more difficult due to content which now lives in partitions (and is signed) rather than in “/boot”. You’ll have to read more, and I have not yet succeeded at installing a custom initrd, but if you do find an initrd, then you can unpack it and see what is on it like this:

# sudo is because some files might be root permissions.
sudo -s
gunzip < initrd > initrd.cpio
# This unpacks a tree of files, start in an empty directory:
cpio -vid < initrd.cpio
exit

One way of creating an initrd (perhaps after editing an existing initrd):

sudo -s
find . | cpio --quiet -H newc -o | gzip -9 -n > ../initrd_new
exit

More info:
https://devtalk.nvidia.com/default/topic/1011027/jetson-tk1/jetson-tx1-initrd/post/5157554/#5157554

You’ll probably have to post a new topic to find out more about how to sign and install modified initrds on an Xavier.

On my wish list for NVIDIA boot would be adding drivers to CBoot:
USB3, DMA-capable serial ports, ethernet, USB SATA, and eSATA. Some of this already exists in one form or another. Overlayfs wouldn’t be a bad addition as well.

Hi linuxdev,

Thanks a lot for your detailed information.

Just back to overlayroot issue.
I think overlayroot would not be supported by R32.1 but overlayfs would.
Now I use overlayfs to achieve overlay root file system.

Only need to know how to mount a read-only root file system.

Thanks

It leads back to the difficulty of not having U-Boot. Normally you could pass an argument to the kernel at boot to alter the mount. You can still probably do this via the device tree “choosen” node “bootargs”, but I don’t know if it will behave as expected.

If you examine the current kernel boot arguments:

cat /proc/cmdline

…then you get something like this (a subset of the full command line):

root=/dev/mmcblk0p1 rw rootwait

“rootwait” just says wait forever until available, the “rw” argument says read-write. “root=/dev/mmcblk0p1” simply says first partition of eMMC. It is the “rw” which would need to change to “ro”. Changing this would involve editing the device tree and flashing the new tree (which has to be signed so you’d have to pay attention to methods).

What I don’t know is if this will be honored. In part, this once again comes down to whether CBoot (rather than U-Boot) might do something to get in the way. Also there may be an initrd, and that initrd might also need change. Once you get past that, then there could be ordinary sys init scripts which take ro and remount rw. I don’t know what you will run into while adding this, but I think all of it will require being able to work on an initrd.

NOTE: If you want to manually ssh in or log in and trigger read-only try this (useful for manual test of overlay prior to working on init scripts and initrd):

sudo echo r > /proc/sysrq-trigger

To pass “ro” by cmdline doesn’t work. (mentioned at my first post)

BTW, Thank you for your suggestion

I tried “sudo echo r > /proc/sysrq-trigger”, but “Permission denied”
Switching to root to do this command, but seems not any effect.

What do you see from:

sudo cat /proc/sys/kernel/sysrq

If not “1”, then before doing the echo of “r” for read only, do this:

sudo echo 1 > /proc/sys/kernel/sysrq

If this is “1”, then the full sysrq command set (of commands available in this architecture) should be allowed.

Also, be sure as little as possible is running when you echo “r”. Possibly if something locks the disk, e.g., an automatic apt upgrade, then “r” might still be denied (in which case waiting for the upgrade to finish or ending whatever process is accessing disk for write operation would make “r” allowed again).

I found to mount read-only command should be “echo “u” > /proc/sysrq-trigger”.
Thank you for your suggestion.

Is any nvidia AE/FAE can answer how to mount a read-only file system as default.

PS: To modify “rw” to “ro” in cmdline doesn’t work

The “u” should be to umount, “r” should set read-only (umount is complete disk removal). Device tree is likely the way to change cmdline to ro, but there is a catch…any initrd might be setting this back up as read-write even if it starts out ro. I am unsure of current release initrd mechanics.

I have not looked at more recent initrd content, someone from NVIDIA might have information on how to update or edit the initrd for current releases. If you can do that, then you can edit any boot script in the initrd to remain ro and to do any kind of related operation, e.g., overlayfs (you’d need all of the necessary binary executables and kernel modules within the initrd).

This doesn’t work, because the shell you’re running is opening the file with the ‘>’ redirect, and the “sudo” only applies to the “echo 1” command.

The way to do this is either:

sudo -i
echo 1 > /proc/sys/kernel/sysrq

or:

sudo sh -c 'echo 1 > /proc/sys/kernel/sysrq'

The first creates an interactive shell with root privileges that can successfully use ‘>’ to open files; the second runs a non-interactive shell as root with the one command line that opens the file and echoes into it.

The same rules of course apply to ‘/proc/sysrq-trigger’ or any other file that you try to access with shell redirect ‘>’ or ‘<’ operators.

Hi linuxdev,

I think mount overlay folders manually can’t achieve the requirements that I want.
Because when I mount root file system to be ro manually, the system can’t work well. (some services can’t open read-only files even I already mount it as overlay).

It looks like that only overlayroot can satisfy my requirements but it can’t work in Xavier.
I search forum and found some people have the same problems but there is no good results finally.
The initrd image would be the issue? I think TX2 doesn’t use initrd but Xavier seems to use it?
For your previous post about custom initerf, it looks like is another problem…

The echo to the magic sysrq is just for testing drivers. If this can be performed, then it means you should be able to succeed via an initrd (make sure it works manually prior to trying to do this by boot edits). Any existing initrd may also be interfering with the “ro” kernel command line argument. I suspect that you will need to examine any existing initrd in detail to figure out where it is failing. I am uncertain of how Xavier works with initrd since it skips U-Boot and works directly from CBoot. It may be something in CBoot is calling this from a partition or some unexpected location. Even if CBoot does not do this, then you will probably have to find a way to do it yourself.

Anyone with experience in customizing an initrd on Xavier might want to comment on the topic.