I’m trying to get a TI Dm6446 development board installed on a SUSE 10.3 Virtual machine. But when I copy a directory into another directory that is suppose to be the NFS shared directory, it looks like the whole Linux system is corrupted.
When I execute the cp command, everything seems to work fine as it doesn’t spit out any error messages, but when I then try to execute ANY other command, it comes up with the following errors:
-bash: /root/bin/grep: cannot execute binary file -> (when I switch users from andre to root using the “su -” command. The system still seems to switch as the text becomes red)
-bash: /root/bin/ls: cannot execute binary file -> (When I try to use the ls command; nothing happens and the list is not displayed)
-bash: /root/bin/chown: cannot execute binary file -> (When I try the chown command following the cp command. Nothing happens except for the error message)
Also, the files that were suppose to be copied are not visible in the required directory. I copied them with the following command:
cp -a /opt/mv_pro_5.0/…/target/* .
(where … contains a very long series of directories)
Does anyone have any advice for me? I am not sure if this is even posted in the right category on this forum, and if it is a problem with linux or with the TI software. My lack of knowledge about Linux would probably shock most of you, so any help offered is greatly appreciated!
Where are you when you execute this cp -a command, in /root?
It looks like the following is the case:
The directories you copied include a bin directory containing programs for a different architecture, and you have $HOME/bin on your $PATH. As a result, when you try to do a ls, it tries to execute /root/bin/ls but it’s the wrong kind of binary.
Try making a subdirectory in /root, say development, cd development and then do the cp to there. Then there’s no chance you will mess up your seach path with foreign binaries.
Thanks. What you said makes a bit of sense and may very well be the problem, but I’m still confused.
I need to make a copy of /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/ in the NFS shared directory /home/andre/workdir/filesys. But there is a directory called /bin in the /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/ directory, and from what you said this directory could lead to the problem.
When I executed the *cp command from the terminal, I was in the /home/andre/workdir/filesys directory, and I used the following command:
cp -a /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/ .
I also tried copying the files from the “My computer” GUI, but it complained about a lot of files with an error message of “Could not read /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/dev/ttyY24” for example.
Any ideas on how to make this copy process work better?
Well that file looks like a device and you can’t copy device files over NFS. I’m not sure what you are trying to do with the directories on openSUSE so can’t be more specific. If you are trying to run the embedded development system in a VM, couldn’t you install from the distribution media of that dev system?
The NFS is used as a memory location for the development system, so that you can compile a lot faster and to make the development process easier. The idea (from the manufacturers of the development kit i.e. TI) is to create a space on you computer’s harddrive where the program that you are developing resides.
They actually give clear instructions on how to install the system and all the components, but what is suppose to be simple and easy, and what happens in real-life, are 2 completely different things!
So how would you recommend copying a directory containing “devices” to another directory on the Linux VM? Sounds simple, doesn’t it?
The device files don’t make sense under a different OS and wouldn’t work there. However if they are only used by the guest OS, then what you have to do is to create the device nodes exactly as they will be under the guest OS with the major, minor numbers and permissions the same. Tar can copy device files, as can cpio. cp -a probably also does. You have just have to be careful that they are never used by the host OS.