Weird virtualbox...

[Stephen]

I have traditionally had better luck with Nvidia graphics with Linux.
however since the ATI/AMD merger they have REALLY stepped up their
Linux driver support. so much so that a HUGE contract went from Nvidia
to AMD fro graphics for the better Linux support. So before flipping
graphics hardware i would look into their drivers and see. I have run
into instances where the default Ubuntu chosen driver is not the right
choice.

On Sat, Jul 14, 2012 at 5:05 PM, kitepilot at kitepilot.com
<kitepilot at kitepilot.com> wrote:
> Well, I was able to determine that the 'malloc' error is happening in *MY*
> box (I thought it was happening on the *other* box), so I booted my box with
> a 'Rescatux' CD, installed SSH, did:
> ssh -fCXY user at remote virtualbox
> and it worked...
> What that means to me is that both, the last Xubuntu and the last Mint, have
> some weird interaction (kernel, video drivers, chipset, who knows) that
> causes the problem.
> I am also having issues because my box was either rebooting X or rebooting
> the whole enchilada, so I did run a memtest86+ for several hours without
> issues and I expect the hardware to be trustworthy.
> It is some sort of hardware disliking software issue.
> Or so I hope..
> Now the question that I am trying to answer is:
> which distro should I install to avoid this nightmare?
> The quest goes on...
> ET
> PS: This box has an ATI video card, should I expect a Nvidia to have better
> results?   I have always have a better luck with Nvidia, but YMMV...
>
>
>
> kitepilot at kitepilot.com writes:
>>
>> Well, the Gnomes are at work (again) in my box and I could certainly use
>> some help to evict them...
>> This is what's happening:
>> I use:
>> 'ssh -fCXY user at remotebox run-something'
>> a lot.
>> Works every time.
>> Or 'mostly' every time...
>> Now when I run (ONLY from *MY* box):
>> ssh -fCXY turboviking virtualbox
>> I get:
>> *** glibc detected *** /usr/lib/virtualbox/VirtualBox: malloc(): memory
>> corruption: 0x099c5e48 ***
>> And a long trace.
>> This is the quick rundown of how it broke:
>> My desktop was having hiccups and I decided to replace whatever I had
>> (can't remember what) with the latest Xubuntu.
>> After that, the problem started.
>> This problem, coupled with other issues, led me to scrap Xubuntu and
>> install the latest Mint/Mate.
>> Problem didn't go away...
>> The Xubuntu and Mint installations were fresh from-scratch installs, the
>> only thing I preserved was my home directory.
>> So the conclusion was evident: there is something in my /home/directory
>> causing the problem.
>> Nope...
>> Created another user, rebooted the box and logged in with the new user.
>> Same $#!T...   :(
>> Now, ANYTHING else that I have fired up works just fine.
>> And If I run the exact same instruction from other of my local boxes, it
>> works fine too!
>> It is ONLY 'vitualbox in my box' that fails.
>> But it used to work just fine...
>> Now the (unsolvable and incomprehensible to me) question is:
>> What could possibly be breaking the whole 'remote SSH run' mechanism (ONLY
>> for Virtualbox) in my box, which used to work fine before, and works fine
>> from everywhere else.
>> Other than sacrificing another goat and burying some transistors and
>> garlic wrapped on anti-static paper at midnite with no Moon, I don't know
>> what to do...
>> I have seen Virtualbox do weird things before when ran it remotely under
>> X/SSH, but this blows my (little) mind.  :(
>> Any ideas?
>> Sight...
>> ET
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss



-- 
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.

Stephen