piCore16 Beta

[Paul_123]

Team Tiny Core is happy to announce the beta release of piCore-16.0.  Both 32 and 64bit images are ready for download/testing.

Changelog for 16.0 beta1 (Since the Alpha1 release):
* rpi-kernel 6.12.25

* Fixed backup errors due to no DSA keys from openssh
* Removed Old module config file for 8192 driver.
* Update module config for rpi wireless (brcmfmac)


Changelog for 16.0 alpha1:
* rpi-kernel 6.12.15
* 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
* Micropython updated to 1.24.1
* OpenSSL updated to 3.4.1
* OpenSSH updated to 9.9p2
* CoreScripts updated to latest in git.

* Fix udev rules for proper serial console configuration.

32bit - http://www.tinycorelinux.net/16.x/armhf/release_candidates/RPi/piCore-16.0.0-beta1.img.gz  (This should run on all rpi boards)
         - sha256: 92efe99b4e821a6a0c469b119db520d1e9347b04ad8c7f586614085ea7d25dd6  piCore-16.0.0-beta1.img.gz

64bit - http://www.tinycorelinux.net/16.x/aarch64/release_candidates/RPi/piCore64-16.0.0-beta1.img.gz  (rpi zero2W, pi3, pi4, pi5)
         - sha256: 51018e946d82f923af2b06df6fa6b9ceac1b5824be2f59964e2e0cb1601b2478  piCore64-16.0.0-beta1.img.gz

Note: Image files are now just gzipped, you can just zcat the image if using dd to write your image, or some imaging tools support writing compressed images.
Note:  When using 32bit images, the pi4 and pi5 will use a 64bit kernel.  please make sure to look at uname if manually downloading kernel module extensions.

[Juanito]

Both piCore (on an RPi3) and piCore64 (on an RPi5) seem to work OK for me 

[uli]

Thanks, works very well, indeed - on Raspi Zero W.
Though there might possibly be some inconsistency with extension names imlib2 vs. imlib2-bin. The latter seems to be used in Xprogs dependencies, but cannot be found in the repository.

[Rich]

Hi uli
That's because in aarch64, the /usr/local/bin/ files were separated
from the imlib2.tcz extension, and in armhf they weren't.

[Rich]

Hi uli
Xprogs.tcz.dep updated in the TC16 armhf repository.

[mortegai]

Updated piCore64 to 16.x from 15.x on RPi4
Updated existing extensions.
Everything works correctly, except that exittc (TC Exit Options) defaults to Safe when I have the BACKUP="0" environment variable set.

[Rich]

Hi mortegai
I see the issue. Will submit a fix.

[Rich]

Hi mortegai
I've moved this particular issue to its own thread:
https://forum.tinycorelinux.net/index.php/topic,27643.0.html

I'm asking for anyone with C++ experience to please take a
look and provide me with some guidance.

[mung]

I have not looked at the beta yet but had a quick look at the alpha.

I may checkout the beta, I had quite a few problems with the alpha but cannot remember in detail  exactly what now, but main thing I thought was why was the extension partition so small??

I resized it, but it should not be necessary, and also it was not any size that made up a usual SD card size (i.e. 64m, 128m, 256m, ....) could have added another 32m to the partition and it been within the 128mb of SD card multiple. That would just make it simpler to add the few extra tcz that I need.
 
Which is another annoyance I have about a seperate extensions partition, why have it?

Why not just put the extensions on the main fat boot filesystem?

I know maybe there are reasons for security or file access speed etc, but it would be nice to have a 'standard' for dropping tcz packages into the windows accessable boot partition. I normally create a 'packages' directory and have a script to check.

Is there some reason it has not been standardised?

I had some problems with wifi setup as an access point I think maybe because configfs was not mounted module would not load or something like that, I did not sort it but if I look at the beta maybe will post details.

I think there were also some errors about invalid ELF headers in dmesg output whcih maybe due to some special kernel modules I compiled or could be busybox as I had to compile that for some extra tools required.

I suppose what I say is not much use as rather vague, but when I check out the beta I may give details if I have problems.

Main thing I think could be changed from the alpha is the partition size or add a simple tool to resize it.

[patrikg]

Take a look at Alpine Linux I think you have only one big FAT partition for Rasberry Pi.

[mung]

Take a look at Alpine Linux I think you have only one big FAT partition for Rasberry Pi.

I think alpine is musl based, so probably makes more problem with cross compile rather than devrelop simple rasbian compile and copy to tinycore??

Not sure if it is a good strategy to direct your possible users to other dists, or maybe I am just a trouble maker :lol

[Paul_123]

Partitions are kept small for distribution and imaging.  I increased them once, and users complained, so I put them back.

The second partition is because fat cannot be easily resized.  You can easily create a single partition image, if that is what you want. 

Don’t use windows and none of this is a problem.

[Rich]

Hi mung

... but main thing I thought was why was the extension partition so small?? ...

So that the image file will fit on as many different devices as possible.

... I resized it, but it should not be necessary, and also it was not any size that made up a usual SD card size (i.e. 64m, 128m, 256m, ....) could have added another 32m to the partition and it been within the 128mb of SD card multiple. ...

When you dd the image onto a device you overwrite the partition table, effectively
destroying any previous contents and creating a dedicated piCore device. At that
point it makes sense to expand the partition to fill the device.

... That would just make it simpler to add the few extra tcz that I need. ...

Design decisions are made with the majority of users in mind, not individuals.
 

... Which is another annoyance I have about a seperate extensions partition, why have it? ...

After you boot, that partition is no longer used and gets unmounted.

... Why not just put the extensions on the main fat boot filesystem? ...

Persistent  /home  and  /opt  directories are also an option. Most likely they
would be placed alongside the  /tce  directory.  /home  and  /opt  should be
on an  ext  file system to preserve ownership and permission attributes.

... I know maybe there are reasons for security or file access speed etc, but it would be nice to have a 'standard' for dropping tcz packages into the windows accessable boot partition. I normally create a 'packages' directory and have a script to check. ...

I think the whole point of Tinycore (piCore) has always been to provide a
bootable environment that then allows you to tailor the system to your needs.
Coreplus attempts to provide required extensions for establishing a wireless
connection for x86 based systems. I believe piCore does something similar. At
that point you can install additional extensions. Once you have it running, you
can use that system to "create a 'packages' directory and have a script to check."
for any future systems.

[Rich]

Hi Juanito

... Everything works correctly, except that exittc (TC Exit Options) defaults to Safe when I have the BACKUP="0" environment variable set.

This issue has been fixed and the git master updated. Only apps and exittc were affected.
Though problem was originally reported here, I did see the same behavior on TC16 x86_64.

Could you please update Xprogs when you have a chance?
Thank you.

[mortegai]

Updated Xprogs.
"exittc" now works correctly.
Thanks everyone.