VirtualBox

Ticket #14178: vbox-irc-chat-log--discussion-about-possibilities-of-total-crash.txt

File vbox-irc-chat-log--discussion-about-possibilities-of-total-crash.txt, 23.0 KB (added by PAETH CLAUDIUSRAPHAEL, 9 years ago)

VBox-IRC-Chat-Log--Discussion-About-Possibilities-Of-Total-crash

Line 
1[VirtualBox 4.3.28 released! --- Forum: http://forums.virtualbox.org/ --- Bugtracker: http://www.virtualbox.org/wiki/Bugtracker --- User Manual: http://www.virtualbox.org/manual/UserManual.html]
2[10:05] == S466531257BOSS [5c4c254c@gateway/web/freenode/ip.92.76.37.76] has joined #vbox
3[10:06] <S466531257BOSS> hi, i have a serious problem with VirtualBox 4.3.28 running on Windows NT 6.3.1 x86 ( Windows 8.1 Industry Embedded all Updates 32-Bit ), which kills my machine totally ( mean immediate shutdown/restart ) mostly with machines, that either try to use the nx feature, or trying to activate virtualization themselve, or if i try bto run a 64-Bit machine;
4[10:06] <S466531257BOSS> The machine it runs on is a Dell 740 OptiPlex, sporting a AMD Athlon X2, 2.7 Ghz, run 2x2GB RAM DDR II
5[10:06] <S466531257BOSS> anyone here who think is able to help out, to go on with me, to isolate the failure?
6[10:07] <@MichalN> First of all, is it a regression or did VirtualBox never work on that system?
7[10:08] <S466531257BOSS> Hi, it is in this case a fresh install, though the same setup, did run before
8[10:08] <S466531257BOSS> i had to reinstall the whole, because the previous setup was killed totally
9[10:08] <S466531257BOSS> btw. the system runs via native vhd boot
10[10:08] == geomyidae_ [uid214@pdpc/supporter/professional/geomyidae] has quit [Quit: Connection closed for inactivity]
11[10:09] <@MichalN> OK, so it used to work but possibly very different software setup.
12[10:09] <@MichalN> What was the working VirtualBox version?
13[10:09] <S466531257BOSS> yes, it varies, but bthe virtualbox version was the same
14[10:09] <S466531257BOSS> it is as given 4.3.28
15[10:10] <@MichalN> Ah, so the same VirtualBox version worked on the same hardware with a different host OS setup?
16[10:10] <S466531257BOSS> sorry, no; it is exactly setup in the same manner as before
17[10:10] <S466531257BOSS> same host os, same vbox
18[10:10] <S466531257BOSS> only difference maybe drivers
19[10:11] <S466531257BOSS> as i used the given wddm driver for the graphics before
20[10:11] <S466531257BOSS> now it is the ati driver
21[10:11] <S466531257BOSS> do you think this might be a point ?
22[10:12] <S466531257BOSS> i run a firepro v5700
23[10:12] <@MichalN> Well, *something* must be different, right? :) It could be the host display driver, although to be honest it sounds unlikely.
24[10:12] <S466531257BOSS> dual head
25[10:12] <S466531257BOSS> do you have an idea, maybe a test ova
26[10:12] <S466531257BOSS> to reduce the possibilities
27[10:13] <S466531257BOSS> a step by step setup
28[10:13] <@MichalN> Some kind of Linux live CD would be good for testing, with a freshly created VM using default settings.
29[10:13] <@MichalN> In all problem cases the host system reboots but does not BSOD? So no crash dump?
30[10:13] <S466531257BOSS> no crtash dump at all, totally kill
31[10:13] <S466531257BOSS> what i can say is
32[10:14] <S466531257BOSS> that ANY time an applianxce tries to use bridged modes
33[10:14] <S466531257BOSS> it definately kills
34[10:14] <S466531257BOSS> but besides that, i cant reduce it to special settings
35[10:14] <S466531257BOSS> until now
36[10:14] <S466531257BOSS> :)
37[10:14] <S466531257BOSS> what do you say is a guaranteed setup
38[10:15] <S466531257BOSS> as for now i am chatting via webchat on the given machine
39[10:15] <S466531257BOSS> so it would be a perfect test if you can say what definately should function at all
40[10:15] <S466531257BOSS> if i am away you know what happened
41[10:15] <S466531257BOSS> :)
42[10:16] <S466531257BOSS> release is 100309
43[10:16] <@MichalN> Well, everything should function :) If you have a 32-bit VM, does it make a difference whether it uses software or hardware virtualization?
44[10:16] <S466531257BOSS> of vbox
45[10:16] <S466531257BOSS> no, tested that already
46[10:16] <@MichalN> You mean both can reboot the host?
47[10:17] <S466531257BOSS> all given combinations of usinh soft vs hard, nx on off etc. using shared folders or not, etc. im through wiith
48[10:17] <S466531257BOSS> tested already with ubuntu lucid for pae without nx, net install
49[10:17] <@MichalN> And that rebooted the host too?
50[10:17] <@MichalN> A 64-bit VM on a 32-bit host OS is a very special case, but it sounds like that's not the only problem.
51[10:17] <S466531257BOSS> and same with pae nx , also debian jessie live and old ova
52[10:18] <S466531257BOSS> it rebooted while system was already running
53[10:18] <S466531257BOSS> that is the only difference
54[10:18] <@MichalN> The trouble is that if the system just reboots, there's no way to tell what really caused it. Doesn't have to be VirtualBox.
55[10:18] <S466531257BOSS> so it got further
56[10:18] <S466531257BOSS> any idea for a sandboxed environment i could setup ?
57[10:18] <@MichalN> Also could be flaky hardware (memory, CPU, whatever).
58[10:19] <S466531257BOSS> thought that too
59[10:19] <S466531257BOSS> but already made ram and cpu stress test
60[10:19] <S466531257BOSS> no failure at all
61[10:19] <S466531257BOSS> hard disk also clean
62[10:19] <S466531257BOSS> gpu test runs fine too
63[10:19] <S466531257BOSS> btw, the host is running stable for days even under full use
64[10:20] <@MichalN> Stress tests don't always find the problem because they don't stress the hardware the same way as "real world" apps :)
65[10:20] <S466531257BOSS> independent of running
66[10:20] <S466531257BOSS> AH
67[10:20] <S466531257BOSS> yes ithere is a difference
68[10:20] == fmehnert [~fm3@p54B4662B.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
69[10:20] == fmehnert_ [~fm3@p54B4662B.dip0.t-ipconnect.de] has joined #vbox
70[10:20] <S466531257BOSS> it is crashing o Windows 8.1
71[10:20] <S466531257BOSS> i have debian jessie as host too and ubuntu 15.04
72[10:20] <S466531257BOSS> they do not crash
73[10:20] <S466531257BOSS> for host os
74[10:21] <S466531257BOSS> but at the moment i can not tell if it ios the same release
75[10:21] <@MichalN> Is that on the same host system?
76[10:21] <S466531257BOSS> yes
77[10:21] <S466531257BOSS> multiboot
78[10:21] <@MichalN> OK, that makes a hardware problem much less likely.
79[10:22] <S466531257BOSS> thought so, but to admit, i forget about that fact, so we can reduce it to windows version if that makes a difference
80[10:22] == `Cam [~textual@60-241-86-210.static.tpgi.com.au] has quit [Quit: ZZZ]
81[10:22] == towo` [~towo@ipb21920e8.dynamic.kabel-deutschland.de] has joined #vbox
82[10:23] <S466531257BOSS> what do you think is there any sandbox i could use to run the vbox ?
83[10:23] <@MichalN> Anyway, the only starting point so far is that that the more or less same setup used to work reliably, but no longer does. So the obvious question is what exactly changed to break it :)
84[10:23] <S466531257BOSS> yes :)
85[10:23] <S466531257BOSS> wait i have an idea
86[10:23] <@MichalN> I'm not sure what exactly you mean by sandbox. It's not really going to do anything, VirtualBox needs to access the host OS/hardware.
87[10:24] <S466531257BOSS> it could be that it not wotrked anymore after installing the visual studio ultimate 2013 testdrive
88[10:24] <S466531257BOSS> but i am not sure about it
89[10:24] <S466531257BOSS> at least it was the last software i installed
90[10:24] == fmehnert__ [~fm3@p54B4662B.dip0.t-ipconnect.de] has joined #vbox
91[10:24] == fmehnert_ [~fm3@p54B4662B.dip0.t-ipconnect.de] has quit [Client Quit]
92[10:24] <S466531257BOSS> i use visula studio community and professional normally
93[10:25] <S466531257BOSS> so it might be a point
94[10:27] <S466531257BOSS> you give up ? :)
95[10:28] <S466531257BOSS> ah sorry overread; by sandbox i mean things like sandboxie or similar
96[10:28] <S466531257BOSS> or debug via vs
97[10:28] <S466531257BOSS> whatever, any idea might help
98[10:29] <@MichalN> No, sandboxie etc. will do no good.
99[10:29] <S466531257BOSS> okay
100[10:29] <@MichalN> The only idea I have is narrowing down the problem to the change between working/non-working setup. If it's not VirtualBox, it has to be something else.
101[10:30] <S466531257BOSS> does vbox have a full logging mode ?
102[10:30] <S466531257BOSS> means is there an option to let it log anything
103[10:30] <@MichalN> Only debug builds, and even then it may not help.
104[10:30] <S466531257BOSS> hmm, sad
105[10:30] <@MichalN> If the host memory is getting corrupted for example, logging won't do much good.
106[10:31] <@MichalN> But the problem is again that a host reboot can be caused by pretty much anything. It's normally an indicator that the system state is too corrupted to continue.
107[10:31] <S466531257BOSS> are there any test ovas from oracle or community, maybe it is possible to narrow down INSIDE a vm
108[10:31] <@MichalN> But there's an infinite number of possible causes.
109[10:32] <@MichalN> I can't think of anything. Again, Linux live CDs are good for self-contained and reproducible testing (not installing the OS, just booting up).
110[10:33] <S466531257BOSS> sorry if not mentioned it to detail, NO PROBLEM AT ALL with any live cd
111[10:33] <@MichalN> Ahh, sorry, I missed that.
112[10:33] <S466531257BOSS> by any i mean: ubuntu lts versions 32 and 64 bit, debian wheezy and jessie, kali 1.1.0a
113[10:34] <S466531257BOSS> only distro that has problems by running very very slowly
114[10:34] <S466531257BOSS> is fedora 21, 17 and 19
115[10:34] <@MichalN> So it's not a general instability, it's something the guest OS does to trigger it.
116[10:34] <S466531257BOSS> no you dont miss i just did not got to it in detail until now
117[10:34] <S466531257BOSS> yes, i think so
118[10:36] <S466531257BOSS> what i could think of in fedora is 2 things: boxes, as it uses libvirt by default in 21 and the anaconda installer which is incredibly dumb in my opinion
119[10:36] <S466531257BOSS> so fedoara aside
120[10:36] <S466531257BOSS> all debian based os run fine as live
121[10:37] <@MichalN> Even the 64-bit guest OS versions work fine as live CD?
122[10:37] <S466531257BOSS> independent of live or, installer, netinstaller, graphical, cli, or even installed, but after having user profile setup they crash too
123[10:37] <S466531257BOSS> yep
124[10:37] <S466531257BOSS> even 64bit
125[10:38] <S466531257BOSS> so to be specific in the moment the guest os ( debian based ) switches from initial initrd to full desktop mode, hanging in drivers and stuff
126[10:38] <S466531257BOSS> so after rebooting into the fully setup guest os
127[10:38] <S466531257BOSS> do we have a breadcrumb ? :)
128[10:39] <@MichalN> Hard to say yet.
129[10:39] <S466531257BOSS> i thought so :)
130[10:39] <@MichalN> Does the host reboot always happen at the same point in the guest OS startup?
131[10:39] <@MichalN> As in, is it reliably reproducible or is there some randomness?
132[10:39] <S466531257BOSS> as i can visually follow, yes
133[10:40] <S466531257BOSS> in case of debian systems, right after logging in in a graphical env
134[10:40] <@MichalN> Does the VM have 3D enabled?
135[10:40] <S466531257BOSS> i tested both
136[10:40] <S466531257BOSS> on and off
137[10:40] <@MichalN> And it kills the host either way?
138[10:40] <S466531257BOSS> yep
139[10:41] <S466531257BOSS> is there a switch for vbox to run without any extension ?
140[10:41] <S466531257BOSS> just to countertest
141[10:41] <@MichalN> What do you mean by "extension"?
142[10:41] <S466531257BOSS> without any use of hardware acceleration or remapping, maybe the vbox mangement gui is not reliable
143[10:42] <S466531257BOSS> ah theres another thing
144[10:42] <@MichalN> You could try running a headless VM.
145[10:43] <S466531257BOSS> i do not run vbox from the documents folder, instead from a diverse pathh on a separate hdd
146[10:43] <S466531257BOSS> but i always do that
147[10:43] <@MichalN> That shouldn't matter.
148[10:43] <S466531257BOSS> okay
149[10:43] <S466531257BOSS> what would be the right switches for running headless in supersafe mode, if there is any option like that ? :)
150[10:44] <@MichalN> VBoxManage startvm <xxx> --type headless
151[10:44] <@MichalN> Or I think holding Shift while starting the VM from the GUI VM Manager should do it.
152[10:45] <S466531257BOSS> Just to prove me wrong: Can it be that running via native vhd boot ( so host inside a vhd ) is confusing vbox, as i use vhd instead of vdi or qcow for guests
153[10:45] <S466531257BOSS> shift while using start-button in gui or from menu ?
154[10:46] <S466531257BOSS> any difference
155[10:46] <@MichalN> Shift while double-clicking on the VM, I think.
156[10:46] <@MichalN> The VHD boot is really unlikely to cause trouble, but of course *something* must be.
157[10:47] <S466531257BOSS> okay i add that to my tests, any other ideas before i go with it, as i am still running on the problematic host with this chat :)
158[10:47] <@MichalN> Anyway, virtual disks are just files to VirtualBox, it doesn't really care what the host filesystem is, if the virtual disks are stored on a network share, etc.
159[10:48] <S466531257BOSS> okay good to know
160[10:48] <@MichalN> The only ideas I have is a) figuring out what changed on the host to cause this, or b) narrowing down what exactly it is the VM does to trigger the reboot.
161[10:49] == Akagi201_ [~akagi201@116.226.177.136] has quit [Ping timeout: 258 seconds]
162[10:49] <@MichalN> As in doing some kind of minimal boot with the guest OS and starting services manually, to get some better idea what is killing it.
163[10:49] <S466531257BOSS> what do you think of the fact, that anytime a guest os tries to use bridged mode it kills definately
164[10:49] <S466531257BOSS> so right before it can boot anything
165[10:49] == Akagi201 [~akagi201@101.81.71.113] has joined #vbox
166[10:50] <S466531257BOSS> means: right after start of the vm
167[10:50] <@MichalN> You mean the VM doesn't even start?
168[10:50] <@MichalN> Or as soon as the guest starts booting?
169[10:50] <@MichalN> What I think of that is that it's significant one way or another :)
170[10:50] <S466531257BOSS> specifically right at the moment the vm is started the whole machine ( host ) kills
171[10:50] <S466531257BOSS> itself
172[10:51] <@MichalN> In the "normal" case the VMs are using NAT? Or NAT Network? Or something else?
173[10:51] <S466531257BOSS> on that point, there is a difference, i use the onboard gigabit net now, before i used wifi g to acces my router before
174[10:52] <S466531257BOSS> in these cases a bridged mode is not given they do as described before
175[10:52] <S466531257BOSS> so live ones run without problem
176[10:52] <S466531257BOSS> and installed ones right after switching to full user experience in graphical mode
177[10:52] <S466531257BOSS> yes nat
178[10:52] <S466531257BOSS> in normal case
179[10:52] <S466531257BOSS> or manually set to nothing
180[10:53] <S466531257BOSS> proved that too
181[10:53] <S466531257BOSS> thin is i changed the pci wifi with a firewire pci
182[10:53] <S466531257BOSS> thats why i use cable now
183[10:54] <S466531257BOSS> onboard nvidia gigabit controller
184[10:54] <@MichalN> OK, so the host networking setup changed.
185[10:54] <S466531257BOSS> :)
186[10:54] <S466531257BOSS> .... yeees
187[10:54] <@MichalN> Can you try the old setup again?
188[10:54] <S466531257BOSS> sometimes things come up when talking bout ... :)
189[10:55] <S466531257BOSS> hmmm, i think i have usb wifi , if you think its enough to deactivate devices in windows host, that is an option
190[10:55] <S466531257BOSS> or is vbox able to see directly without the hal of windows what devices are inside the host ?
191[10:56] <S466531257BOSS> then i think i should screw the host up
192[10:56] <@MichalN> No. Host network drivers will be used.
193[10:56] == DCyrax_ [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox
194[10:56] <@MichalN> So what network device is used and what driver that device uses does matter.
195[10:56] <S466531257BOSS> so deactivating plus instead using a wifi usb might reduce the cases y you think ?
196[10:57] <S466531257BOSS> okay i added it to my test variants
197[10:57] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has quit [Ping timeout: 272 seconds]
198[10:57] <S466531257BOSS> any another idea
199[10:57] <@MichalN> What was the original networking setup again?
200[10:57] == DCyrax_ has changed nick to DCyrax
201[10:57] <S466531257BOSS> originally internal wifi dlink 54 mbit over g acces to an easybox 803
202[10:58] <S466531257BOSS> drivers actiove for nvidia gbit onboard controller but not used
203[10:58] == Hypnoz [~Adium@99-100-176-240.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Leaving.]
204[10:58] <S466531257BOSS> now im using the gbit net directly to an easybox 804 which is now master router
205[10:59] <S466531257BOSS> and the pci wifi dlink is out of and changed with a firewire controller
206[10:59] <S466531257BOSS> the original 803 is chained on the now easybox 804
207[10:59] <@MichalN> OK, so the previously used NIC isn't in the system anymore.
208[10:59] <S466531257BOSS> so connecting wifi to the easybox 803 would be the same net i used before
209[11:00] <S466531257BOSS> yep
210[11:00] <S466531257BOSS> its out
211[11:00] == aeichner_ [~aeichner@2a02:8109:8200:e48:201:2eff:fe35:4709] has joined #vbox
212[11:00] <@MichalN> Based on what you observed, does it look like the guest doing some network activity might be what's killing the host?
213[11:00] <S466531257BOSS> hmmm
214[11:01] <S466531257BOSS> ubuntu tries to check in ubiquity setup for given access to the nets
215[11:01] <@MichalN> I should say that NAT should be very safe because in that case VirtualBox is just a regular app that uses the TCP/IP network stack. Bridged networking is completely different.
216[11:02] == aeichner|nas [~aeichner@2a02:8109:8200:e48:201:2eff:fe35:4709] has quit [Ping timeout: 272 seconds]
217[11:02] <S466531257BOSS> i agree ( as far as my understanding of the insides go ), what makes me humble is that the host crashes immediately after starting the vm, when set to bridged
218[11:02] <S466531257BOSS> okay to be precise
219[11:03] <S466531257BOSS> it does NOT crash when bridging to another net
220[11:03] <S466531257BOSS> i have another unused pci net 100mbit in the host
221[11:03] <S466531257BOSS> i just didnt use it anymore
222[11:03] <S466531257BOSS> but it is present at all
223[11:03] <S466531257BOSS> and just tested if it crashes immediately too when bridged to that one
224[11:04] <@MichalN> So that didn't kill the host.
225[11:04] <S466531257BOSS> do you think, it could be the onboard gbit ( marvell yukon ) that might be a guaranteed killer independent of networking mode ?
226[11:04] <S466531257BOSS> right that didnt kill the host
227[11:04] == HeyCitizen [~HeyCitize@69.156.205.235] has quit [Quit: Coyote finally caught me]
228[11:05] <S466531257BOSS> at least until a fully installed guest ( linux) is runnig the desktop
229[11:05] <S466531257BOSS> after login into setup user accopunt
230[11:05] <@MichalN> That's what it sounds like, but I can't imagine why that would cause trouble with NAT. Unless it was the host NIC driver that's buggy.
231[11:05] <@MichalN> When you dual boot to Linux, you're using the same Marvell NIC?
232[11:06] <S466531257BOSS> im not into the details of linux systems, do you know if there is a hardware check for before ( in setup mode ) unseen devices like the nvidia onboard marvell yukon)
233[11:06] <S466531257BOSS> yes in host linux i use the same
234[11:06] <@MichalN> If the same NIC works in Linux then the NIC hardware is probably okay, but the driver still could be faulty.
235[11:07] == HeyCitizen [~HeyCitize@69.156.205.235] has joined #vbox
236[11:07] <S466531257BOSS> the idea is, maybe the installed guest linux tries to access other devices or do checks on the already found ones, even in nat mode ? like, some of the hardware might slip through to the guest ?
237[11:07] <@MichalN> You know, a few years ago I had trouble with some AMD board which I think had a similar NIC. The system was just never stable until I replaced it with a different NIC.
238[11:07] <S466531257BOSS> hope you understand what i try to tell, sorry im native german
239[11:08] <@MichalN> I understand. But no, the guest does not see the host hardware at all. It could only be something indirect.
240[11:08] <S466531257BOSS> so you, sofar agree it COULD be the or one of the problems
241[11:08] <S466531257BOSS> the gbit nic
242[11:08] <@MichalN> As in the network activity triggered by the guest will one way or another cause activity on the host NIC+driver.
243[11:08] <S466531257BOSS> think it helps deactivate via bios ?
244[11:09] <S466531257BOSS> as far as i know windows 8.1 gives a sh.. on it, as the device is accessible independent of bios setting
245[11:10] <S466531257BOSS> i just can deactivate it via device manager to get rid of it
246[11:10] <@MichalN> It should be possible to deactivate the device in the BIOS so that Windows can't see it at all, *if* everything works properly.
247[11:10] <S466531257BOSS> :) yeah
248[11:10] <@MichalN> But yes, disabling it in Device Manager is another option.
249[11:10] <S466531257BOSS> it SHOULD
250[11:10] <S466531257BOSS> okay added that one
251[11:10] <S466531257BOSS> so, you run hot already, anymore ideas, maybe curious ones ?
252[11:10] <S466531257BOSS> :)
253[11:10] <S466531257BOSS> btw
254[11:10] <S466531257BOSS> thanks for discussing these
255[11:11] <S466531257BOSS> it helps a lot to cook more brains than just the one i am carrying ;)
256[11:11] <@MichalN> No further ideas. So far it's clear there's some kind of problem with networking on the host system, the rest remains to be seen :) Trying a different NIC is definitely a good idea.
257[11:12] <@MichalN> A bad NIC/driver can easily corrupt host memory which can cause the kind of reboots you're seeing.
258[11:12] <S466531257BOSS> okay ill give it all a tray and countertest if thinking i found a solution; to spend some results, what is the best place? just in case it could help another user with a similar setup
259[11:13] <S466531257BOSS> i could have a lookup for the driver version, maybe the driver was updated on jump to 8.1 with update1
260[11:14] <S466531257BOSS> so where ( if ) ishould give feedback
261[11:14] <@MichalN> The VirtualBox bug tracker or forum is probably the best way to share information, although it's not yet clear that there is actually a bug in VirtualBox.
262[11:14] <S466531257BOSS> can you specify what exactly is needed to report a bug ?
263[11:15] == Tekn0 [~token@unaffiliated/teknomancer] has joined #vbox
264[11:15] == mode/#vbox [+o Tekn0] by ChanServ
265[11:15] <S466531257BOSS> ill do that work if possible
266[11:16] == JarJarBenks [~BenOrigin@cpc70137-lutn12-2-0-cust564.9-3.cable.virginm.net] has joined #vbox
267[11:17] <S466531257BOSS> ... just in case it results in a bug
268[11:18] <@MichalN> See here: https://www.virtualbox.org/wiki/Bugtracker
269[11:18] == JarJarBenks has changed nick to GenteelBen
270[11:19] == lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #vbox
271[11:19] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has quit [Read error: Connection reset by peer]
272[11:19] <S466531257BOSS> last question: is it okay to spend this chat logged in case of a bug report ?
273[11:19] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox
274[11:20] == pauled [~pauled@unaffiliated/pauled] has quit [Quit: pauled]
275[11:20] <@MichalN> I don't think anyone will want to read the entire conversation but sure, you can save it for later reference.
276[11:21] <S466531257BOSS> thanks a lot, for you helping out and your kindness; ill go testdrive now. thank you, and have a nice day, evening or whatever time ! :)
277[11:21] == D-Boy [~D-Boy@unaffiliated/cain] has quit [Excess Flood]
278[11:22] == DCyrax_ [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox
279[11:22] <@MichalN> Thanks!
280[11:22] <S466531257BOSS> thank you!, bye

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy