Tiny Core 16.0 Alpha 1 Testing

[Knoppix1337]

Ok, I seemed to narrow down the problem. It is busybox. I had an issue with this a couple years ago with Knoppix.

I unpacked/repacked rootfs.gz and introduced some delays and debug comments in the startup scripts, specifically /init

at first I inserted:

Code: [Select]

#!/bin/sh

echo -n "holding at /init for 60sec..."
sleep 60
echo "done"and it would happily wait for 60 seconds and continue and soon lockup.

Ultimately I added a "counting dots" routine to "exercise" busybox

Code: [Select]

#!/bin/sh

echo -n "holding at /init for 10sec"

i=0
while [ $i -le 100 ]; do
  sleep .1; echo -n "."
  i=$(($i+1))
done and it locks up before it's finished counting.

I tried it with the prink kernel, and it boots, so I made a test script to again exercise busybox:

Code: [Select]

#!/bin/sh

echo -n "looping"

i=0
while [ $i -le 10000 ]; do
  sleep .1; echo -n "."
  i=$(($i+1))
done

and eventually it locked up, once so far, but it also locked up while trying to compile some code, so for whatever reason I think the printk kernel only delays the inevitable.

I'm going to try compiling the latest busybox (and perhaps earlier versions) to try and narrow this down further, and then report my findings both here and upstream.

[curaga]

If it tried to use non-supported instructions, you would see that (unhandled opcode error on screen). Thus I don't think it's busybox.

[Rich]

Hi Knoppix1337

Ok, I seemed to narrow down the problem. It is busybox.
 ----- Snip -----
I tried it with the prink kernel, and it boots, so I made a test script to again exercise busybox:

Code: [Select]

#!/bin/sh

echo -n "looping"

i=0
while [ $i -le 10000 ]; do
  sleep .1; echo -n "."
  i=$(($i+1))
done

...

I think that might be provable:
Install  bash.tcz  and  coreutils.tcz.

Change the first line of your script from:

Code: [Select]

#!/bin/shto:

Code: [Select]

#!/bin/bash
If you're running a GUI, click the  Exit  icon and select  Exit to Prompt.

Run:

Code: [Select]

ps aux | grep bin/Kill any instances of udevd, syslogd, and klogd.

Then run:

Code: [Select]

# Make sure the system can find bash.
hash -r
# Change the current shell from busybox ash to bash.
bash
# Launch your test script.
./TestScript
If it still locks up, it's probably not busybox.
Based on what you said here, it may not be very repeatable:

... and eventually it locked up, once so far, ...

So you may need to let it run for an extended period of time.

[MikeLockmoore]

Hi MikeLockmoore

... corepure64.gz = rootfs64.gz + modules64.gz ...

You can create corepure64.gz like this:

Code: [Select]

cat rootfs64.gz modules64.gz > corepure64.gz

Rich: I've done it the way you suggested.  Earlier I tried to do it with gunzip each, cat them together, then gzip the result.

Anyone: Maybe I'm too rusty and confused about things, but I don't think I'm getting a valid alpha release boot (note: I'm calling it "rc" below because I assume you are close to promoting 16 up to release candidate level soon).  Let me explain what I'm trying to do, then I'll look at any advice you have.

Step 1: Boot just the base TC 16 and graphical apps in FLWM built with FLTK 1.4.1 so I can see what they look like on my machine and how they behave.  I expect to be able to resize the GUI apps with Ctrl Plus/Minus keystrokes (is this a valid expectation, since they are built with FLTK 1.4.1?).  To do this, I have the vmlinuz from the TC 16 repo and the the two system files archives (rootfs64 and modules), merged into a "corepure16_16rc.gz" file as discussed above.

To boot this configuration, I have the vmlinux_16rc binary file and corepure64_16rc.gz binary file on my USB stick under the /boot folder (shows up as /mnt/sdb1/boot when I get it mounted).  From the isolinux menu, I select the 16 entry and edit it to look like:
LABEL tc_rc
MENU LABEL Boot TinyCore 16 RC                                                 
TEXT HELP                                                                     
Boot TinyCore  -- version 16 -- Release Candidate --
Boot media is removable. Use TAB to edit options for specific needs.
ENDTEXT
KERNEL /boot/vmlinuz64_16rc
INITRD /boot/corepure64_16rc.gz
APPEND loglevel=3 base norestore vga=791

But when I do this, I get no X GUI, just the command line.

Step 2: Be able to load some local extensions to my TC 16 config (so I can eventually use WiFi, firefox, and compile software while booted to TC 16).  I tried to use the same extensions in the CDE/ folder of my CD boot image on my USB boot memory stick.  The isolinux.cfg boot stanza is

LABEL tc_rc
MENU LABEL Boot TinyCore 16 RC                                                 
TEXT HELP                                                                     
Boot TinyCore  -- version 16 -- Release Candidate --
Boot media is removable. Use TAB to edit options for specific needs.
ENDTEXT
KERNEL /boot/vmlinuz64_16rc
INITRD /boot/corepure64_16rc.gz
APPEND loglevel=3 tce=sda2/tce16 restore=sda2/tce16 vga=791

