Hello,
I want to modify the rootfs so after boot, TX2 will run in text mode only (without x server) .
How can I do it ?
I did not find the file extlinux.conf
Thank you,
Zvika
I think this was not so easily done in R28.x. The more recent R32.x is set up such that if you flash without monitor and keyboard, and complete first boot setup instead with serial console, then this is how the system will be set up.
The systemd setup in R28.x did not necessarily conform the way it should have, and changing default boot from graphical.target to multi-user.target did not work as expected. Some people did this, and got it to work, but I don’t know what steps they took beyond changing default boot to multi-user.target. If you can switch to R32.x, then your life will be simpler. If you cannot switch due to some dependency on the R28.x version of CUDA or other reasons, then someone who has done this can probably give the required steps.
Note: The usual manual method (useful for testing) of switching mode is either of:
- “
sudo systemctl isolate multi-user.target” - Or, “
sudo systemctl isolate graphical.target”
(I doubt multi-user.target will correctly go to text mode, but it should)
Hi linuxdev,
Thank you very much for your reply.
My goal is to block any writing to the disk.
The TX2 can be reset\shutdown with external discrete and I’m afraid this can harm the disk.
I tried to set “ro” in fstab but then the system did not boot because it failed to launch the x server.
Can you tell what is the right way to block any disk writing ?
Writing will be possible only after running: mount -o remount rw /
Best regards,
Zvika
I have never tried this. I can tell you that there are many cases where temp files are required, and the zram and ramdisk in general tends to be popular for mount on “/tmp”, and sometimes parts of “/var”, if there is a desire to not write (any ramdisk is going to be quite fast in comparison to most block storage devices).
I think a lot of people working on this use OverlayFS, but I’m not sure if anyone has yet succeeded with this on a Jetson (most documentation for this is written for a PC, and the boot sequence and software for a Jetson is quite different). It basically involves customizing the initrd, and then wherever a write to the disk occurs, there is a RAM overlay instead. Think of a live DVD style distribution where it isn’t possible to write to the DVD.
Speaking of “/var”, you might need to limit logging, or set this up to instead log to a remote host. If you set up log rotation to be very aggressive, then you could use a ramdisk mounted on “/var/log”.
In terms of what you are afraid of harming, are you speaking of hardware or software harm? Software is always a risk, but hardware can usually be protected.
Btw, although Magic SysRq is not intended for normal operation, it does illustrate what goes on during a forced change to read-only. Perhaps if you looked at the code to this, then it might offer some clues. If I am going to forcibly shut down a system which is otherwise “stuck”, then I tend to do the following:
# Sync:
ALT+SYSRQ+s
# Force read only ("umont" and remount "ro"):
ALT+SYSRQ+u
# Force boot:
ALT+SYSRQ+b
There are also times which this is used with KGDB/KGDBOC for remote kernel debugging. In that case, instead of using those keystrokes, you can instead echo a character to “/proc/sysrq-trigger” on the serial console.
One thing I am thinking of is that the initial ramdisk (initrd) essentially reads the operating system into ram (and has to obviously be a small amount of content), then does a pivot_root into the actual init and hard drive. If you were to modify your initrd to not mount everything in “/”, but to instead mount pieces with read-only where possible, e.g., “/usr” could probably be mounted ro, then you could do a fine grain search for where rw is mandatory and mount everything else ro. In some cases you might be able to change a file being written to to instead be a symbolic link to a writable location. It wouldn’t be easy, but a partial read-only might be simple.
Hi linuxdev,
Your help is highly appreciable.
Best regards,
Zvika