Recent Posts

91

TCB Tips & Tricks / Re: advdef ver.2.1 versus 7z ver.26

« Last post by Paul_123 on March 13, 2026, 08:36:06 PM »

I know its for fun..  So I'll play the game with you

This is a different rootfs than you, but the results you can see.

Code: [Select]

-rw-r--r-- 1 paul paul 12633088 Mar 13 19:46 rootfs-piCore64-17.0.uncompressed
-rw-r--r-- 1 paul paul  4466798 Mar 13 19:42 rootfs-piCore64-17.0.gzip9
-rw-rw-r-- 1 paul paul  4246873 Mar 13 19:49 rootfs-piCore64-17.0.gz.advdevz4
-rw-rw-r-- 1 paul paul  4235095 Mar 13 19:50 rootfs-piCore64-17.0.gz.7zmx9
-rw-r--r-- 1 paul paul  4206895 Mar 13 19:42 rootfs-piCore64-17.0.pigz.zopfli.noiterations
-rw-r--r-- 1 paul paul  4205410 Mar 13 19:42 rootfs-piCore64-17.0.pigz.zopfli.I100
-rw-r--r-- 1 paul paul  4006378 Mar 13 19:42 rootfs-piCore64-17.0.zst-10
-rw-r--r-- 1 paul paul  3458360 Mar 13 19:42 rootfs-piCore64-17.0.zst-19
-rw-r--r-- 1 paul paul  3030460 Mar 13 19:42 rootfs-piCore64-17.0.xz-6

decompression

Code: [Select]

gzip9:   mesreal 0m0.078s
advdef:      real 0m0.075s
7zmx9:      real 0m0.085s
pigzzopfli:  real 0m0.075s
pigzzopfli100: real 0m0.091s
zstd-10:     real 0m0.035s
zstd-19:     real 0m0.028s
xz:             real 0m0.154s
So XZ gets it the smallest, but does take more to decompress it.  zstd is probably the winner.   But lets see.

This is the boot of a Raspi5,

I pulled some relevant lines from dmesg.
this rootfs was produced with pigz

Code: [Select]

[    0.031569] Trying to unpack rootfs image as initramfs...
[    0.102147] Freeing initrd memory: 5664K
[    0.630088] Run /init as init process

This is the zstd compressed rootfs

Code: [Select]

[    0.038710] Trying to unpack rootfs image as initramfs...
[    0.080141] Freeing initrd memory: 5424K
[    0.633339] Run /init as init process


hmmmm, I might switch piCore to zstd.  Need to do more testing.

92

TCB Tips & Tricks / Re: advdef ver.2.1 versus 7z ver.26

« Last post by nick65go on March 13, 2026, 07:28:25 PM »

1 . One of your stated goals was trying to exactly produce the distributed initrd.gz file, which I was trying to help you understand was impossible.
2. If your definition of better is the compressed size of the initrd, then why not use xz or zstd to compress the image.
3. If your definition of better is boot time, did you try a uncompressed initrd, or just a gzip -1 compressed file.

1. I try to understand first, then maybe to improve TC17. There are NO clear instructions how to reproduce rootfs.gz. If it can not be reproduced then so be it. Survive but not happy.
2. I try to use tools from TC17 to re-build TC17 (learning it). Maybe re-master it to boot in 40 MB RAM just for fun. The smaller is + on demand then the better, for me. Or else there are TC3,x until TC10, plenty to choose from. My current linux has XZ in kernel + packages (is Archlinux derivative named CachyOS x86-64-v3).
3. Boot time is secondary, 3-5 seconds wasted to boot did not matter in a full day.
PS: I assume you understand that all is play/ fun, pushing the limits. Someone can grab a linux (Fedora, OpenSuse, Debian, Ubuntu, whatever) in minutes! and install it also in few minutes with default settings. And a PC (even a Chrome OS) someone can buy new (lasting 3-8 years), with money earned from few days of work (I hope) ...

93

TCB Bugs / not used functions from tc-functions

« Last post by nick65go on March 13, 2026, 06:58:29 PM »

