After my research this morning on NI forums, and after doing some tests with the cRIO, I can say:

• I checked the lvrt.conf file, and the RTTarget.LaunchAppAtBoot=True key is created automatically after the startup.rtexe is created from LabVIEW Project Explorer, set as Run As Startup, and deployed into the cRIO.
• After this, the cRIO MUST be rebooted to start the startup.rtexe, and now the ./nilvrt start and ./nilvrt stop can be executed successfully.
• So far I could not find another token to modify to avoid rebooting the cRIO to start running the startup.rtexe.
• I've found documents on internet that confirm that is necessary to reboot the cRIO after we deploy/transfer a new .rtexe, like this.
• This link mentions tokens on cRIO to be edited, but not more information that I know already.
• I'm gonna contact NI to ask for more information and create a post in NI forums.

The startup.rtexe is just a binary file to execute. When it was executed, the FPGA bit file will be downloaded to the FPGA. This is the same as using the C application to deploy the FPGA bit file. Therefore, it would be hard for me to imagine the startup.rtexe needs the "REBOOT" to make it work.

I thought in the Linux world, only the kernel-level update needs to reboot the system to make the new patch to work. I do not think startup.rtexe is in this kernel level. I felt it was just something like an executable, but maybe I was wrong.

I agree with you. I think is not necessary to REBOOT, too. I'm still working on this. 

After my today's tests, I can say that:

1. We can deploy the startup.rtexe using either the LabVIEW Project Explorer or the SCP command from the terminal.
2. If you want to use the SCP you have to find the startup.rtexe in the directory /build/home/lvuser/natinst/bin from the local machine, and send it to /home/lvuser/natinst/bin in the cRIO.
3. In the /etc/natinst/lvrt.conf file there is this RTTarget.LaunchAppAtBoot token that has to be set to True (RTTarget.LaunchAppAtBoot=True). If this token does not exist in the lvrt.conf file, please create it at the end of it.
4. The new startup.rtexe has to be stopped first with nilvrt stop and then run it with nilvrt start. This will let the software reload the configuration and recognize the new startup.rtexe (only if RTTarget.LaunchAppAtBoot=True).
5. If you want to connect to the cRIO from the LabVIEW Project Explorer, check whether the startup.rtexe is running or not. If it is not running, you will receive the message "Failed to connect to the target" in LabVIEW. If the startup.rtexe is running, you will be asked to abort it, with the message "The target is already running a Real-Time Startup Application. Press OK to confirm you want to abort the existing application and connect to the target from this project.".
6. Before sending the new startup.rtexe using SCP, check whether any startup.rtexe is created in the /home/lvuser/natinst/bin. If not, after sending the startup.rtexe you will note that this file has the owner admin. This will give problems to someone that needs to deploy a new startup.rtexe using LabVIEW Project Explorer. Please change the owner to lvuser to avoid this problem. This will not be necessary if you are going to replace the startup.rtexe.

For the point 5, "Failed to connect to the target", it is because the nilvrt is not running. Not the startup.rtexe.
For the point 6, the "owner" and "group" need to be checked. Do not forget, when you change the ownership of file, you use chown owner:group. For the list, an easy way is to check /etc/groups file.

Looks good. This content should be documented in ts_m2fpga in a latter time to let John know how to deal with it.