Hi,
I’m using Jetson Tk 1 Dev board kit…
I tried to keep external SDcard as Root FS(File-System) as stated in Tegra Linux Driver Package Development Guide.pdf
"If the root file system will be on an SD card, execute the script as follows:
$ sudo ./flash.sh mmcblk1p1 "
So I used this command for flashing jetson under Recoverory mode
$ sudo ./flash.sh jetson-tk1 mmcblk1p1
But still it is not working..
I think the reason for this should be due to this part of code in flash.sh
if [[ "${target_rootdev}" == mmcblk0p* ]]; then
rootdev_type="internal";
elif [ "${target_rootdev}" = "eth0" -o "${target_rootdev}" = "eth1" ]; the n
rootdev_type="network";
elif [[ "${target_rootdev}" != mmcblk1p* && \
"${target_rootdev}" != sd* ]]; then
echo "Error: Invalid target rootdev($target_rootdev).";
usage rootdevunknown 1;
fi;
Can anyone help me in this issue?
Thank you in advance...
Information that may be of use…you can keep the boot loader on Jetson, flash normally, and then edit “/boot/ext/extlinux.conf” to point at the SD card by editing the “root=/dev/mmcblk0p1”. This keeps the boot loader on the eMMC, but points to another device for rootfs. The existing eMMC is then available as a backup if the SD card is not installed (you can add a second entry to the original eMMC root and select on serial console).
The sample rootfs (including your modifications) can be unpacked directly on your SD card from the host. The “apply_binaries.sh” script can then be run with option “–root ” to apply it to a non-standard location (the SD card mount point on the host). The “/boot” directory which is actually used would remain on the Jetson eMMC, but all else would go to the SD card during boot. I believe if you were to flash with mmcblk1p1 directly you probably would not retain the ability to boot to regular eMMC and the eMMC “/boot” would not be used.
Thank you everyone for your valuable reply..
I have also tried copying to rootfs using the cp command for SD-card.
Eventhough it works, there is an issue in it.
When connected to HDMI display, the screen is always blank.
Then I added privileges to the root by
$ chmod 755 /
Now the display works..
But still I want to know what's the reason behind this lack of privilege for root....
"When connected to HDMI display, the screen is always blank.
Then I added privileges to the root by
$ chmod 755 /
Now the display works…
But still I want to know what’s the reason behind this lack of privilege for root… "
I think it is because lightdm/unity writes some temporary files. If it cannot, then it is unable to display anything.
I have seen this when the MMC is full.
Sorry, should have mentioned this, need to change permissions for the root of the SD (or USB or SSD).
I think it is the way the ‘disk’ was created. Normally, you would start with a blank HDD and incrementally install Linux. In this case the blank HDD root is automatically given root access.
Now in our case, we have mounted a device as a secondary/media device. Linux for safety must default these to 000 permissions or at least that is my guess.
I also believe permissions behavior results in the way the files/permissions are copied. If you use “cp” without the right options, or without root authority for the copy, then some ownership and/or permissions change. What options did you use for cp? You might use sudo with “-adpR” or similar.
Incidentally, with regard to the temporary files mentioned by GE_Chen, migrating a running system via cp means temporary files exist for that system and will also be copied. One could clone an existing Jetson (which is technically not booted so far as the root partition is concerned) and then copy from the loopback mounted clone to avoid the temporary files.
In the past, what I’ve done is to unpack the sample rootfs directly onto the SATA drive or SD card as root, followed by the running the “apply_binaries.sh” script using the “–root /some/path/to/rootfs_device” option…also as root. This has worked well.
Note that when using an alternate rootfs location that the /boot directory of the alternate device is ignored, as u-boot is still installed on eMMC. The /boot on eMMC needs to remain intact, and it is in fact a good idea to copy this to the /boot of the SD card or other alternate rootfs device as a backup. The eMMC version is the one which determines boot parameters so long as you are simply migrating rootfs to a new device when originally flashed to mmcblk0p1. Directly installing to mmcblk1p1 also moves the boot loader, and leaves the original install unbootable (unless the alternate install can point to mmcblk0p1). To boot to multiple external devices it’s just easier to leave the boot loader on eMMC/mmcblk0p1.