Tiny Core 16.0 Alpha 1 Testing

[GNUser]

At this point I've tested 16.0alpha1 on three different x86_64 machines serving very different roles:

1. personal laptop
2. family media player + classic video game console emulator
3. wireless router running multiple servers (http, xmpp, dlna, ftp)

Everything just works.

Honestly, you guys have set the bar such that I've just come to expect "no problems", even in the alphas.

Hi Leee. Indeed. My experience has been consistent: Upgrading to alpha version of TCL is less trouble than (in years past) upgrading to stable version of other distros.

[Rich]

Hi Knoppix1337

... boot_delay=200 didn't seem to slow anything down, I even tried 2000. ...

You're right, I tried it too.
It seems that option is not configured:

Code: [Select]

# CONFIG_BOOT_PRINTK_DELAY is not setFound here:
http://tinycorelinux.net/16.x/x86/release/src/kernel/config-6.12.11-tinycore

Without error messages, there really isn't anything to go on.
That leaves the shotgun approach. Start disabling stuff and
see if we hit anything.

Try adding these boot codes:

Code: [Select]

acpi=off noapic nolapic
You can also try:

Code: [Select]

nomoduleThis should stop any kernel modules from loading in
case one of them is causing the problem.

If you want to experiment with other boot codes, there are about a thousand here:
https://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt

[ovacikar]

VIA Technologies C7 single core x86 32bit microprocessor.

What cpu features does it show in dmesg , when it boots successfully with the tcl 15 kernel?

Or you can compare successful dmesg to the frozen boot messages, which exact line is missing when it fereezes.

[Leee]

In 16.x / x86_64, abiword.tcz needs to have wv.tcz added to its .dep file.  Without it abiword fails to start:

Code: [Select]

tc@dolly:~$ abiword
abiword: error while loading shared libraries: libwv-1.2.so.4: cannot open shared object file: No such file or directory
abiword starts up ok after   tce-load -i wv

[Juanito]

..but: http://repo.tinycorelinux.net/16.x/x86_64/tcz/abiword.tcz.dep

contains:

Code: [Select]

wv.tcz
enchant2.tcz
goffice.tcz
redland.tcz
libical3.tcz
glibc_gconv.tcz
adwaita-icon-theme.tcz

[Leee]

..but: http://repo.tinycorelinux.net/16.x/x86_64/tcz/abiword.tcz.dep

contains:

Code: [Select]

wv.tcz
enchant2.tcz
goffice.tcz
redland.tcz
libical3.tcz
glibc_gconv.tcz
adwaita-icon-theme.tcz

Hmmmm.... Looks like tce-load did not retrieve abiword.tcz.dep - there likely was some error message that I didn't notice as I had many distractions at the time.

Apparently everything else listed in abiword.tcz.dep had already been downloaded as deps of other things, so the fact that there was no dep file at all didn't jump out at me.

[Rich]

Hi Knoppix1337
Paul_123 compiled a kernel that enabled the Boot Printk debugging option.
You can find it here:
http://tinycorelinux.net/16.x/x86/debug/

I tried it out by replacing quiet with:

Code: [Select]

boot_delay=200
The  Booting kernel  message displayed for about 2 or 3 minutes, probably
processing the early printk messages that don't normally get printed.
Then the regular printk messages started and they scrolled at a comfortable
rate to read.

[Knoppix1337]

I previously tried all kinds of cheatcodes including acpi=off noapic nolapic. I didn't know about nomodule but that had no effect either.

I tried the printk kernel, this machine is only 1ghz, so it waited alot longer than 2-3min at booting kernel, thanks for the warning.

It slowly went through all the messages, and IT BOOTED FINE!
So I tried it without the boot delay=200 and without loglevel=7, and it still booted fine.
Then I added sleep 13 and reboot to bootlocal.sh and left it for like 5 hours and it was still going.

So it works, but we still don't know why or what the issue was.

I was previously looking through the boot sequence code, and although I used the waitusb=13 cheatcode, the message from the bootcode never showed up showing that it was actually waiting. It's the only thing out of the ordinary that I noticed.

[curaga]

It's a kernel bug of some kind, but it will be hard to track down without messages, if you can't compile the kernel and try to bisect where it broke down.