Tiny Core Base > Release Candidate Testing
Core v7.0beta1
andyj:
What happens if you set the copy2fs.flg and load them all? It's strange that rootfs only shows 20M used. I have 260+ loops and it shows 500M on my system.
coreplayer2:
I think I've figured out the problem, but the jury is not out yet..
Increased vmalloc to 256MB at the grub2 command line and hopefully that will accommodate the massive video card that appears to be causing the issue.
"UPDATE" this was the fix, I should have looked at dmesg sooner :p problem solved
thanks
curaga:
@coreplayer2:
If you boot without that option, what does "grep -i vmalloc /proc/meminfo" say (after hitting that mount error)? How big a GPU do you have?
edit: On a Qemu boot, there's 900mb reserved.
@andyj
There is a new kernel driver for the VMWare mouse, supposed to enable a better experience, but it requires Xorg and the vmmouse driver. Seems like you need a bootcode, psmouse.proto=imps, to disable the new vmmouse driver.
It's unfortunate this can't be detected at runtime. We can either:
- disable that driver, but then the VMWare mouse experience might suffer in the future, when they remove the userspace mouse sync from xf86-input-vmmouse
- just document that vmware + Xvesa needs that
Adding absolute pointer support (vmmouse, touch screens) to Xvesa would also be possible, but it's not something I'm interested in doing.
andyj:
The boot code fixes the mouse problem with Xvesa, insofar as it now exhibits the behavior of TC 6 where the mouse works but you have to manually ungrab the mouse to move it out of the window. The built in vmmouse driver also explains why manually ungrabbing the mouse in TC 7 wasn't required, even though the mouse wasn't working in Xvesa. I would answer the question this way: If someone is using VMware, then they will probably use Xorg and open-vm-tools to get the video and mouse functionality they need. If not and they stick with Xvesa then they know what they are getting. If they are using ESX then the video driver doesn't really matter because they are either using VNC to see the console, or in my case not running X at all and using SSH. I'm not having any luck changing this after boot, either through sysctl. /proc or /sys. Would adding this bootcode to the command line for the ISO image affect other platforms? Then we could go the documentation route, by pointing out during the "add boot codes" phase of the installation process that this is needed for VMware VM's using Xvesa and not Xorg.
curaga:
Adding the bootcode by default might break others' mice, especially laptop touchpads, so that's not an option. I don't think there's any runtime way, but I asked the VMWare people, maybe they have an idea.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version