Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on February 05, 2025, 05:58:51 AM
-
Team Tiny Core is pleased to announce that Tiny Core 16.0 Alpha1 is available for public testing:
http://repo.tinycorelinux.net/16.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/16.x/x86_64/release_candidates/distribution_files
This is an alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
Since this is an alpha cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.
We appreciate testing and feedback.
Changelog for 16.0 alpha1:
* kernel updated to 6.12.11
* glibc updated to 2.40
* gcc updated to 14.2.0
* binutils updated to 2.43.1
* e2fsprogs base libs/apps updated to 1.47.1
* util-linux base libs/apps updated to 2.40.2
* zlib base lib updated to 1.3.1
* getTime.sh: support more than one server from dhcp from miesi-ionos
* update-everything: offer to remove deprecated extensions from bdantas
* tc-function remove mount/umount from bb list from CardealRusso
* provides.sh: Rich's improved versions: update from CardealRusso
* linuxrc: remove symlink from GNUser
Not in the base, but also updated:
* mirrorpicker: grab info.lst from 15.x
* mirrorpicker: explicitly use bb wget
* editor: various changes from Rich
-
Hi Juanito. I'm on x86_64. Upgrade from 15 -> 16.0alpha1 went smoothly.
I've only found two small issues so far:
1. libsndfile.tcz is missing from the repo. This causes extensions that have libsndfile.tcz somewhere in their dependency tree (e.g., ffmpeg4.tcz, mpv.tcz) to not load.
2. xxhash.tcz, xxhash-dev.tcz, and upgraded rsync.tcz are missing from the repo.
-
1. libsndfile.tcz is missing from the repo. This causes extensions that have libsndfile.tcz somewhere in their dependency tree (e.g., ffmpeg4.tcz, mpv.tcz) to not load.
2. xxhash.tcz, xxhash-dev.tcz, and upgraded rsync.tcz are missing from the repo.
Correction: xxhash.tcz and xxhash-dev.tcz are present in the TCL16 x86_64 repo.
libsndfile.tcz and the recently-upgraded rsync.tcz do appear to be missing.
-
libsndfile and rsync copied over
-
Thanks, Juanito. Everything is humming now.
A major version upgrade with such minimal hiccups is something I've only ever experienced on TCL. Thanks and kudos to the team.
-
Hi Juanito
While troubleshooting another issue I found these
hard-coded dependencies:
16.x/x86_64/tcz/rtl88x2bu.tcz.dep:wireless-6.6.8-tinycore64.tcz
16.x/x86_64/tcz/tcc.tcz.dep:linux-6.6_api_headers.tczand:
16.x/x86/tcz/tcc.tcz.dep:linux-6.6_api_headers.tcz
All 3 have been fixed.
-
Thanks :)
-
System hangs at random times during boot on Wyse C Class (Cx0) and Wyse V Class (Vx0) thin clients.
I tried all kinds of debugging options to no avail.
I tried booting 15.x vmlinuz with the 16.x rootfs.gz and modules.gz and it boots fine.
I tried booting 16.x without the modules.gz, and it still hangs.
It never completes the boot sequence. It hangs somewhere between freeing kernel memory and network startup.
By hanging, I mean no response from caps/numlock, no ctrl-alt-delete, screen frozen.
Any advice?
-
No problems so far on my HP laptop. Honestly, you guys have set the bar such that I've just come to expect "no problems", even in the alphas.
Just a brief bit of testing with 16.0alpha1 / x86_64 with the exact same setup that I use for 15.0.
With the host is as described below by neofetch and using only the extensions listed in onboot.lst (below the neofetch output).
- firefox 133.0.3 works (as built for 15.x by firefox_getLatest)
- sound works with alsa (plus apulse for firefox)
- ssh and sshd work w/both password auth and key auth
- conky works
- emelfm2 works (with the same old issues it has had for years)
- gpicview works
- libreoffice works
- vlc works
- wifi works (as does wired network)
I haven't tried Thunderbird nor the editor mods yet.
tc@dolly:~$ neofetch
0000 Host: dolly
00 Model: HP ENVY x360 Convertible
00 00 OS: TinyCoreLinux 16.0alpha1 x86_64
00 00 0000 Kernel: 6.12.11-tinycore64
00 Uptime: 29 mins
0000 Packages: 275 (tce-status)
00 0000 Shell: sh
00 00 00 Resolution: , 1920x1080
00 00 00 WM: JWM
00 00 00 Terminal: aterm
00 00 00 CPU: Intel i5-6200U (4) @ 2.800GHz
00 00 00 GPU: Intel Skylake GT2 [HD Graphics 520]
00 Memory: 1374MiB / 11908MiB
00 00 00 (°- Disk (/mnt/sdb1): 95.9G / 3.6T (3%)
0000 00 //\ tce dir: /mnt/sdb1/boot/core16.0a1/tce64
00 0000 0000 v_/_ Local IP: 10.0.0.6
tc@dolly:~$ cat /tce/onboot.lst
graphics-KERNEL.tcz
openssh.tcz
lshw.tcz
usb-utils.tcz
pciutils.tcz
alsa-config.tcz
alsa.tcz
apulse.tcz
nmap.tcz
firmware-mediatek.tcz
firmware-iwlwifi.tcz
wifi.tcz
conky.tcz
Xorg-7.7.tcz
Xprogs.tcz
aterm.tcz
jwm.tcz
wbar.tcz
alsamixergui.tcz
fluff.tcz
thunderbird.tcz
firefox.tcz
vlc.tcz
libreoffice.tcz
emelfm2.tcz
xdotool.tcz
watcher.tcz
busybox_extras.tcz
zip.tcz
flnotify.tcz
e2fsprogs.tcz
samba.tcz
cifs-utils.tcz
gpicview.tcz
advcomp.tcz
tcl8.6.tcz
tk8.6.tcz
neofetch.tcz
-
Hi.
It would be a good timing to move on to FLTK-1.4 (currently, the latest is 1.4.1)
How are you going to compile it (with xft, with wayland ... etc)
BTW, they are switching to CMAKE instead of the usual autotools, when will cmake be available ?
-
Hi Knoppix1337
... It never completes the boot sequence. It hangs somewhere between freeing kernel memory and network startup.
By hanging, I mean no response from caps/numlock, no ctrl-alt-delete, screen frozen.
Based on that, it sounds like you already removed the quiet boot
code from your bootloader so you could see printk messages.
You could try adding the boot code:
loglevel=7That enables more messages.
If you want to slow down the rate messages are printed:
boot_delay=200That's delay between each message in milliseconds.
5 messages per second in this example.
How much RAM is installed?
-
Thanks, I've tried loglevel=7, I get more messages, but nothing to indicate what it's hanging on.
boot_delay=200 didn't seem to slow anything down, I even tried 2000.
This is a VIA C7 x86 32bit based machine with 2GB RAM.
-
System hangs at random times during boot on Wyse C Class (Cx0) and Wyse V Class (Vx0) thin clients.
What cpu do they use?
-
It would be a good timing to move on to FLTK-1.4 (currently, the latest is 1.4.1)
How are you going to compile it (with xft, with wayland ... etc)
BTW, they are switching to CMAKE instead of the usual autotools, when will cmake be available ?
I think we should start a separate thread for this since there’s several things to discuss and x86 may be treated differently to x86_64.
-
VIA Technologies C7 single core x86 32bit microprocessor.
-
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.
-
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:
# 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:
acpi=off noapic nolapic
You can also try:
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
-
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.
-
In 16.x / x86_64, abiword.tcz needs to have wv.tcz added to its .dep file. Without it abiword fails to start:
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
-
..but: http://repo.tinycorelinux.net/16.x/x86_64/tcz/abiword.tcz.dep
contains: wv.tcz
enchant2.tcz
goffice.tcz
redland.tcz
libical3.tcz
glibc_gconv.tcz
adwaita-icon-theme.tcz
-
..but: http://repo.tinycorelinux.net/16.x/x86_64/tcz/abiword.tcz.dep (http://repo.tinycorelinux.net/16.x/x86_64/tcz/abiword.tcz.dep)
contains: 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.
-
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:
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.
-
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.
-
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.
-
Hi Knoppix1337
Since it now boots, execute this:
dmesg > dmesg.txtand attach the file to your next post. Maybe something
will stand out.
-
Ok, here is the dmesg from Tiny Core 15 and 16.
-
Hi Knoppix1337
There wasn't much that caught my attention.
I had to look this one up:
rd.udev.event_timeout=13It only applies to systemd, which Tinycore doesn't have.
Here are a couple more boot codes you can try if you wish:
apm=off noisapnp
-
Hi Knoppix1337
I found netconsole which looked interesting:
https://mjmwired.net/kernel/Documentation/networking/netconsole.rst
though I had no luck in getting it to work. It looked like the netconsole
driver wasn't getting loaded.
-
Hi Knoppix1337
I figured it out and got netconsole working. It's pretty simple
and works with the stock kernel and initrd. Full details here:
https://forum.tinycorelinux.net/index.php/topic,27538.0.html
-
Although not strictly speaking in the base, the following have been updated in the tc-16.x x86_64 repo for testing:
fltk-1.4: can now use x11 or wayland
flwm/flwm_topside: recompiled against fltk-1.4 (can only be used with x11)
Xprogs: fltk_projects (gui applets) recompiled against fltk-1.4 and can now be used with x11 or wayland
fluff: recompiled against fltk-1.4
wbar-conf: recompiled against fltk-1.4 (can only be used with x11)
tc-install-GUI: recompiled against fltk-1.4
There are a couple of problems:
Using flwm or flwm_topside: when enlarging a window the window border does not get re-drawn and, with flwm_topside, the window controls disappear, but still work.
When using a mouse wheel to scroll in the RH pane of the apps gui, the LH pane also scrolls - this happens with both x11 and wayland.
The window title font probably needs adjusting, especially with flwm_topside
Suggestions on how to fix the above would be gratefully received.
Further testing with x11/flwm* and wayland/labwc/labwc-config would be much appreciated.
-
I ordered a serial null modem cable, the Wyse V Series (Vx0) has onboard serial, as well as my desktop machine. I used the kernel parameter
console=ttyS0,115200n8 for all 3 of these.
The printk is from the debug kernel you sent.
The failsafe is the cheatcodes from the Knoppix failsafe boot option containing: APPEND lang=en vga=normal atapicd nosound noapic nolapic noacpi pnpbios=off acpi=off nofstab noscsi nodma noapm nousb nopcmcia nofirewire noagp nomce libata.force=noncq hpsa.hpsa_allow_any=1 nonetwork nodhcp xmodule=vesa initrd=/boot/rootfs.gz,/boot/modules.gz ignore_loglevel no3d nofb console=ttyS0,115200n8
Obviously some parameters are ignored by TC.
-
Hi Knoppix1337
What happens with this boot code:
via-rhine.avoid_D3or this one:
module_blacklist=via-rhine
-
Hi Knoppix1337
One more thing. What happens if you boot without the
Lexar 8 GB USB Flash Drive plugged in?
-
After a few tries I realized it should be:
via_rhine.avoid_D3 or module_blacklist=via_rhine but the system still hung.
As far as the USB Lexar flash drive, I booted from the internal IDE flash DOM with no change.
I even used a PS/2 keyboard and both disabled USB in the BIOS as well as the kernel with the cheatcode: usbcore.nousb again with no change.
-
I tested labwc-config with tc-16.x x86_64 and the fltk gui applets seem to work as expected.
-
Hi Knoppix1337
The version which hangs (ser-con-Vx0-tc16-x86.txt) ends here:
Booting Core 16.0alpha1
Running Linux Kernel 6.12.11-tinycore.
Checking boot options... Done.
Starting udev daemon for hotplug support... Done.
loop: module loaded
usb-storage 3-2:1.0: USB Mass Storage device detected
scsi host2: usb-storage 3-2:1.0The "Checking boot ..." and "Starting udev ..." messages come /etc/init.d/tc-config.
"loop: module loaded" is due to tc-config executing "modprobe loop".
The last 2 messages are from the kernel.
The version which completes (ser-con-Vx0-tc16-x86-printk.txt) ends here:
Booting Core 16.0alpha1
Running Linux Kernel 6.12.11-tinycore.
Checking boot options... Done.
Starting udev daemon for hotplug support... Done.
usb-storage 3-2:1.0: USB Mass Storage device detected
scsi host2: usb-storage 3-2:1.0
loop: module loaded
via-rhine 0000:00:0b.0 eth0: VIA Rhine III at (ptrval), 00:80:64:84:0d:8f, IRQ 19
via-rhine 0000:00:0b.0 eth0: MII PHY found at address 1, status 0x7849 advertising 01e1 Link 0000
input: PC Speaker as /devices/platform/pcspkr/input/input4
cpufreq: CPU0: Fast frequency switching not enabled
cpufreq: Registered transition notifiers:
cpufreq: 0xc01257d0
scsi 2:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 4
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sdb] 15679488 512-byte logical blocks: (8.03 GB/7.48 GiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 43 00 00 00
sd 2:0:0:0: [sdb] No Caching mode page found
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 2:0:0:0: [sdb] Attached SCSI removable disk
random: crng init done
Adding 227132k swap on /dev/zram0. Priority:-2 extents:1 across:227132k SS
Scanning hard disk partitions to create /etc/fstab
Setting Language to C Done.
Setting Timezone to America/Chicago Done.
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Possible swap partition(s) enabled.
Loading extensions...parport_pc 00:05: reported by Plug and Play ACPI
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
ppdev: user-space parallel port driver
Done.
Setting keymap to us Done.
Restoring backup files from /mnt/sda1/tce/mydata.tgz Done.
longhaul: Option "enable" not set - Aborting
Setting hostname to box Done.
login[604]: root login on 'tty1'Maybe the cpufreq module is hanging the CPU.
Try:
initcall_blacklist=cpufreq
You could also try this to reduce udev activity:
udev.children-max=1
... The failsafe is the cheatcodes from the Knoppix failsafe boot option containing: APPEND lang=en vga=normal atapicd nosound noapic nolapic noacpi pnpbios=off acpi=off nofstab noscsi nodma noapm nousb nopcmcia nofirewire noagp nomce libata.force=noncq hpsa.hpsa_allow_any=1 nonetwork nodhcp xmodule=vesa initrd=/boot/rootfs.gz,/boot/modules.gz ignore_loglevel no3d nofb console=ttyS0,115200n8
Obviously some parameters are ignored by TC.
Parameters that the kernel does not recognize wind up in /proc/cmdline
for use by system scripts. TC uses this mechanism too.
The noacpi code is valid, but not by itself. It should be:
pci=noacpi
... 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. ...
The waitusb=N only executes a sleep N instruction with no message.
It will always wait N seconds.
The waitusb=N:UUID="UUID of device to wait for" will echo a countdown while waiting.
It will wait up to N seconds.
It will continue when the device is ready or N seconds has elapsed, whichever comes first.
-
Problems with re-drawing window borders using flwm/flwm_topside in x86_64 seem to have been fixed, updated extensions uploaded.
-
@polikuo - when using labwc-config in x86_64, things seem to work OK, but when I exit to the console I cannot "startx" (Xorg-7.7 flwm aterm wbar), the gui begins to start and then hangs.
I don't see an error in the xorg log - any ideas?
-
Problems with re-drawing window borders using flwm/flwm_topside in x86_64 seem to have been fixed, updated extensions uploaded.
Juanito: That is great news! Thanks for helping me get back up to working on FLTK aps and FLWM... looks like I'm getting here too late to help much. I would like to get 16 RC up and running though. The RC files at http://repo.tinycorelinux.net/16.x/x86_64/release_candidates/distribution_files/ don't seem to show today's date. Is that the right place to grab them?
Juanito or anyone... I'm currently booting TC15 on a ThinkPad laptop form a USB stick, I think in "legacy" mode (non UEFI). It modded the boot config to use different boot parameters to use my internal SSD storage as my tce/ home (deleted "cde" from the boot parmeters and added "tce=sda2 restore=sda2")
I'd like to keep the 15 kernel as an option, and setup my USB boot stick to have a new TC 16 RC menu entry.
I think I can do this by copying over the RC vmlinuz64 with a new name to sit next to the TC 15 vmlinuz kernel, then making sure the RC boot menu entry refers to the correct name of the kernel I want.
However, I'm not sure how to set up the modules.gz and rootfs64.gz. is the RC rootfs64 the same as the corepure64.gz that is on my USB boot stick? So I can set up my boot entry like this...
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/rootfs64.gz
APPEND loglevel=3 tce=sda2/tce16 restore=sda2/tce16 vga=791
What do I do with the modules.gz in the release candidates URL? Thanks for any suggestions! -Mike
-
The RC files at http://repo.tinycorelinux.net/16.x/x86_64/release_candidates/distribution_files/ don't seem to show today's date. Is that the right place to grab them?
Yes
I think I can do this by copying over the RC vmlinuz64 with a new name to sit next to the TC 15 vmlinuz kernel, then making sure the RC boot menu entry refers to the correct name of the kernel I want.
Yes, you can rename them, for example, modules64_16.gz, rootfs_16.gz and vmlinuz64_16
However, I'm not sure how to set up the modules.gz and rootfs64.gz. is the RC rootfs64 the same as the corepure64.gz that is on my USB boot stick?
corepure64.gz = rootfs64.gz + modules64.gz
So I can set up my boot entry like this...
Using grub you can specify "initrd /boot/rootfs64.gz /boot/modules64.gz"
I'm not sure if your boot loader can do this or not (you can try :) ), otherwise you'd have to concatenate them
-
Hi MikeLockmoore
... corepure64.gz = rootfs64.gz + modules64.gz ...
You can create corepure64.gz like this:
cat rootfs64.gz modules64.gz > corepure64.gz
-
Thanks Rich and Juanito. I did get it to boot! I'm having networking issues and I notice that screen & window repainting is much slower than normal. A big window takes about 1 to 2 seconds... you can see the repaint flow down the window. :o
I have to take a break now for some family activities, but I'll probably work on this later today. Thanks again!
-
Bind 9.20 needs liburcu-dev, which is available for 64 bit but not 32 bit. I'm also building against Tcl/Tk 9.0 which is not ABI compatible with 8.6. Other updates will include MariaDB 11.4, PHP 8.4, and Postgresql 17.
-
Minor update: I did a boot with 16 RC with a "base" boot parameter to avoid any release 15 extensions being loaded or anything from my version 15 home. The graphic repaint is working much better. Maybe not as snappy as regular version 15, but you can't see redrawing flow. If you quickly move a GUI window like the text editor, there is more graphical tearing than version 15, but nowhere near as bad as I was seeing with a bunch of extensions loading, including thinkpad_acpi.tcz which I think includes some graphics drivers for DRM mode, etc. Maybe some of the version 15 extensions don't play nice with v.1.4.1 FLTK built into the new version of FLWM?
I do need to build back up a developer's set of extensions for the version 16 RC boot mode to maybe do some refinement of FLWM or apps. I'm not sure if I am supposed to be able to do this, but I thought the GUI apps (e.g. Control Panel and Editor) should be scalable now with Ctrl Plus or Ctrl Minus key combos, but I didn't see it work so far.
As far as running extensions in this 16 RC environment, can I just use the normal Apps tool and pull in the regular extensions and have them run "on boot" as normal, or will I need special extensions? I think there's a wireless library that wants kernel 6.12-specific stuff that won't work with the wiresless kernel modules extension for release version 15.
-
Hi MikeLockmoore
I would avoid mixing extensions from different versions. Kernel
modules shouldn't be an issue. Dependency files don't include
kernel versions. They include entries like wiresless-KERNEL.tcz.
Then, tce-load uses uname -r to determine the running kernel
and uses that to replace KERNEL with the kernel version and
load the matching kernel module extension.
Problems can occur when extensions and or dependencies are
updated to different versions across releases.
What I do is set up separate partitions for different versions. I
make them between 2 and 4 Gigabytes. That's plenty of space
for extensions as well as a persistent home and opt directories.
-
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: #!/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#!/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: #!/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.
-
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.
-
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:
#!/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:
#!/bin/shto:
#!/bin/bash
If you're running a GUI, click the Exit icon and select Exit to Prompt.
Run:
ps aux | grep bin/Kill any instances of udevd, syslogd, and klogd.
Then run:
# 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.
-
Hi MikeLockmoore
... corepure64.gz = rootfs64.gz + modules64.gz ...
You can create corepure64.gz like this:
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
-
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:
waitusb=5
-
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.
-
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:
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.
-
Hi MikeLockmoore
There are no GUI components in the initrd.
For a GUI:
tce-load -wi Xorg-7.7 flwm_topside aterm wbar
startx
If you are running x86 (32 bit only) and want to use Xvesa:
tce-load -wi Xvesa flwm_topside aterm wbar
startx
-
Some users are reporting that firmware will not load from /usr/local/lib/firmware - has anybody else seen this problem?
-
Hi MikeLockmoore
There are no GUI components in the initrd.
For a GUI:
tce-load -wi Xorg-7.7 flwm_topside aterm wbar
startx
If you are running x86 (32 bit only) and want to use Xvesa:
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?
-
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?
-
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.
-
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.
-
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. ;D
-
Depending on your graphics card, you could try Xorg-7.7-3d to use hardware acceleration if you have a compatible gpu.
-
I got the FLTK apps rescaled bigger by changing the Xft.dpi setting in .Xdefaults. I tried 120.0 (133% bigger than default 96.0), but I think I could live with 120.0 (125% bigger than default 96.0) fairly well.
However, there is an issue with FLWM in this mode that the title bar does not grow to show the fully-scaled font and the window sizing buttons disappear, which I think @Juanito has noted before. When I have some time over the next week, I hope to look into this and try to develop a patch for FLWM to better handle the window scaling. If we can also support scaling FLTK aps up above 100%, I'd like to do that too, but at least changing the Xft.dpi in .Xdefaults gives me a bigger "100%" to start from. :D
I've attached a screenshot, which has a lot of whitespace to help it compress to within the required size limit.
Depending on your graphics card, you could try Xorg-7.7-3d to use hardware acceleration if you have a compatible gpu.
Thanks for letting me know about this, but with just the thinkpad-acpi extension, it is running fairly well... perfectly usable like this. If I feel the need to do something with real 3D rendering, I could look into that.
-
I looked under linux-6.12.11/drivers/net/wireless/realtek/rtw88 and don't see that /lib/firmware is hard coded anywhere.
I see this in the kernel config: # Firmware loader
#
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""..but it's not been set to anything as far back as tc-10.x
I also see this: /tmp/linux-6.12.11/drivers/base/firmware_loader/Kconfig: the directory specified by the EXTRA_FIRMWARE_DIR option, which is
/tmp/linux-6.12.11/drivers/base/firmware_loader/Kconfig:config EXTRA_FIRMWARE_DIR
/tmp/linux-6.12.11/drivers/base/firmware_loader/builtin/Makefile:# Create $(fwdir) from $(CONFIG_EXTRA_FIRMWARE_DIR) -- if it doesn't have a
/tmp/linux-6.12.11/drivers/base/firmware_loader/builtin/Makefile:fwdir := $(CONFIG_EXTRA_FIRMWARE_DIR)..but I wonder if this is for firmware blobs to be built in to the kernel.
I have a couple of devices that require firmware and both load it from /usr/local/lib/firmware without problems.
-
However, there is an issue with FLWM in this mode that the title bar does not grow to show the fully-scaled font and the window sizing buttons disappear, which I think @Juanito has noted before.
That was referring to enlarging a window by dragging - prior to the patch to flwm, enlarging a window in flwm_topside would result in the window border and buttons disappearing, which was fixed by the patch.
-
Ok, sorta rude awakening this morning.
Yesterday I ran the printk kernel with the #!/bin/sh version of the script to make sure it indeed locks up, and it did after 170,000 loop iterations (I changed the echo to print the loop number instead of a dot and increased the number of loops)
Then I did as you listed;
installed coreutils + bash, ran ps, killed processes, changed the script to #!/bin/bash, and ran the script overnight.
It locked after 348,000 iterations.
So what can we try next?
-
Hi Juanito
I took a look at the Kconfig file and it lists:
config EXTRA_FIRMWARE
string "Build named firmware blobs into the kernel binary"You set it like this:
EXTRA_FIRMWARE="foo.bin bar.bin etc.bin"
Then there is:
config EXTRA_FIRMWARE_DIR
string "Firmware blobs root directory"
depends on EXTRA_FIRMWARE != ""
default "/lib/firmware"It's where the build system gets the firmware it's compiling into the kernel.
-
Knoppix1337
I think it's as curaga said:
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.
I'm not sure where to go from here.
Just my opinion, but unless you have some compelling reason to
move to TC16, you might want to consider sticking with TC15 if
it works on your system.
-
However, there is an issue with FLWM in this mode that the title bar does not grow to show the fully-scaled font and the window sizing buttons disappear, which I think @Juanito has noted before.
That was referring to enlarging a window by dragging - prior to the patch to flwm, enlarging a window in flwm_topside would result in the window border and buttons disappearing, which was fixed by the patch.
Yes, if I have Xft.dpi at the default resolution of 96.0 dots per inch, the titlebars look fine and the window size buttons are visible. I've also discovered that the Ctrl+"Plus" really means you need to use the shift key to get the "+" character (Ctrl + Shift + "+") to make the windows grow, and it is perfectly capable of growing above 100%. However, the window title bar and buttons do not scale with the other FLTK GUI elements inside the window, either smaller or larger. Maybe this is OK if the Xft.dpi setting in the .Xdefaults file was honored by FLWM for the window frame & decoration.
I must say, the scaled-up text for scaled-up button labels, etc. looks quite nice and smooth. The ControlPanel app is scaled to 200% in this screen shot and Fluff at 150% I think.
.
-
Some users are reporting that firmware will not load from /usr/local/lib/firmware - has anybody else seen this problem?
Is it something like this?
Got the following message when booting my HP 2133, took a picture, but it was too large, so I used an on-line jpeg to ocr converter
Core is distributed with ABSOLUTELY NO WARRANTY. www.tinycorelinux.net
tc@box:'$ tg3 0000:07:03.0: Direct firmware load for tigon/tg3_tso5.bin failed with error -2
tg3 0000:07:03.0: Falling back to sysfs fallback for: tigon/tg3_tso5.bin
tg3 0000:07:03.0 eth0: Failed to load firmware "tigon/taJso5.bin"
tg3 0000:07:03.0 eth0: TSO capability disabled
Let me know if you need me to try anything on this machine.
-
Some users are reporting that firmware will not load from /usr/local/lib/firmware - has anybody else seen this problem?
To use my built-in Intel WiFi adapter in my ThinkPad, I'm using the firmware-iwlwifi extension without issue. Running on WiFi at the moment, actually!
--
Mike
ccm 16384 6 - Live 0x0000000000000000
cpufreq_conservative 12288 0 - Live 0x0000000000000000
cpufreq_powersave 12288 0 - Live 0x0000000000000000
cpufreq_userspace 12288 0 - Live 0x0000000000000000
snd_hda_codec_hdmi 49152 1 - Live 0x0000000000000000
iwlmvm 319488 0 - Live 0x0000000000000000
mac80211 425984 1 iwlmvm, Live 0x0000000000000000
i915 2289664 4 - Live 0x0000000000000000
joydev 20480 0 - Live 0x0000000000000000
drm_display_helper 114688 1 i915, Live 0x0000000000000000
iwlwifi 253952 1 iwlmvm, Live 0x0000000000000000
drm_kms_helper 102400 2 i915,drm_display_helper, Live 0x0000000000000000
thinkpad_acpi 81920 0 - Live 0x0000000000000000
sparse_keymap 12288 1 thinkpad_acpi, Live 0x0000000000000000
intel_gtt 16384 1 i915, Live 0x0000000000000000
snd_ctl_led 20480 0 - Live 0x0000000000000000
cfg80211 303104 3 iwlmvm,mac80211,iwlwifi, Live 0x0000000000000000
snd_hda_codec_realtek 118784 1 - Live 0x0000000000000000
snd_hda_scodec_component 12288 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_hda_codec_generic 57344 1 snd_hda_codec_realtek, Live 0x0000000000000000
platform_profile 12288 1 thinkpad_acpi, Live 0x0000000000000000
snd_hda_intel 28672 0 - Live 0x0000000000000000
snd_hda_codec 81920 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000
ttm 49152 1 i915, Live 0x0000000000000000
agpgart 28672 2 intel_gtt,ttm, Live 0x0000000000000000
drm_buddy 16384 1 i915, Live 0x0000000000000000
drm 348160 8 i915,drm_display_helper,drm_kms_helper,thinkpad_acpi,ttm,drm_buddy, Live 0x0000000000000000
snd_hda_core 49152 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
snd_hwdep 12288 1 snd_hda_codec, Live 0x0000000000000000
snd_intel_dspcfg 12288 1 snd_hda_intel, Live 0x0000000000000000
i2c_i801 24576 0 - Live 0x0000000000000000
i2c_smbus 12288 1 i2c_i801, Live 0x0000000000000000
snd_pcm 86016 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core, Live 0x0000000000000000
snd_timer 24576 1 snd_pcm, Live 0x0000000000000000
snd 65536 10 snd_hda_codec_hdmi,thinkpad_acpi,snd_ctl_led,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer, Live 0x0000000000000000
soundcore 12288 2 snd_ctl_led,snd, Live 0x0000000000000000
cec 36864 2 i915,drm_display_helper, Live 0x0000000000000000
rtsx_pci_sdmmc 20480 0 - Live 0x0000000000000000
mmc_core 110592 1 rtsx_pci_sdmmc, Live 0x0000000000000000
mei_hdcp 12288 0 - Live 0x0000000000000000
think_lmi 24576 0 - Live 0x0000000000000000
wmi_bmof 12288 0 - Live 0x0000000000000000
firmware_attributes_class 12288 1 think_lmi, Live 0x0000000000000000
squashfs 40960 210 - Live 0x0000000000000000
pcspkr 12288 0 - Live 0x0000000000000000
xhci_pci 16384 0 - Live 0x0000000000000000
e1000e 167936 0 - Live 0x0000000000000000
rtsx_pci 61440 1 rtsx_pci_sdmmc, Live 0x0000000000000000
ac 12288 0 - Live 0x0000000000000000
xhci_hcd 114688 1 xhci_pci, Live 0x0000000000000000
mei_me 24576 1 - Live 0x0000000000000000
mei 69632 3 mei_hdcp,mei_me, Live 0x0000000000000000
battery 16384 1 thinkpad_acpi, Live 0x0000000000000000
video 57344 2 i915,thinkpad_acpi, Live 0x0000000000000000
backlight 12288 5 i915,drm_display_helper,thinkpad_acpi,drm,video, Live 0x0000000000000000
loop 24576 420 - Live 0x0000000000000000
lpc_ich 24576 0 - Live 0x0000000000000000
wmi 16384 3 think_lmi,wmi_bmof,video, Live 0x0000000000000000
intel_smartconnect 12288 0 - Live 0x0000000000000000
-
Hi Knoppix1337
Is it something like this? ...
Yes, but typically it should find it after the firmware extension is
loaded, firmware-tigon.tcz in your case.
-
Yes, if I have Xft.dpi at the default resolution of 96.0 dots per inch, the titlebars look fine and the window size buttons are visible. I've also discovered that the Ctrl+"Plus" really means you need to use the shift key to get the "+" character (Ctrl + Shift + "+") to make the windows grow, and it is perfectly capable of growing above 100%. However, the window title bar and buttons do not scale with the other FLTK GUI elements inside the window, either smaller or larger. Maybe this is OK if the Xft.dpi setting in the .Xdefaults file was honored by FLWM for the window frame & decoration.
I must say, the scaled-up text for scaled-up button labels, etc. looks quite nice and smooth. The ControlPanel app is scaled to 200% in this screen shot and Fluff at 150% I think.
Does the scaling require a scalable font defined in flwm/config.h or will it work with a fixed font?
-
flwm/flwm_topside in the tc-16.x x86 repo have been recompiled against the latest fltk-1.3 and the font has been set to the flwm default by un-commenting the following in config.h, which was commented out previously.
#define TITLE_FONT "-*-helvetica-medium-r-normal--*"
-
Using tc-16.x and Xorg-7.7, I can start the gui once, although there is a faint coloured band at the top of the screen, which disappears once the gui is fully started.
If I try to exit to the console prompt I get a blank screen or a screen with a couple of green squares only recoverable by cycling the power.
This is on a dell e7240 laptop using intel haswell hd graphics 4400.
This seems to be a worsening problem with x86, it doesn't happen with x86_64.
Also with x86 the Xorg-7.7-3d/modesetting driver combination will not start, but Xorg-7.7-3d/xf86-video-intel will start, whereas both start with x86_64.
It's my understanding that xf86-video-intel has been depreciated in favour of modesetting.
-
flwm/flwm_topside in the tc-16.x x86 repo have been recompiled against the latest fltk-1.3 and the font has been set to the flwm default by un-commenting the following in config.h, which was commented out previously.
#define TITLE_FONT "-*-helvetica-medium-r-normal--*"
On the x86_64 side, I've been experimenting with adding some fonts. I used the notosans-fonts-ttf.tcz, plus I downloaded and manually installed two other font faces from Google's online font browser & repository... "Roboto" (similar to Lexi Sans and Noto Sans), and "Rancher" which is very stylized. In this screenshot, I built FLWM to use Rancher for the titlebars, and I set the font size to something intentionally overly large to see the letter shapes more clearly. Howdy, partner!
-
Hi MikeLockmoore
Open a terminal and try this under fltk-1.4:
export FLTK_SCALING_FACTOR=1.3
apps
Does that help you with regard to scaling fltk apps?
-
Hi MikeLockmoore
Open a terminal and try this under fltk-1.4:
export FLTK_SCALING_FACTOR=1.3
apps
Does that help you with regard to scaling fltk apps?
That works, and is pretty slick! I think what I'd like to do for FLWM is have it check for that environment variable, and if it is already set to something other than 1.0, use it. If it is not set, or set to 1.0, check the Xft.dpi setting in .Xdefaults, and set that FLTK_SCALING_FACTOR according to the ratio of the Xft.dpi / 96.0 (e.g. 120.0 / 96.0 = 1.25), and scale the titlebar characters according to that ratio too, because the titlebar is not affected by the FLTK-1.4 application scaling. I've not dug in enough to see if I can re-scale the titlebar every time the inner FLTK_SCALING_FACTOR is changed, but at least it could be done once at FLWM startup.
-
Hi MikeLockmoore
... I've not dug in enough to see if I can re-scale the titlebar every time the inner FLTK_SCALING_FACTOR is changed, but at least it could be done once at FLWM startup.
I think FLTK_SCALING_FACTOR needs to be exported before starting
the window manager. ~/.profile seems like the right place to do this.
I'm not aware of any way to change it's exported value after starting
the window manager.
-
Hi Juanito
Using tc-16.x and Xorg-7.7, I can start the gui once, although there is a faint coloured band at the top of the screen, which disappears once the gui is fully started.
If I try to exit to the console prompt I get a blank screen or a screen with a couple of green squares only recoverable by cycling the power. ...
I see a band with 1/4 inch wide vertical stripes across the top of the screen
before the GUI shows up. I can exit to the console prompt and startx starts
the GUI again.
-
After I tried to update xorg-server and it failed to start, I got an interesting explanation from the xorg-server people:
From what I understand, the Xorg's fbdev driver filters out PCI devices, because they have a DRM driver available. It only binds to things like efifb, which is on the platform bus. The actual PCI graphics device has a DRM driver and is supported by Xorg's modeset driver.
Xorg detected this before kernel 6.9, but looked at the wrong place in sysfs. With kernel 6.9 it broke and therefore Xorg's fbdev would bind to PCI devices. That's why it worked. After we fixed Xorg in the cited commit, the filter is back and working as intented. If you revert that commit and go back to a kernel before 6.9, I'm sure it would filter it out either.
So yeah, I'm sure this isn't a bug. If you want fbdev on this hardware, you have to set it manually.
The latest state of play, on my intel haswell hardware at least is:
64-bit without graphics-KERNEL: fbdev doesn't work, but uses xf86-video-vesa
64-bit with graphics-KERNEL: both modesetting and xf86-video-intel work
32-bit without graphics-KERNEL: fbdev doesn't work, but uses xf86-video-vesa - hangs on exit to console prompt
32-bit with graphics-KERNEL: modesetting hangs, xf86-video-intel works