in TC17 32 bits, from rootfs.gz, in /etc/init.d/tc-functions:
the functions merge(), replace(), purge() use the commands index() and getline. but I think they are not functional because they are not internal into ash, neither applets from busybox. Also /bin/which did not find them.
I tested by: I booted in GUI from qemu, and opened aterm then sourced /etc/init.d/tc-functions.

94

Raspberry Pi / Re: Apache Guacamole working poorly

« Last post by MrPorcine on March 13, 2026, 05:16:39 PM »

I've done some more work exploring this problem, but Guacamole is still not working well. When I first attach to Guacamole, response is good for maybe 10 seconds, then whenever the screen changes dramically Guacamole disconnects and the client has to reconnect. The grace period only works for the first client after a boot on the server.

The available schedulers on the server are "none [mq-deadline] kyber bfq". I've tried them all, none fix the problem. mq-deadline is the default.

I've substuted a faster SD card, no change.
I've tried a pi 4 in place of the pi 3, no change in Guacamole. In general, the Pi 4 makes the UI snappier. It could be that with a Pi 4 I get a longer grace period before the first disconnect. I can't think of a reason where the problem is independant of processor speed.

I've tried different clients, so far Brave and Chromium. Using a very fast client makes no difference.

95

Raspberry Pi / Re: failed in wait for X piCore16.0 on Raspi2,3,4 and 5

« Last post by MrPorcine on March 13, 2026, 04:42:41 PM »

I use X without a display manager as well. Here is how I start up my app (dviii_m)

Code: [Select]

#wait for framebuffer
Timeout=0
while [ $Timeout -lt 40 ] ; do
[ -c /dev/fb0 ] && break
Timeout=$(($Timeout + 1 ))
sleep 0.25
done
export DISPLAY=":0.0"
/usr/local/bin/Xorg -retro -s 0 vt07 &
sleep 2
/opt/DynaViewIII/bin/dviii_m /dev/ttyAMA0 &>/opt/dviii.log &
X takes a while to start up, I have to use the sleep command to make sure it's ready. I've used

Code: [Select]

/usr/local/bin/startx /opt/DynaViewIII/bin/dviii_m /dev/ttyAMA0 -- -retro -s 0 vt07
And it sometimes works.
This script is run in the init process, so everything is as root. It works on a pi 3 and pi 4, I don't know about others.

96

TCB Tips & Tricks / Re: advdef ver.2.1 versus 7z ver.26

« Last post by Paul_123 on March 13, 2026, 04:34:12 PM »

One of your stated goals was trying to exactly produce the distributed initrd.gz file, which I was trying to help you understand was impossible.

If your definition of better is the compressed size of the initrd, then why not use xz or zstd to compress the image.
If your definition of better is boot time, did you try a uncompressed initrd, or just a gzip -1 compressed file.

97

TCB Talk / Re: Installing on a Tatung TWN-5213 CU

« Last post by peasthope on March 13, 2026, 03:56:21 PM »

P.s. Pictorial evidence of anitX.
https://commons.wikimedia.org/wiki/File:AntiXonTatung5213.jpg

98

TCB Talk / Re: Installing on a Tatung TWN-5213 CU

« Last post by peasthope on March 13, 2026, 03:28:35 PM »

Rich & all,

Since you have a working network connection, you should be able
to install  tc-install-GUI.tcz.

Yes, QEMU provides a network connection.  No specific command line parameter needed.

Either click on the Apps icon or open a terminal and enter:

Code: [Select]

tce-load -wil tc-install-GUI

cd /mnt/A/ ; ls -ld Tiny*iso 
# Yes, the image exists.
DISPLAY=:0.0 gparted /dev/sdf  # Format the part to avert automount.
DISPLAY=:0.0 qemu-system-i386 -m 2G -cdrom TinyCore17.0.iso \
 -serial file:CorePlusTrace -drive file=/dev/sdf,media=disk,format=raw -boot order=d

# In the guest system, open a terminal and execute.
tce-load -wil tc-install-GUI
# tce-load completed successfully.
# Click installer icon to activate installer.
# Complete the installation.  No problem evident.
# Put the CF card in the Tatung TWN-5213 CU and power up.

# This appears on the screen.

