Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: Roberto A. Foglietta on June 03, 2009, 11:41:59 AM
-
roberto@rafbook:/media/disk-2/distro$ md5sum -c tinycore_2.0rc4.iso.md5.txt
tinycore_2.0rc4.iso: OK
roberto@rafbook:/media/disk-2/distro$ qemu -kernel-kqemu -cdrom tinycore_2.0rc4.iso -boot d
after creating new .Xauthority it says "error: could not open display"
trying xsetup.sh it says: "Segmentation fault"
-
I don't use Windows, so can't answer until I visit a willing friend who has such.
However, from reading posts, seems several users are running v2.0rc4 with Qemu.
I believe the Slim login manager was tested on v2.0rc4 and Qemu.
I also believe I read that a newer Qemu is required on Windows and that Qemu varied by Linux distribution. I could be wrong, as I don't run Qemu either.
-
I don't use Windows, so can't answer until I visit a willing friend who has such.
However, from reading posts, seems several users are running v2.0rc4 with Qemu.
I believe the Slim login manager was tested on v2.0rc4 and Qemu.
I also believe I read that a newer Qemu is required on Windows and that Qemu varied by Linux distribution. I could be wrong, as I don't run Qemu either.
I do not use windows since 1^ june 1999!
Qemu is available for linux too.
:)
-
Works for me (qemu 0.10.0). (gosh I hate saying that, I remember how it feels when I'm the one reporting.)
Is there an update available? Or other kqemu modes (default or no-kqemu)?
-
Works for me (qemu 0.10.0). (gosh I hate saying that, I remember how it feels when I'm the one reporting.)
Is there an update available? Or other kqemu modes (default or no-kqemu)?
qemu 0.9.1
this works
qemu -boot d -cdrom tinycore-2.0rc4.iso
this does not work
qemu -kernel-kqemu -boot d -cdrom tinycore-2.0rc4.iso
::)
-
That makes it a Qemu bug; try the latest version?
-
That makes it a Qemu bug; try the latest version?
qemu 0.10.0 into ubuntu 9.04:
qemu -cdrom tinycore_2.0rc4.iso -boot d
It says: "MP-BIOS bug: 8254 timer not connected to IO-APIC" and dies
At boot time using these: "tinycore nolapic noapic" works
Using -kernel-qemu option it shows the same warning message reported in my first post
-
i get this exact problem also (on a windows box using qemu)....tc 1.4 works fine with qemu 0.91......but tc 2.2 doesnt.....its only a problem when you try to use kqemu....i would also like to take this opportunity to say that i am a big fan of tiny core......very handy for bioinformaticists who want to use linux-based programs on windows machines.... :) keep up the good work!
-
This may be to late to help anyone but I had the same problem and checked the qemu help. You need -no-acpi
e.g. qemu -boot d -noacpi -cdrom tinycore_2.3.1.iso
worked for me when I got the ..MP8254 timer not connected to IOAP" problem.
Best regards.
-
I missed out the dash in -no-acpi i.e. qemu -boot d -no-acpi -cdrom tinycore_2.3.1.iso
Best regards dogflap
-
well...i have tried using different versions of qemu and kqemu (heres a good link to a windows binary of a recent qemu release: http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5147 ) .....but no luck getting past this one........the error messages are as described in Roberto A. Fogliettas first post......tiny core 1.3 is still fine.......bummer.... :-\
-
well...i have tried using different versions of qemu and kqemu (heres a good link to a windows binary of a recent qemu release: http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5147 ) .....but no luck getting past this one........the error messages are as described in Roberto A. Fogliettas first post......tiny core 1.3 is still fine.......bummer.... :-\
see http://forum.tinycorelinux.net/index.php?topic=3103.0 (http://forum.tinycorelinux.net/index.php?topic=3103.0)
-
thats a very nice guide you posted there.....unfortunately it doesn't seem to exactly solve my problem :( .....if you change your boot code to "qemu -kernel-kqemu -no-acpi -boot d -hda vdisk.img -cdrom tinycore_2.4rc1.iso" i think you will get the same error we have described....it was always my understanding that you need the "-kernel-kqemu" bit to actually use the kqemu accelerator..is that right??..unfortunately tiny core runs woefully slow for me without kqemu.....
one workaround i have found is to boot up with the Xorg-7.4 extension......when this is used "qemu -kernel-kqemu -no-acpi -boot d -hda vdisk.img -cdrom tinycore_2.4rc1.iso" works......i have noticed that when Xorg and kqemu is used, the window that tiny core opens in is somewhat smaller......
another thing i noticed was that my boot code could not contain "-std-vga" as i had previously used for my tiny core 1.3 setup......qemu just crashed...
a downside of loading Xorg at startup is it bloats things.......but...invariably a lot of the bioinformatics apps that i need to use have required this extension anyway.....so i guess i can live with that.....
...all of this indicates to me that something about X has changed between tiny core 1 and 2?......i tried loading up with the xvesa extension or xfbdev extension.....but it didnt change things......in any case.....i probably am just revealing that i have no idea what i'm doing haha!...i'm just a biologist!....
well.....maybe that might be enough info for people more knowledgeable than me to work out why this problem occurs....perhaps down the track i can learn how to make some bioinformatics-specific tiny core extensions... :)
cheers everyone
-
kernel-kqemu is not needed to use kqemu; it only uses it more. The default is user mode kqemu, which is somewhat slower, but still faster than -no-kqemu.
Of course this is on linux, I have no idea if it functions the same on Windows :P Also I use KVM, not kqemu for my accelerating (way faster, only available on linux).
-
kernel-kqemu is not needed to use kqemu; it only uses it more. The default is user mode kqemu, which is somewhat slower, but still faster than -no-kqemu.
Of course this is on linux, I have no idea if it functions the same on Windows :P Also I use KVM, not kqemu for my accelerating (way faster, only available on linux).
In Vista, user mode kqemu accelerates execution by a surprising amount. Without it tinycore runs too slow to be of much use but with kqemu tinycore/ opera for instance is useable (excluding flash video of course).
-
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 ...
-
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.
-
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.
-
@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.
-
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...
-
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.
-
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
-
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.
-
I am closing this topic as it was started for a very old rc4 and no the current v2.9 one