rc4 xvesa does not work at all into qemu

[maro]

Due to some analysis I did today for another thread (http://forum.tinycorelinux.net/index.php?topic=4605.0) I stumbled across this one here and thought I provide an update about some potentially interesting discovery.

After I convinced myself that with TC 2.7 one could not run Xvesa in a QEMU VM which was started with '-kernel-kqemu' I did a comparison with TC 1.4.3. Since both /usr/bin/Xvesa files seemed to be identical (according to the md5sum result), I had a look at the dependencies (with ldd). To me it looked like that those are mostly libc related.

[... I'm skipping now over several iterations of my troubleshooting there were not all that successful ...]

I finally put all 14 /lib/*-2.3.6.so files from a running TC 1.4.3 VM, together with (and that is important) the 14 soft-links pointing to those libs into a single tar-archive. I transfered this tar-file to a TC 2.7 VM and extracted those 14 files and 14 soft-links in /lib. I had started this VM with the boot option 'text', and after this rather crude "downgrade" of libc from v2.9 to v2.3.6 was able to start Xvesa (via startx) on the TC 2.7 VM.

So I guess it should be possible to run Xvesa on a QEMU VM with '-kernel-kqemu' maybe after re-building Xvesa against the current libc (i.e. v2.9).

Please note: I'm not suggesting for a moment to operate such a system (with a "downgraded" libc) on a regular basis. To me this was just a proof-of-concept. I just wanted to convince myself that Xvesa can run. Most things I've tried seemed to work. But the appbrowser did not want to connect to the mirror, even though tce-load was working fine. Go figure ...

[bigpcman]

Due to some analysis I did today for another thread (http://forum.tinycorelinux.net/index.php?topic=4605.0) I stumbled across this one here and thought I provide an update about some potentially interesting discovery.

After I convinced myself that with TC 2.7 one could not run Xvesa in a QEMU VM which was started with '-kernel-kqemu' I did a comparison with TC 1.4.3. Since both /usr/bin/Xvesa files seemed to be identical (according to the md5sum result), I had a look at the dependencies (with ldd). To me it looked like that those are mostly libc related.

[... I'm skipping now over several iterations of my troubleshooting there were not all that successful ...]

I finally put all 14 /lib/*-2.3.6.so files from a running TC 1.4.3 VM, together with (and that is important) the 14 soft-links pointing to those libs into a single tar-archive. I transfered this tar-file to a TC 2.7 VM and extracted those 14 files and 14 soft-links in /lib. I had started this VM with the boot option 'text', and after this rather crude "downgrade" of libc from v2.9 to v2.3.6 was able to start Xvesa (via startx) on the TC 2.7 VM.

So I guess it should be possible to run Xvesa on a QEMU VM with '-kernel-kqemu' maybe after re-building Xvesa against the current libc (i.e. v2.9).

Please note: I'm not suggesting for a moment to operate such a system (with a "downgraded" libc) on a regular basis. To me this was just a proof-of-concept. I just wanted to convince myself that Xvesa can run. Most things I've tried seemed to work. But the appbrowser did not want to connect to the mirror, even though tce-load was working fine. Go figure ...

Does anyone have any more ideas on Maro's theory? It would be great if we could get kqemu '-kernel-kqemu' working again for Xvesa.

[Jason W]

I may soon rebuild Xvesa on TC 2.x and if all goes well I will provide it as an extension.  There are many things that can be wrong with an Xvesa build that I may not notice because it doesn't relate to my hardware.  If after testing and no issues reported, a rebuilt Xvesa could be considered for base.  But since the current Xvesa binary works so well for so many, I would want a rebuild to remain in extension status for a while before including it in an RC.

[maro]

@Jason: I now believe that there might not be the need for a rebuild of Xvesa on TC 2.x. Well, at least not if my findings here are correct and can be verified by others.

After I accidentally found some files that were probably used to build Xvesa (see http://forum.tinycorelinux.net/index.php?topic=3513.msg26763#msg26763) I attempted such a rebuild under TC 2.8.1 (using compiletc.tcz and a few other files). It took several iterations (with ca. 2h runtime per attempt) for me to find out (by trial and error) what was required until I finally had a new Xvesa executable . Albeit the result of running it in a QEMU VM (v0.11.1 with '-kernel-kqemu') was still a segmentation fault.

This result brought the focus back to libc (v2.9). I already knew (see reply #15) that changing it back to the version used for TC 1.x would allow Xvesa to run. Whilst I was looking for some details of how to re-build libc I stumbled over the following file:
    http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tcz/src/glibc-i486/glibc.gz
I assume that this is the result of what gerald_clark has mentioned in:     http://forum.tinycorelinux.net/index.php?topic=1685.msg25891#msg25891

Well, at first I tried to apply this version of libc on a freshly booted "plain" TC 2.8.1 VM, i.e. with QEMU parameters of
    qemu -soundhw ac97 -kernel-kqemu -cdrom tinycore_2.8.1.iso
As expected Xvesa failed after the initial boot, so I transfered 'glibc.gz' into the VM and did
    zcat glibc.gz | ( cd / ; sudo cpio -idum) ; startx
This time Xvesa started successfully. I also tried the Xvesa file of the Xvesa.tcz extensions, which had previously also failed with a segfault. As with the Xvesa exectuable from the TC 2.8.1 initrd the test was a success.

Next I build a new, remastered initrd, by extracting tinycore.gz followed by glibc.gz. I saved the result as tc-new.gz. I then used this new initrd explicitly with the following command:
    qemu -soundhw ac97 -kernel-kqemu -kernel bzImage -initrd tc-new.gz -append "quiet max_loop=256"
Please note that this is practically equivalent to the QEMU parameters used above (with the exception of tc-new.gz instead of tinycore.gz). As in the first test Xvesa started successfully, as did the Xvesa executable from the Xvesa.tcz extension.

So in summary: I'm pretty certain that the libc (v2.9) of the TC 2.x initrd is somehow "dodgy". A potentially "better" version seem to be available, which might also solve the kernel panic issue that other users have been reporting.

BTW, the Xvesa executable I had compiled on TC 2.8.1 seem to also work with the "patched" initrd. I'm sure more testing involving other QEMU users will be required to confirm my findings. I hope the description of the steps I undertook will help to facilitate those tests.

[Juanito]

I'm pretty certain that the libc (v2.9) of the TC 2.x initrd is somehow "dodgy". A potentially "better" version seem to be available, which might also solve the kernel panic issue that other users have been reporting.

The tc-2.x libc-2.9 gives problems with at least some i486/i586 machines. I've rebuilt libc-2.9 a few times recently - at the moment, the version you reference will boot on i486/i586 machines, but gives problems on other machines such as the atom n450...

[bigpcman]

I'm pretty certain that the libc (v2.9) of the TC 2.x initrd is somehow "dodgy". A potentially "better" version seem to be available, which might also solve the kernel panic issue that other users have been reporting.

The tc-2.x libc-2.9 gives problems with at least some i486/i586 machines. I've rebuilt libc-2.9 a few times recently - at the moment, the version you reference will boot on i486/i586 machines, but gives problems on other machines such as the atom n450...

Thanks for the investigative report maro. Looks like we need multiple versions 0f libc-2.9 available as extensions to resolve these problems.

[alu]

it would explain to me why flash crashes opera or why shiretoko loaded with flash causes a segfault when used on my gecko netbook (vortex x86 processor); i suspected libc to be guilty since libplayerflash.so depends on it, and i didn't see any other dep which would cause this

[maro]

Here is some good news, I've just booted the brand-new ISO of TC 2.9rc4 and that contains a new libc (v2.11.1):
    Xvesa does now start up properly without failing with a segfault.
Lets hope that other users (e.g. with special HW) are also getting a better result from this library upgrade.

With hindsight I should have just been lazy and waited a couple of days instead of spending quite a few hours on compiling, tweaking and testing. Ah well, at least I got a tiny bit more insight in what makes TC tick.

[roberts]

I am closing this topic as it was started for a very old rc4 and no the current v2.9 one