No EFI environment detected.
early console in extract_kernel
input_data: 0x00880094
input_len: 0x005be8f3
output: 0x00100000
output_len: 0x00c7c720
kernel_total_size: 0x00d5d000
needed_size: 0x00d5d000
Decompressing Linux... Parsing ELF... No relocation needed... done.
Booting the kernel (entry_offset: 0x00b072d0).
ACPI BIOS Error (bug): A valid RSDP was not found (20250807tbxfroot-222)

A problem with ACPI?  Therefore try again.  During installation set bootcode "acpi=off".
The result is exactly the same except that the last line is absent.
Some other error blocks further progress?  No helpful message.  =8~/

Ideas?

Thanks,                      ... P.

99

TCB Tips & Tricks / Re: advdef ver.2.1 versus 7z ver.26

« Last post by nick65go on March 13, 2026, 02:50:45 PM »

Lets do not confuse sha256sum with file size in Bytes. Reproducibility depends also of file calendar data (EPOCH). So please publish your results of using better tools (pipz) to make rootfs.cpio.gz.

Now back in bussiness/ topic of advdef: After I read wiki about deflate64 (advdef) versus deflate (gzip), it seams is about dictionary (32KB -> 64 KB) but also about length of strings in the window/range chunks to compress. So I have the idea to pre-sort (the extracted rootfs.gz), files with smaller size are first in the list send to cpio. My results below, using 7zip on sort(x0.cpio) and not-sorted cpio (123.gz), then advdef on x1.cpio (pre-sorted) or x2.cpio (not-sorted)

Code: [Select]

sudo find -type f -printf '%s %p\n' | sort -n | cut -f2 -d" " | sudo cpio -o -H newc > ../x1.cpio
18057 blocks 
#normal un-sorted cpio
 sudo find | sudo cpio -o -H newc > ../x2.cpio 
18182 blocks
> ls -alB ../x*
.rw-r--r-- 9.245.184 abc 13 Mär 19:16  ../x1.cpio
.rw-r--r-- 9.309.184 abc 13 Mär 19:16  ../x2.cpio

Code: [Select]

> gzip -1 x1.cpio
> gzip -1 x2.cpio
> ls -alB ./x*.gz
.rw-r--r-- 3.677.872 abc 13 Mär 19:20  ./x0.gz
.rw-r--r-- 4.218.542 abc 13 Mär 19:16  ./x1.cpio.gz
.rw-r--r-- 4.230.975 abc 13 Mär 19:16  ./x2.cpio.gz

Code: [Select]

> ./advdef -z4 x1.cpio.gz
     4218542     3695808  87% x1.cpio.gz
     4218542     3695808  87%

> ./advdef -z4 x2.cpio.gz
     4230975     3701897  87% x2.cpio.gz
     4230975     3701897  87%

> ls -alB ./x*.gz
.rw-r--r-- 3.677.872 abc 13 Mär 19:20  ./x0.gz       ; 7zip of sorted X0.cpio
.rw-r--r-- 3.695.808 abc 13 Mär 19:25  ./x1.cpio.gz  ; advdef of x1.cpio (pre-sorted)
.rw-r--r-- 3.701.897 abc 13 Mär 19:26  ./x2.cpio.gz  ; advdef of x2.cpio not-sortedso with pre-sorted x0.cpio I obtained with 7z even a better rootfs.gz , than initial reported

Code: [Select]

.rw-r--r--  3.684.655 abc 13 Mär 11:55  123.gzsummary: best in class solution (until now): 7z ver.26 with per-sorted cpio archive.

100

TCB Tips & Tricks / Re: advdef ver.2.1 versus 7z ver.26

« Last post by Paul_123 on March 13, 2026, 01:23:17 PM »

1. Really? this is "disturbing", that using same original compression program offered by TC and the same input original TC data, for a single-threaded advdef you said I can not obtain the same result.

Just unpacking the cpio archive, then repacking it changes it.  Even if you do not change the content.   Take compression out of the equation.

Decompress the initrd, now you have an uncompressed cpio archive.  Now run a sha256sum for that initrd.

extract the archive through cpio......then recreate it, but don't pass it through gzip.   Now run the sha256sum again.   I would expect different checksums.