When the sda2/tce16 folder has an onboot.lst file that includes FLTK-1.3.tcz and FLWM.tcz (and those files in the optional/ subfolder), I get a GUI desktop, but (I'm sure) the old version for FLTK 1.3 as built for TC 15.  If I delete the FLTK-1.3.tcz and FLTM.tcz from my onboot.lst file, I get a X GUI where the mouse cursor is only the XWindows "X" cursor (not the normal arrow pointer cursor).  The X cursor makes the wbar icons enlarge as I hover over them, but none of them respond to mouse clicks and I cannot get the system menu with right-mouse (trackpad in my case) click.

Thanks for your suggestions and helping this rusty TC user (and hopefully, again, a developer) out!
--
Mike

[Rich]

Hi MikeLockmoore

... APPEND loglevel=3 base norestore vga=791

But when I do this, I get no X GUI, just the command line. ...

I see a couple of issues.
The  base  keyword tells it you don't want to load any extensions.
Since you are booting from a USB device, you might want to append:

Code: [Select]

waitusb=5

[Knoppix1337]

Oh, yeah. I wanted to thank for explaining how the waitusb works, I didn't know you could wait for a specific UUID, I might use that on a machine with a spinning USB drive.

[MikeLockmoore]

I see a couple of issues.
The  base  keyword tells it you don't want to load any extensions.
Since you are booting from a USB device, you might want to append:

Code: [Select]

waitusb=5

Thanks, Rich.  I'll try the waitusb.  For my "Step 1", I was trying to boot the minimal GUI for TC 16 as you get when you download and boot the version 15.0 CorePure64  .iso (19.5 MB).  I was expecting that all the needed files are in rootfs64.gz and modules.gz which I merged to one init ram fs, but maybe that was a bad assumption. Is the simple Xvesa/Wayland GUI and FLWM and base FLTK apps like AppBrowser and terminal in these init ram fs files or do I need some extensions to boot the minimum GUI?  I want to make sure I'm running the latest FLWM and apps from Juanito.

[Rich]

Hi MikeLockmoore
There are no GUI components in the initrd.

For a GUI:

Code: [Select]

tce-load -wi Xorg-7.7 flwm_topside aterm wbar
startx
If you are running x86 (32 bit only) and want to use Xvesa:

Code: [Select]

tce-load -wi Xvesa flwm_topside aterm wbar
startx

[Juanito]

Some users are reporting that firmware will not load from /usr/local/lib/firmware - has anybody else seen this problem?

[MikeLockmoore]

Hi MikeLockmoore
There are no GUI components in the initrd.

For a GUI:

Code: [Select]

tce-load -wi Xorg-7.7 flwm_topside aterm wbar
startx
If you are running x86 (32 bit only) and want to use Xvesa:

Code: [Select]

tce-load -wi Xvesa flwm_topside aterm wbar
startx

Ah, OK. Thanks for helping me again.  I've tried to fetch all of the dependencies.  I am getting a checksum error on FLTK-1.4, which is needed by flwm/flwm_topside at least  I can't try startx yet.

@Juanito: do you need to update the checksum for FLTK-1.4.tcz?

[Juanito]

The fltk-1.4 checksum is OK on the server for the tc-16.x x86_64 repo - maybe you could delete fltk-1.4.tcz* from your tce folder and try again?

[MikeLockmoore]

The fltk-1.4 checksum is OK on the server for the tc-16.x x86_64 repo - maybe you could delete fltk-1.4.tcz* from your tce folder and try again?

Thanks, I deleted all the fltk-1.4 files in my tce16/ and re-fetched them and things are good. That was weird...  I thought I had fresh everything back when I posted that.

I can boot into the FLWM desktop now!  I can rescale some of the applications like ControlPanel and MountTool and Fluff.  But I can only scale them down, not up!   :'(  That is the opposite of what I wanted (what I really need to be able to see comfortably). 

Rendering speed in Firefox is quite slow on this Thinkpad T440p, which has a Core i7 4700MQ at 2.4 GHz processor, so it even if about ten years old, is not a slouch.  I can try the thinkpad-acpi firmware extension and see if that hurts/helps.  The top utility oes show high CPU (80 to 99%) use when Firefox is doing significant screen repainting.

[Rich]

Hi Juanito

Some users are reporting that firmware will not load from /usr/local/lib/firmware - has anybody else seen this problem?

GNUser reported that too:
https://forum.tinycorelinux.net/index.php/topic,27522.msg177455.html#msg177455

I looked into it a little and to me it appeared like /usr/local should work, but
GNUser said it doesn't.

[MikeLockmoore]

Rendering speed in Firefox is quite slow on this Thinkpad T440p, which has a Core i7 4700MQ at 2.4 GHz processor, so it even if about ten years old, is not a slouch.  I can try the thinkpad-acpi firmware extension and see if that hurts/helps.  The top utility oes show high CPU (80 to 99%) use when Firefox is doing significant screen repainting.

Actually, rendering speed was bad for everything, not just Firefox.  I now load thinkpad-acpi-6.12.11-tinycore64 on boot and the speed is good now even at full native resolution (1920 by 1080 pixels).  I can drag the FF window around the screen with my mouse and it repaints smoothly with basically zero tearing.   

[Juanito]

Depending on your graphics card, you could try Xorg-7.7-3d to use hardware acceleration if you have a compatible gpu.