Flash script.
If I delete these files, many packages will not be updated.
Hello,
I create another folder directly, decompress the system source code again, and then flash the system. So I think this must have flashed all the content.
In general, there is no specific dependency that is completely affected, and it is nested.
This should probably work, but there might be some corner cases. If you do this, and you also do the same with “~/.nvsdkm/” content, then this might help if there was something wrong with the install itself.
Because the downloaded content is at “~/Downloads/sdkm_downloads/” it shouldn’t add a lot of time to start over after completely deleting the “~/.nvsdkm/” content and letting it regenerate. I’d even completely remove the “Linux_for_Tegra/” (or move it somewhere else, probably compressing it as you did).
If you suspect the actual download content is bad (probably doesn’t happen very often), then you could also remove “~/Downloads/nvidia/*”.
Regardless, if we can get the default case working and only later change the RT kernel, then I think odds of packages not having dependency problems would go up a lot. Before you ever change the kernel I’d completely update the system with the apt mechanism, and only then add the RT kernel. I’d keep the old kernel as a separate boot entry perhaps.
Hello,
I think you’ve got my meaning wrong.
I re-decompress just to flash a system without RT, because my original BSP has compiled RT into it, and I don’t want to adjust it any more, which has nothing to do with the original system being affected.
The key point is that no matter what the burning mode of my system is, whether it is RT Kernel or not, the system version will be changed when Jetpack is installed, and the method provided above cannot be installed normally.
Hi,
Please refer to the document below to check whether it meets your requirements.
To prevent
apt upgradefrom unintentionally overriding your custom kernel, you need to rename the kernel and initramfs images, and then updateextlinux.conf. You can do this either on the host or on the target….
Thanks
Hello，
I tried to adjust it according to the steps in the link, but I couldn’t get into the system when I restarted after the modification.
sudo mv /boot/Image /boot/Image.custom
sudo mv /boot/initrd /boot/initrd.custom
# edit /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT custom
MENU TITLE L4T boot options
LABEL primary
...
# Add a new entry to custom kernel
LABEL custom
MENU LABEL custom kernel
LINUX /boot/Image.custom
INITRD /boot/initrd.custom
APPEND ${cbootargs}
The following is the debug log of shutdown and restart after modification.
custom.log.txt (124 KB)
It uses Devkit and the official system without any changes.
Please help me to see if there is no change.
It’s interesting that the log is entirely non-readable binary. The custom boot entry seems like it is valid and should work. Do you have the unmodified kernel still as the default entry (or vice-versa, the modified as default…basically do you still have the original and new kernel both as boot entries)? One of the entries should succeed.
It might be useful to duplicate a working default entry. Take the original unmodified kernel and initrd and make both a default entry for it and a custom entry. For the custom entry actually copy the kernel and initrd to a new name like you did with the custom entry. The point is that if a package overwrites the original then you’ll still have the original in an alternate name, and from there it is easier to correct mistakes. The RT kernel could be in a third entry. At some point if we can get it working then the desired entry can become the default. About the only difference is changing the “mv” to a “cp”.
Hello，
Sorry, didn’t notice my files were encrypted.
I went ahead and tried to change the names of Image and initrd before installing Jetpack according to the steps in thel. Although successful, in jtop, the version has not changed to R38.2.1, but in fact it is viewed with "dpkg -l | grep -I l4t". Still downloaded R38.2.2. And the files I modified under the system will also be restored to the default.
For example, if I modify the script file under /usr/sbin/, the script will be restored to the original file after installing Jetpack.
This greatly affects the use.
This is probably the longer and more difficult way to see what is going on, but if you start with a system that has your kernel in it and is running correctly, and then go to install a .deb package, you could log this to have a record of exactly what it changes. In turn, this might allow looking at individual packages which make up the operation as a whole. You can append " 2>&1 | tee log_something.txt" to any apt or dpkg command.
Normally this would mean something like this:
sudo apt update 2>&1 | tee log_update.txt
sudo apt-get upgrade 2>&1 | tee log_upgrade.txt
sudo apt-get install ./jetpack-something.deb 2>&1 | tee log_jetpack.txt
That would be some work to make that useful, but if you feel motivated, then start with a fully “set up as you want it but not yet having jetpack install” system, and then log the steps and attach the logs to the forum (be sure to mention the exact command for the JetPack install step which is breaking things). Also list any files you are hoping to protect from change.
Note that you can use this to find out the name of a package which a file is from:
dpkg -S /some/where/a/file
For any file which changes you could also write down the name of the package which owns it via the “dpkg -S” command.