L4T R21.7 - read-only rootfs issue

Hi all,
i’m on a TK1 with L4T R21.7
i need to mount rootfs in read-only mode (for production purposes)
but if i set the right kernel bootargs the system stucks completely at boot time (upstart procedure)
without any error message.

The strange thing is that this issue happened automatically a few days ago, probably some errors on the filesystem made sure that it was automatically mounted in read-only mode on reboot, and the system was unusable (I checked settings in fstab and in the mmc filesystem with tune2fs but there is no trace of the errors = remount-ro)

Any suggestion for the right support of read-only mode rootfs?

FYI, it seems that the “/etc/init/nv.conf” script will show as “failed” when mounting read-only (but it isn’t an issue). Regarding the reason for this script thinking believing it has failed is an attempt to work around a known package bug; one of the files which can sometimes be overwritten by a regular package update is:


…and the last act of nv.conf is to attempt to fix this through a forced sym link write (this is the reason for a fail note about this script when mounting read-only):

ln -sf ${LIB_DIR}/libglx.so /usr/lib/xorg/modules/extensions/libglx.so

I commented this line out as a test and it makes no difference (normally this wouldn’t matter anyway unless you’ve just had a rare package update issue…and even then it only matters for the GUI). However, while testing, it is suggested to comment this line out anyway.

When I change the kernel command line argument “rw” to instead be “ro” the system notes this prior to halting in failure:

The disk drive for / is not ready yet or not present.

Unfortunately it seems the serial console is not able to enter keys required to continue via this message:

The disk drive for / is not ready yet or not present.
keys:Continue to wait, or Press S to skip mounting or M for manual recovery

I directly attached a keyboard and could hit “M” for manual recovery. The list of mounts shows rootfs is rw instead of ro, but this is probably due to being in recovery mode (which also is a reason why only one console works).

If instead of “M” for manual recovery I enter “S” to skip mount, then things work. Although the file system acts as if it is read-only “/etc/mtab” and the “mount” commands disagree and think it is read-write.

I can’t say if this is actually a bug, or if instead setup requiring read-write makes this configuration invalid. My guess is that you’d need to come up with an init configuration which has no requirement for write, e.g., puts any locks or other writes on a different partition (think SD card or SATA drive or even a new partition in eMMC). If this were a live DVD distribution, then it would have some sort of overlay filesystem so the eMMC (or base media) is read-only, but would have the appearance of writeability for lock files and temp files.

My question is this: How are you attempting to make this read-only? Is it via the “rw” edit to become “ro” in extlinux.conf? Have you tested to see if this is possible with a standard desktop Ubuntu 14.04 distribution?

I’m trying to make rootfs read-only passing the right kernel bootargs from u-boot (roots is in emmc onboard):

root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

I’m working on a console-only version of the system, I need only a system that can run my opencv4tegra application at startup thus i’m trying to disable all unneeded services such as desktop environment(lightdm), bluetooth, alsa, and more…

I need a read-only rootfs in order to prevent all possible file system issues due to power loss.
(in this case i mountneeded write resources on a secondary device, like SD)

What is the right way to make Linux4Tegra rootfs read-only?
What is your “hint”?

I am currently using R21.6 as a reference (I have not yet flashed R21.7). I suspect the default extlinux.conf is no different since R21.7 is a maintenance release.

There is a lot going on in this default command line (posting as a reference):

APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid= debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

Can I verify that what you are showing is a subset of the “APPEND” and not the complete argument?

I’m not sure if using “mmcblk0p2” (not the default partition) would have any effect or not. I am assuming you’ve test booted and had no issue with “rw”, but FYI, there may be subtle cases where a partition scheme change gets more complicated than it would first appear.

I have not been able to provide any “simple” read-only adjustment. What I will suggest (I don’t have your system setup so I can’t reproduce it) is that you post any console message (including a few lines prior to halting) and show what you get. Do you get the prompt for asking if you want to skip or fix the issue? Then work on reconfiguring anything “temporary” in nature to use an SD card for its mount instead of rootfs (this is not necessarily a final configuration…this is for debugging). An example is to create a partition of sufficient size on an SD card, and use fstab to mount that to “/tmp/”. On the same SD card make another partition to mount at “/var/lock/” (and yet another partition for “/var/log/”). See if anything changes or improves or gets further along with the “ro” rootfs.

On a desktop PC you might see something like the following in fstab when not trying to use “ro”:

/dev/whatever_for_rootfs   /         ext4   defaults 1 1
/dev/whatever_for_tmp      /tmp      ext4   defaults 1 2
/dev/whatever_for_lock     /var/lock ext4   defaults 1 3
/dev/whatever_for_log      /var/log  ext4   defaults 1 4

The rootfs is a bit different on a Jetson, so you can probably ignore “/” in fstab (even if the partition shows “rw” later you will probably find the kernel “ro” argument causes correct “ro” behavior). You’d still include the other directory mount points. The final columns are basically to suggest fsck order if needed, and on a filesystem which is normally mounted you would make the order “1” for rootfs and then continue in order for other critical partitions (thus “2” then “3” then “4”…this does fsck serially instead of in parallel). If you had partitions which were not normally mounted, but for whatever reason still named, then those final columns would be “0 0” instead of “1 something”.

If you get this booting correctly with an alternate “/tmp”, “/var/lock/” and “/var/log/”, then try “ro” and see if things work or fail. If you have kept a boot log from a working read-write and then compare to a boot log with alternate writable mount point partitions, then you can post the changes you get here and we can look further at how to make that partition itself remain on rootfs and work “ro”.

I solved the issue:

in order to mount rootfs in read-only mode you have to setup the “ro” setting consistently, both in u-boot and in /etc/fstab:


emmcargs=ip = off root = / dev / mmcblk0p2 ro rootfstype = ext4 rootwait


# Copyright (c) 2018, NVIDIA CORPORATION.  All rights reserved.
 # NVIDIA CORPORATION and its licensors retain all intellectual property
 # and proprietary rights in and to this software, related documentation
 # and any modifications thereto.  Any use, reproduction, disclosure or
 # distribution of this software and related documentation without an express
 # license agreement from NVIDIA CORPORATION is strictly prohibited.
 # /etc/fstab: static file system information.
 # These are the filesystems that are always mounted on boot, you can
 # override any of these by copying the appropriate line from this file into
 # /etc/fstab and tweaking it as you see fit.  See fstab(5).
 # <file system> <mount point>             <type>          <options>         <dump> <pass>
 /dev/root            /                    rootfs          ro                     0 1