tinycore_v2.8rc2

[Machete]

* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.

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.

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...

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:

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.

I don't have any VMs but this was sent in response to my query on Qemu:

I had no issues with Qemu and my test machines when I first suggested it in the 2.6 rc series.

It does not specify which version of Qemu.

As for VirtualBox, I have received:

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...

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).

[curaga]

I haven't seen the issue yet on Qemu 0.10.{2,5} and 0.11.1, all on linux.

[roberts]

Based on feedback and current and projected usage patterns, I have decided the current structure has become unwiedly. Therefore I am planning on a major change to the structure of how extensions are stored and managed.

Instead of releasing v2.8 as it currently is and then having a major change in v2.9,
I will not be releasing the current v2.8rc2 as v2.8 final. More to follow.
 
The new structure wiill be available for testing starting v2.8rc3
See also: http://forum.tinycorelinux.net/index.php?topic=4560.msg24126#msg24126

[helander]

Robert, could you share just a few words about what your aiming at?

I made a quick hack today to test some thoughts I have had. The main idea is to separate what get installed during boot from what is actually stored in the tce-directory. It works like this:

An added boot call named "install=extension" and when this is present only the named extension and its dependents are installed during boot. The named extension could typically be a meta-package (no real content but just having a dep file that starts the dependency chain". Dependencies are processed recursively. This of course requires the dep files to present in the tce-directory, but this is already done today when using appbrowser.

This allow me to at boot decide on a multitude of extension sets without having to prepare multiple tce-directories (and waisting space).

I added about 20 lines to /usr/bin/tce-seup and the extra processing time during boot is minimal (sub second).

/Lars

[bmarkus]

Quote from: bmarkus on January 06, 2010, 07:52:49 AM

Hopefully I will have access to another notebook with the same type where I can test it to exclude unique issue with my machine.

Unfortunately couldn't test as machine was moved to country side Sad

Today I got another ACER Aspire 5720Z notebook. Tested both 2.8rc1 and 2.8rc2. It is freezing randomly similar to my notebook already during boot at different phases, so it is not an issue with my machine bit with the model.

[roberts]

Thanks for the extra effort to test.

I will reverse kernel options in rc3, i.e., the smaller upx kernel will be available in the distribution area for those who wish and are able to use a smaller and faster booting kernel, the larger, standard kernel will be back in the iso for both Tiny Core and Micro Core in the next rc.

rc3 is coming along great, I am testing now on several boxes. I think everyone will be very surprised  with new features and streamlined extension mamagement options, of which appsaudit is central.