Tiny Core Base > Release Candidate Testing
tinycore_v2.8rc2
Machete:
--- Quote from: tclfan on January 08, 2010, 05:12:45 PM ---
--- Quote from: Kingdomcome on January 08, 2010, 12:47:55 PM ---
--- Quote from: roberts on January 07, 2010, 06:19:17 PM ---* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
--- End quote ---
This is the cause for the ACPI errors during boot and also the cause for the VM not closing after shutdown. I understand and respect what the team is trying to do with the upx'ed kernel, but I wont be using it in my daily use.
--- End quote ---
My brief testing was booting straight from LiveCD, but since I am planning to virtualize TCL soon, this is of great concern. It looks to me the issue is not VM BIOS's across the board, but rather UPX as the common denominator...
--- End quote ---
Which seems to agree with something I found in UPX's bug tracker on sf.net, granted it's a bit old (July 2008), but: http://sourceforge.net/tracker/index.php?func=detail&aid=2014835&group_id=2331&atid=102331
Back then, they weren't set up to handle bvmlinuz 2.08, and the first version of UPX to list support in their changelog is 3.04, released in September. As a test, I downloaded a copy for win32 & linux, and fed the uncompressed kernel image through each, using everything from -1 through -9, --best, --brute, and --ultra, all with the same results, except for -1 through -5, which wouldn't even compress.
If anyone knows of another distro that uses UPX'd kernels, I'd like to see if/how they worked around this issue, and see how it behaves in VirtualBox. I don't currently have access to the most recent builds of kvm/qemu, but hope to soon, and am willing to try it there, too.
roberts:
I find it interesting that the public versus the private posts, pms, emails differ so much.
First off, UPX of July 2008 is too old. We are talking about Sept 2009!
This is what was sent to me and started it all:
--- Quote ---I just noticed there had been a new release of UPX on Sep 27th, after a year. The new version supports recent kernels. So, compressing our bzImage gives back the old benefits of 200kb smaller size, and a bit faster boot.
--- End quote ---
I don't have any VMs but this was sent in response to my query on Qemu:
--- Quote ---I had no issues with Qemu and my test machines when I first suggested it in the 2.6 rc series.
--- End quote ---
It does not specify which version of Qemu.
As for VirtualBox, I have received:
--- Quote ---I just tested rc2 and everything seems to be fine. See attached screenshot.
Other specs if needed:
Host: Ubuntu Karmic 32-bit
VBox: 3.1.2 r56127 (Karmic package)
VM profile: defaults; no hard drive; no hw assisted virtualization;
boot from CD loaded with rc2 .iso
My previous test with vbox used AMD-V (hw assisted virt), but that
probably doesn't matter...
--- End quote ---
I have received no other hardware specific failures.
I only wish those who have it working in VMs share with those who are experiencing issues.
Machete:
I know that 2008 is old, hence the reason I alluded to it being old, isn't it? I had HOPED you'd be using a newer build of UPX than that! That's NOT the reason I linked to that bug entry. I posted it, to illustrate that this problem HAS SURFACED IN THE PAST, and that they've only fairly recently included support for it, 1.5 years later (at least, according to the changelog).
As for the responses you have received about other emulators, it's obvious that this is a mixed bag, working or otherwise. I'm still willing to forward any additional information you would like to help nail down what is going on in the boot sequence. VirtualBox, itself, obviously isn't the main factor, you quote someone using Karmic x86 using the most recent build, with no problems, yet I have a similar setup (as far as VB is concerned) and have issues with ACPI at boot time. Another user is using the latest qemu and having issues, yet the person you quote is not, even though they don't indicate which version they're using.
I asked for other distros so I could see if they were doing anything different on that front, what THEIR experience on the matter is, and, maybe, just MAYBE, they had any fixes or workarounds for us.
So, I'm re-wording my original request: if this were a NORMAL machine, ignoring the virtual aspect, how would one NORMALLY troubleshoot these issues? What can I do to get the information we need to resolve this? I'm not accustomed to having a kernel behave like this, on either a real or virtual machine, and I don't like it happening here.
althalus:
Is it possible the people experiencing this problem simply have motherboards that don't support APIC or have it turned off? The solution to virtualbox was just turn on APIC, after all, and a number of TC users ARE using very old hardware.
maro:
@althalus: As far as I can say from my own use of VB as well as reported here by Machete: ticking the 'Enable IO APIC' selection box makes the 'IO APIC resources could not be allocated' message disappear, but the 'ACPI: Unable to load System Description Tables' message is still showing up. Furthermore one still has to manually "switch off" the VM after poweroff. Therefore we don't have a "solution" to mitigate the regression reported for VB emulation using UPX compressed kernels.
I've now done a few tests involving different versions of QEMU, on different host hardware and different host OS: The results are somewhat inconsistent, but some regression with TC 2.7 vs. 2.8rc2 is noticable. Here are some test cases (unless noted, the VM was using 64 MBytes):
Host: AMD Athlon XP 2400+, OS: TinyCore 2.7, QEMU: 0.10.2
TC 2.8rc seems to work fine (no error messages, and proper "switch off")
Host: VB emulation under WinXP, OS: TinyCore 2.7, QEMU: 0.10.2
TC 2.8rc seems to work fine (no error messages, and proper "switch off")
Host: VB emulation under WinXP, OS: Slitaz cooking 091104, QEMU: 0.10.5
TC 2.8rc seems to work fine (no error messages, and proper "switch off")
Host: Intel Core Duo T2400, OS: WinXP, QEMU: 0.10.6
booting TC 2.8rc2 with a VM with 64MB memory seems fine,
but doing the same with 256 MB shows a different error message during the boot:
''ACPI: Unable to set IRQ for PCI Interrupt Link [LNKC]. Try pci=noacpi or acpi=off"
most likely as a consequence of the IRQ issue eth0 fails to work
Host: VB emulation under WinXP, OS: Ubuntu 09.10, QEMU: 0.11.0
TC 2.8rc2 shows the same regression as seen with VB 3.1.2 (under WinXP),
see first paragraph of this post (error message and no proper "switch off")
Host: Intel Core Duo T2400, OS: WinXP, QEMU: 0.12.1,
Host: VB emulation under WinXP, OS: TinyCore 2.7, QEMU: 0.12.1 and
Host: AMD Athlon XP 2400+, OS: TinyCore 2.7, QEMU: 0.12.1 (quick&dirty compiled by myself)
booting TC 2.8rc on each of these three VMs produces the error messages
"ACPI: Unable to load the System Description Tables"
"PnPBIOS: dev_node_info: function not supported on this system"
"PnPBIOS: Unable to get node info. Aborting."
during the boot process, and the "switch off" fails to work properly
I've done a few more tests, with results similar to those above. At least for myself a certain picture seems to emerge: A UPX compressed kernel does not play as "nicely" on more recent versions of QEMU (i.e. > 0.10.x) and VB. The size of the memory of the VM might play also a role (but I'm running out of time to look into this, at least for today).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version