Hello Tim,

I just executed that very command on my machine. There were no issues and the repo was pulled down cleanly.

Are you still seeing issues? If so, do you see the same problems getting to other mercurial repos. Try "hg clone http://selenic.com/hg mercurial-repo" and see if things come down cleanly.

I will say that it took a long time to start the actual transfer (1min). I wonder if you have a timeout somewhere that went stale.

Keep us posted,

Earl, team Mbed

Hello Earl Thank you for responding. I just tried you example. It works with out problems.

I still have the same problem checking out mbed-dev. It takes quite a whit before I get the error message to day, TMMW I guess.

The strange thing is: Before I experienced this problem I did A hg pull, and a hg update. Both worked, but I got a message telling me, that I now had 2 Heads. In stead of cloning in a diferent directory. Deleted the old file af tried to clone a new set of file *DOH*!

Whe ever the cause is. The problemis still there.

Sincerely Tim

Hello Tim,

I am stumped.

Here are some ideas that I pulled from discussions on the internet.

1) [I suspect you have already tried this one] Clone into a completely different directory.

2) Switch from https to ssh as the protocol. This fixed another user's similar issue.

3) There is some dubious discussions around this being a registry issue. I don't really have a fix here. I suspect there are some registry scanning tools that will check the registry for errors. The places online where I saw this suggestion were all pitching their tool, so please take this fix with a grain of salt.

After this tries, I don't know what else to try. You might try asking in the mercurial support channels. Someone there might have a suggestion.

Good luck,

+ Earl, team Mbed

Hello again Earl. Thank you for your feedback.

1) Yes, I of cause tried that. The problem persists.

2) An interesting approach if the problem can’t be solved otherwise, and fine as a fallback in emergencies. I gave it a pop just replacing https: with ssh:. It didn’t work for 2 reasons: It’s not correct syntax and You have a configuration error on the computer running os.mbed.com.

The correct syntax is: “hc clone ssh: / /oz4ga@os.mbed.com/ / users/mbed_official/code/mbed-dev/” “oz4ga” is my username. Replace it with your own username / login.

Notice the double slash (/ /) between mbed.com and the absolute path the repo. This is needed because the default for the path to the repo is to be relative to the user’s home directory.

Since I haven’t succeeded I can’t say if the user is going to be prompted for a password. If not I guess nothing would preclude using mbed_official as the login name. Then the double slash isn’t needed.

I said It wouldn’t work for 2 reasons. The other is: the path to the hg script isn’t included in the search path in the environment the subprocess spawned by sshd runs in, hence hg at the server side can’t be started which again result in, my hg won’t have a hg at your side to communicate with.

The error message is: “abort: no suitable response from remote hg!” This seems to quite a common problem indicating that either something has been changed at your end or this facility isn’t used at all or very rarely.

The remedy for this is of cause to change the above or telling me the absolute path to the hg script at the server, then I may use this information as a command line argument. When we get this working, I’ll be happy to provide input for a FAQ entry for this problem.

3) I concur that claiming this to a registry problem is dubious. I run AVG PC TuneUP on both my desktop and my laptop PC. This will rinse the registry for problems on regular basis. I’m facing the problem on both computers both before and after I triggered a registry cleanse on both.

Now what to do? I’m running 2 Raspberry Pi’s to automate tasks. A RPi 1B running Debian Jessie ans a RPi 3 running FreeBSD. The Linux RPi is facing the same problem, which indicates that this isn’t at all related to Windows. The eyeopener was that it actually IS works fine on FreeBSD. Sadly, the RPi 3 ran out of swap after fetching a few 1000 files when adding file changes. See transcript of the hg session below.

tim@nut:~ % uname -a FreeBSD nut.sunsite.lv 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320146M: Tue Jun 20 09:59:03 MDT 2017 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/ GENERIC arm64

tim@nut:~ %

tim@nut:~ % sudo hg clone https://os.mbed.com/users/mbed_official/code/mbed-dev/ destination directory: mbed-dev requesting all changes adding changesets adding manifests adding file changes files [=========> ] 4189/21957 3m49s

I did a quick one-person wave and fetched a clone using a bigger FreeBSD computer, so yes, I have my test environment running with mbed-dev version 163. This is of cause fine, but the root cause of all these problems hasn’t been established.

I can’t imagine I’m the only one using mbed-dev, so you haven’t heard the last of this. There haven’t any release of mbed-dev for months and It’s 4 days since Anna Bridge announced the release, so I’m a little surprised that you haven’t been bitten by this before. I’m probably the first doing a fresh “hg clone”. Everybody else must have been doing “hg pull” & “hg update”.

Since it works on my FreeBSD computer, but not on either of my windows computers and not on my Linus computer all sitting on same LAN segment behind the same NAT and therefore at the same official ip address, this can’t be related to routing. We can’t blame either of our ISP’s.

As a consequence, I dare to point my finger at MBED.COM. “somebody” changed “something” (TM) on either the os.mbed.com server and/or on your network. Since this is OS dependent, my first guess would be to look for a change in either a load balancer or a firewall. Such devices are from my experience capable of causing an OS based difference due to the differences in implementations of the TCP/IP stack.

The only other change I can imagine at a glance would be a change in or upgrade of mercurial and/or ssh software. The problem with hg not being found could indicate this as a possibility. I don’t believe this solely could be pertaining in a change in sshd. One should never say never. OpenBSD once had had a remote vulnerability I OpenSSH, I’m not suggesting you have a vulnerability in your software. I’m just claiming suggesting something fishy to be going on.

I ask you kindly to forward my ramblings to both your security team, your change management team, your network operations team, server operations team and ask then to consider the case. I’m confident that ARM/MBED is doing change management and incident handling according to ITIL or other pest practice framework for IT operations, hence it would be a good starting point looking on changes in reverse chronological order for areas relating to what I described.

Sincerely Tim Børresen