I've tried looking at other questions here with similar problems, but unfortunately I haven't been able to solve this issue.
For some basic background info, I'm currently using a PC in a lab and the lab has GPU servers somewhere in the institution. I'm attempting to connect the Atom Editor to the remote host. My PC uses Windows 10 and the remote server is Ubuntu 16.04.
I've looked at thie remote-atom guide but for some reason the "Start Server" option is not working. I've also tried to do what this answer has stated, but unfortunately I don't have sudo permission.
Would there be another way that I can connect Atom remotely? Thank you.
You can easily connect to remote FTP using atom even if you do not have any sudo permission on the sudo server.
On Remote server:
- Create a rsa key (ssh-keygen -t rsa)
- add the public key to .ssh/authorized_keys file
- download the private key to you local desktop
On local machine > open Atom editor:
- press ctrl+space to open the 'ftp-remote-edit'
- add the server if not present already
Atom editor: remote server configs
That's it, you are ready to connect and edit files.
Other viable option is using VS code using winScp.
I accidentally disabled my virtualbox host-only network in Network and sharing folder and it disappeared, and now I cannot do anything in Genymotion due to a network error. How do I find the network to enable it or get Genymotion to work again?
Genymobile soft is supposed to recreate the apropriate network on the fly when needed.
Make sure you use the last version and it should be fine.
I'm working on a Embedded Linux application and I would like to use GDB to debug it. The problem is that, although the Kit configuration seems fine (the Debugger option is correctly pointed to the GDB correspondent to the device's GCC - device is a Linux ARM), when I ask Qt Creator to run in debug mode it returns an error in the "Application Output":
sh: gdbserver: not found
This seems strange since, as I sad, the configuration is fine and no error about that is reported by Qt Creator in any moment before starting debug mode.
I did some research on the web to find which was the exact steps to use GDB to debug an Embedded Linux application from within Qt Creator (to use breakpoints, etc.) and the closest thing to an answer I got was this commentary by Tobias Hunger:
You will need to have ssh and gdbserver installed on your board for
this to work. Then you need to set up your board [qt-project.org] in
Creator. Afterwards you need to set up a kit [qt-project.org] using
this device.
Those steps, thought, are not clear to me.
First, why would I need to have a GDB inside the device if the Kit should point to my local GDB?
Or it shouldn't?
Where would I put the GDB anyway?
How do I know if I have this ssh on my device?
If I don't, how do I install it?
All the other mentioned steps are already done, but related to the GDB located on my Desktop Ubuntu. Should I change something if I do the above steps?
And of course, is this manual my Tobias complete or do I need to do something else for this to work?
You need gdb and ssh on your Ubuntu and gdbserver and sshd on your device: actually when you deploy a project on a remote device using QtCreator, it makes use of ssh for copying the files to target, then it launches gdbserver on the device (attached to the executable that you want to debug) and then launches gdb on your Ubuntu connecting to the running gdbserver on the device.
So you need all of them to make things working.
ssh and gdb can be installed on your Ubuntu simply via apt-get. Instead the installation of sshd and gdbserver on your board is platform-specific: it can be that some boards already have them in their standard system image, or maybe in some cases it is up to you to install them... if your Linux distribution on the board has some package manager then you might try to use it... in the worst case you will have to compile them on your own for your board and install them manually.
Currently I have installed RStudio in Ubuntu server. When I use another linux and windows system to ssh it, I can see the RStudio GUI. However, when I start to use my Macbook to ssh, nothing appears.
the command I entered is
"rstudio"
No error messages appear and no RStudio GUI appears either.
This is really confusing, can anyone give me some suggestions or ideas on what to do?
When I try to connect to local ports, Computer -> Connect local, using Portmon v. 3.02, I'm getting an error message, Error 2, in a small error dialog box:
I run the tool as an administrator (if not, I get error 6).
By the way this is a Windows 7 x64. On 32-bit, in Windows 7 x86, it works fine. How can I fix this problem?
Sysinternals' Portmon works only on 32-bit versions of Windows. It does not support 64-bit (probably its driver is not signed).
From the Portmon homepage:
Runs on:
Client: Windows XP (32-bit) and higher (32-bit).
Server: Windows Server 2003 (32-bit) and higher (32-bit).
In Windows Explorer, right click on portmon.exe --> select Properties --> click the Compatibility tab, and Run in Windows XP compatibility mode. It works fine like that in Windows 7 64-bit.
"Error 2" is "Cannot find the file specified", that is, cannot find a required DLL file.
Originally, you got this error when you tried to run Portmon from a network location: that broke the security trust, causing Portmon to be untrusted (or perhaps just messing up the search path somehow).
On my copy of Windows 7 64 bit, Microsoft Dependency Walker (depends.exe) tells me that PORTMSYS.SYS (the file created/loaded by Portmon.exe), has unresolved dependencies on ci.dll, clfs.sys, hal.dll and kdcom.dll.
Those are the
code integrity
common log file system
hardware abstraction layer
kernel debugger com
libraries, and they aren't actually missing: if they were, Windows wouldn't boot. However, I don't see a copy of those files in SysWow64. This suggests to me that the problem is not with portman.sys: the problem is with the win32 compatibility layer in Windows 7/64 bit: It doesn't support debug properly.
It is now 2018. There is no 64-bit version of Portmon. Serial ports are a legacy standard. The Windows 7 problem was fixed by the release of Windows 8.1. However, there is a faint chance that some Visual Studio utility or security update back-ported to Windows 7 will fix the problem. Perhaps someone who is familiar with SysWow and debugging will comment.
Instead of portmon for Windows x64, you can use an emulator of a pair of virtual COM ports and a simple program that will connect the physical port and one of the virtual ones, as well as perform the logging function.
To create a pair of virtual COM ports you can use:
com0com (preferably version "com0com-2.2.2.0-x64-fre-signed", because it contains signed x64 driver)
Virtual Serial Ports Emulator (VSPE), every time it starts on x64 it asks to purchase a driver, but it works even if you refuse.
Simple mapping and logging program can be found e.g. here or you can write it yourself, it is simple.
The sequence of actions is follows:
Сreate a pair of virtual COM ports using emulator (for example, COM28 and COM29)
Let the external device be connected to the computer COM1 port. In the program, whose exchange with external device we want to listen to, we set up a port COM28 (instead of СОМ1) for communication.
In the mapping program, we set up that we want to bind and log ports COM1 and COM29 (don't forget to set the port baud rate).
I haven't tried it yet, but this question mentions com0com. It creates two virtual serial ports and emulates a null modem cable between them. It claims to be able to run on 64 bit Windows. I'm not sure whether it comes with software that lets you just pipe input from a real port into one of the virtual ports. One of the FAQ's says that you can turn on logging.
I guess in the worst case, you could write your own small program that pipes data from a real port to one of the virtual ports and logs it all.
There's also this question on open-source alternatives that mentions a couple of projects.
I've used AccessPort
http://sudt.com/en/ap/download.htm and it works great. Very similar to Portmon
Don't start Portmon from a network drive/path or something else.
Copy on to the hard disk drive, e.g. on the desktop, restart and try again!
If you run Portmon in compatibility mode, it will work.
Check Make older programs run in this version of Windows.
It says:
To run the Program Compatibility troubleshooter:
Open the Program Compatibility troubleshooter by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type troubleshooter, and then click Troubleshooting. Under Programs, click Run programs made for previous versions of Windows.
Follow the instructions in the troubleshooter.
The above is a public explanation from Microsoft for a common situation when running older applications in Windows.
But, I can say it briefly;
Right click on portmon.exe
Select menu about "troubleshooting compatibility problem" or something like that (I'm using a foreign version of Windows, so I don't see correct name of that menu in English.)
Select automatic mode
It will detect the problem and recommend Windows XP (SP2) mode
Select it and execute Portmon again.
I hope it works!
Instead of Portmon you can also use the IO Ninja program with the "Serial Monitor" plugin.
It gives a little less information than Portmon, but in a more understandable form. The main thing is, just like a Portmon, it allows you to see the data that is transmitted between a third-party application and an external device via a serial port. The program works under modern versions of Windows (I tried it myself on Windows 10 x64). The aforementioned plugin "Serial Monitor" is paid (but has an evaluation period).
Note: the port that you want to monitor must first be connected to the "IO Ninja" program, and then opened in a third-party application whose exchange with an external device you want to track.
Just to test that the hardware is working, you could perhaps boot a Linux live CD and run the statserial and/or minicom program to verify that it works. The Knoppix distribution seems to contain both those programs.
Serial ports on Linux are named /dev/ttyS0 for COM1, /dev/ttyS1 for COM2, etc.