VirtualBox

Opened 11 years ago

Closed 11 years ago

#12171 closed defect (worksforme)

SVN hangs in Ubuntu Server 10.04 guest

Reported by: mkar Owned by:
Component: network Version: VirtualBox 4.2.16
Keywords: Cc:
Guest type: Linux Host type: Linux

Description

I am running Linux Mint Debian Edition (LMDE) with all updates as host and Ubuntu Server 10.04 as guest.

When I run e.g. "svn up" I will get a message e.g. "At revision 5262." but then the svn process hangs and never returns to the prompt.

The result is the same with network in both bridged and NAT mode. Ctrl-C does not work; I must use "kill -9" to get rid of the svn process.

An almost identical bug report was solved before (Ticket #6237 svn cannot work properly after upgrading to 3.1.4).

My VirtualBox version is 4.2.16. I checked the release-log for 4.2.18 but found no related fix there so I haven't tried it yet. svn client version on guest is v1.6.6.

For me this is a blocker since I connot run any builds on my virtual build-server if Subversion is not operating.

Best Regards, Mats

Attachments (1)

VBox.log (108.5 KB ) - added by mkar 11 years ago.
Log of start-svn_up-poweroff

Download all attachments as: .zip

Change History (11)

comment:1 by Frank Mehnert, 11 years ago

priority: blockermajor

Which file system are you using to perform 'svn'?

comment:2 by mkar, 11 years ago

Uhu? Both host and guest are using EXT4 if that is what you mean.

comment:3 by Frank Mehnert, 11 years ago

Yes, that's what I mean. The next piece of information I would like to see is a VBox.log file of such a VM session where you tried 'svn up' in the guest.

by mkar, 11 years ago

Attachment: VBox.log added

Log of start-svn_up-poweroff

comment:4 by mkar, 11 years ago

Nothing happened in the log during "svn up". Everything up to """00:00:14.694264 AIOMgr: Flush failed with VERR_INVALID_PARAMETER, disabling async flushes""" was during the start. """00:04:35.368522 Guest Log: VBoxGuest: VBoxGuestCommonGuestCapsAcquire: pSession(..."""" is from power down.

comment:5 by Frank Mehnert, 11 years ago

Ok. Are you 100% sure that you don't perform the 'svn up' action on the 'VMShare' (mapped to /home/makr/VMShare) shared folder? Because there are known issues with 'svn' and VBox shared folders...

comment:6 by mkar, 11 years ago

Yes, I'm sure, I'm running from a sub-directory of the users home folder.

The folder in question was actually checked out from the host by mounting the guest home folder from the host using sshfs, but this was only because "svn co" didn't work either.

I now tried "svn co" from guest with no external mounts of any kind and get the same result as before, i.e. after authentication to server nothing more happens, I have to kill the svn process yto get the prompt back. The VBox.log is the same too -- nothing happens after completed startup.

comment:7 by Frank Mehnert, 11 years ago

Could this be also a network problem, perhaps some firewall active? I saw in your configuration that you are using a host networking interface as network connection. Did you try to run tcpdump in the guest and on the host? Running both parallel could show if any packets gets lost. The symptoms you are describing point more to a problem with the networking connection. Also, do you run any special networking configuration, e.g. with jumbo frames enabled?

comment:8 by mkar, 11 years ago

No firewall active on guest or host. No special configurations of network interfaces.

tcpdump traces on host and guest are identical (with timestamps removed).

tcpdump -i eth1 "ip host 10.64.2.105" output:

...snip...
IP 10.64.2.105.22 > 10.64.20.252.51661: Flags [P.], seq 8580:8617, ack 7026, win 256, options [nop,nop,TS val 206189655 ecr 236710], length 37
IP 10.64.20.252.51661 > 10.64.2.105.22: Flags [.], ack 8617, win 220, options [nop,nop,TS val 236710 ecr 206189655], length 0
## Message on guest: At revision 5263.
IP 10.64.20.252.51661 > 10.64.2.105.22: Flags [P.], seq 7026:7191, ack 8617, win 220, options [nop,nop,TS val 236711 ecr 206189655], length 165
IP 10.64.2.105.22 > 10.64.20.252.51661: Flags [.], ack 7191, win 255, options [nop,nop,TS val 206189676 ecr 236711], length 0
## No activity for a long time, then I'm killing svn process on guest
IP 10.64.20.252.51661 > 10.64.2.105.22: Flags [F.], seq 7191, ack 8617, win 220, options [nop,nop,TS val 259065 ecr 206189676], length 0
IP 10.64.2.105.22 > 10.64.20.252.51661: Flags [.], ack 7192, win 255, options [nop,nop,TS val 206212009 ecr 259065], length 0
IP 10.64.2.105.22 > 10.64.20.252.51661: Flags [F.], seq 8617, ack 7192, win 255, options [nop,nop,TS val 206212009 ecr 259065], length 0
IP 10.64.20.252.51661 > 10.64.2.105.22: Flags [.], ack 8618, win 220, options [nop,nop,TS val 259065 ecr 206212009], length 0
^C
53 packets captured
53 packets received by filter
0 packets dropped by kernel
141 packets dropped by interface    <--this line on host only

comment:9 by mkar, 11 years ago

OK, closing in on the problem -- not VirtualBox's fault as it seems....

I have another build server (a physical machine) running the same software as my virtual machine and I get the same error there, however on my host it works without problem.

Tried changing svn protocol from https: to http: and voila, it works from the build servers too! I can live with http: for a while, but it would be good to get https: working too so I can use it on a trip (the purpose of moving to a virtual machine).

svn version on the build servers: 1.6.6. svn version on my host: 1.6.17.

I will try to upgrade svn on the vm build server.

@frank: Thanks for your help, sorry for wasting your time.

comment:10 by Klaus Espenlaub, 11 years ago

Resolution: worksforme
Status: newclosed

Thanks for the feedback!

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use