Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: Juanito on September 23, 2020, 01:33:38 AM
-
Team Tiny Core is proud to announce the first beta release of piCore-12.0
For RPi0 and RPi1:
http://tinycorelinux.net/12.x/armv6/test_releases/RPi/piCore-12.0-beta1.zip
For RPi2, RPi3 and RPi4:
http://tinycorelinux.net/12.x/armv7/test_releases/RPi/piCore-12.0-beta1.zip
..and for the first time a 64-bit release for RPi3 and RPi4:
http://tinycorelinux.net/12.x/aarch64/test_releases/RPi/piCore64-12.0-beta1.zip
Note that the 64-bit extension support is limited as everything has to be built from scratch.
Core components
- kernel 5.4.51
- glibc-2.31
- busybox-1.31.1
- gcc-10.1.0
- util-linux-2.35.2
- e2fsprogs-1.45.6
Changes since alpha release:
* init: Avoid awk rounding
* tc-config: Similar awk rounding
* 32-bit kernels rebuilt to fix certificates error
* libstdc++ recompiled for missing futex functions
Please try it out and share your experience, bugs found, etc.
-
Hi
Does it contain Rich's wbar changes?
on the older beta I do not recall seeing a Apps update for wbar.
-
Not that I'm aware of, but perhaps @Rich would be kind enough to do them?
-
Hi Juanito
I'll take care of it. I'll also update the $WM_menu_common scripts in flwm, flwm_topside, and jwm.
-
Is there a way of mounting the image to replace the core and changed files?
(from the alpha release)
-
Yes:
$ tce-load -i util-linux
$ cd /tmp
$ mkdir test image
$ sudo /usr/local/bin/mount -o loop,offset=$((8192*512)) /tmp/test/piCore-12.0-beta1.img /tmp/image
If the offset is not correct, check it with: $ /usr/local/sbin/fdisk -l piCore-12.0-beta1.img
-
xf86-video-dummy added for piCore64 - this will allow remote connections with x11vnc without a screen connected.
The driver does not seem necessary for piCore as the xf86-video-fbturbo driver (which will not compile for piCore64) starts without a screen connected.
-
only trying out aarch64 at this stage, after slight mod of above command I think, because I did not run a script for diff....which may be a mistake, the only file in partition 1 that changes is the rootfs-piCore64-12.0.gz.
on reboot I have version
12.0_beta1
but now when I check apps, it does not report I am on beta. And now I can't remember if it ever reported alpha. Do we agree only one file changed?
-
As far as I know on piCore64, only one file changed, but @paul_123 will be able to confirm.
-
Hi Juanito
... I'll also update the $WM_menu_common scripts in flwm, flwm_topside, and jwm.
Wbar and window managers updated in all TC12 repos.
-
Thanks :)
-
Oh, wow !
New arch "aarch64" :D
Please port these extensions to the repo, they're working properly.
(I copied them from 11.x/x86)
mirrors.tcz
getlocale.tcz
unifont.tcz
submitqc.tcz
P.S. I'm working on openbox for aarch64.
Is there a different location for 'libexec' files ?
IIRC, I've seen some build scripts that specify a different directory.
Many thanks
-
Welcome back :)
Please use /usr/local/lib/appname for libexec so we know where the files came from.
-
getlocale, mirrors, submitqc and unifont copied to aarch64 repo
-
Oh, wow !
New arch "aarch64" :D
Was a bit of an adventure, but a nice step forward.
-
getlocale, mirrors, submitqc and unifont copied to aarch64 repo
Sorry~~ :-[
I've already hacked around the submitqc script and I totally forgot about it.
To make this script works on this platform, it'll need some tinkering.
Please append a new option around line 185.
aarch64) BASELIBS="$BASELIBS ld-linux-aarch64.so.1 linux-vdso.1"; ARCH="aarch64";;
The result should looks like
case "$ARCH" in
x86_64) BASELIBS="$BASELIBS ld-linux-x86-64.so.2 linux-vdso.so.1" ;;
i686) BASELIBS="$BASELIBS ld-linux.so.2 linux-gate.so.1"; ARCH="x86" ;;
x86) BASELIBS="$BASELIBS ld-linux.so.2 linux-gate.so.1" ;;
armv7l) BASELIBS="$BASELIBS ld-linux-armhf.so.3 linux-vdso.1"; ARCH="armv7";;
aarch64) BASELIBS="$BASELIBS ld-linux-aarch64.so.1 linux-vdso.1"; ARCH="aarch64";;
*) echo "$SCRIPT: Unrecognized architecture '$ARCH'. See --help." && exit 1 ;;
esac
BTW, I just finished compiling openbox and sent it to picoresubmit AT gmail DOT com
Working and Tested. (I'm using it right now 8))
Furthermore, the openbox-config.tcz on x86_64 can be copied without tweaks as well.
Please port it over. ;)
Please use /usr/local/lib/appname for libexec so we know where the files came from.
Noted :)
./configure --prefix=/usr/local --libexecdir=/usr/local/lib/openbox
Cheers ;D
-
Please submit the submitqc changes as a patch and any piCore extensions to the standard email address - nobody knows the password to the piCore email address..
-
Please submit the submitqc changes as a patch and any piCore extensions to the standard email address - nobody knows the password to the piCore email address..
Extensions re-emailed to tcesubmit AT gmail DOT com
Along with the submitqc patch file.
Many thanks
-
posted - thanks :)
-
Hi, wrong dep file for util-linux-python.tcz
There's no python.tcz in this arch, only python2.7.tcz or python3.8.tcz
I believe it should be python2.7.tcz
-
From the contents of util-linux-python.tcz.list, it looks like it should be python3.8?
-
From the contents of util-linux-python.tcz.list, it looks like it should be python3.8?
tc@box:~$ find /tmp/tcloop/util-linux-python -not -type d -exec file {} +
/tmp/tcloop/util-linux-python/usr/local/lib/python3.8/site-packages/libmount/__init__.py: Python script, ASCII text executable
/tmp/tcloop/util-linux-python/usr/local/lib/python3.8/site-packages/libmount/__pycache__/__init__.cpython-38.opt-1.pyc: python 3.8 byte-compiled
/tmp/tcloop/util-linux-python/usr/local/lib/python3.8/site-packages/libmount/__pycache__/__init__.cpython-38.pyc: python 3.8 byte-compiled
/tmp/tcloop/util-linux-python/usr/local/lib/python3.8/site-packages/libmount/pylibmount.la: libtool library file, ASCII text
/tmp/tcloop/util-linux-python/usr/local/lib/python3.8/site-packages/libmount/pylibmount.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, stripped
Yep, you're right. :)
Furthermore, pylibmount.so depends on libmount.so.1
So the dep file should look like
python3.8.tcz
util-linux.tcz
-
dep file adjusted - thanks for reporting this.
-
Missing applet busybox groups used in openssh.tcz extension.
-
I see that the openssh init.d script calls busybox groups, which is no longer present in piCore, but is it actually needed - openssh works for me without that command being present?
In piCore: $ cat /tmp/tcloop/openssh/usr/local/etc/init.d/openssh
#!/bin/sh
# openssh sshd start script
[ $(id -u) = 0 ] || { echo "must be root" ; exit 1; }
start(){
busybox groups sshd >/dev/null 2>&1
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
busybox id sshd >/dev/null 2>&1
[ $? -ne 0 ] && busybox adduser -D -H -G sshd -u 33 -s /dev/null sshd
[ -d /var/empty ] || mkdir /var/empty
[ -f /usr/local/etc/ssh ] || mkdir -p /usr/local/etc/ssh
[ -f /usr/local/etc/ssh/sshd_config ] || cp /usr/local/etc/ssh/sshd_config.example /usr/local/etc/ssh/sshd_config
..whereas in x86: $ cat /tmp/tcloop/openssh/usr/local/etc/init.d/openssh
#!/bin/sh
# openssh sshd start script
[ $(id -u) = 0 ] || { echo "must be root" ; exit 1; }
start(){
[ -f /usr/local/etc/ssh/sshd_config ] || { echo "config file /usr/local/etc/ssh/sshd_config not found"; exit 1; }
There shouldn't be a need for any groups apart from root and staff?
-
Yes, openssh works, but if you do backup (filetool.sh -b), in the next boots a message appears (not harmful) about user sshd already exists, because the addgroup is executed.
Perhaps the best would be to adapt the script to x86 style.
-
Hi Juanito
... openssh works for me without that command being present? ...
It works because the addgroup command is probably present:
--- Snip ---
# This fails with "applet not found"
busybox groups sshd >/dev/null 2>&1
# This detects a failure and assumes group sshd does not exist, so it adds it.
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
--- Snip ---
-
init.d adjusted
-
init.d adjusted
But now, if the sshd user does not exist (initial/pristine situation) occurs error:
Privilege separation user sshd not exist
and sshd does not run.
-
Hi Juanito
Another way to test if group sshd exists.
Change this:
busybox groups sshd >/dev/null 2>&1
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
To this:
touch /tmp/groups
chown tc:sshd /tmp/groups >/dev/null 2>&1
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
-
Hi Juanito
Another way to test if group sshd exists.
Change this:
busybox groups sshd >/dev/null 2>&1
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
To this:
touch /tmp/groups
chown tc:sshd /tmp/groups >/dev/null 2>&1
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
Or just change to
grep -q sshd /etc/group
[ $? -ne 0 ] && busybox addgroup -g 33 sshd
-
Hi mortegai
If you are going to do that, search for an exact match:
grep -q '^sshd:' /etc/group
-
But now, if the sshd user does not exist (initial/pristine situation) occurs error:
Privilege separation user sshd not exist
and sshd does not run.
sshd ran on startup for me in testing using the modified openssh init.d script, but I presume now that was influenced by the backup.
I don't know of a reason why an additional user named sshd would be necessary for sshd to work on piCore - things work on Core/CorePure64 without it.
I will have access to a screen in a couple of days time to be able to troubleshoot.
-
Hi Juanito
Seems this already came up in piCore-12.0alpha1:
http://forum.tinycorelinux.net/index.php/topic,24196.msg153179.html#msg153179
-
If you could interpret anything he said..... lol.
groups sshd was a carry over from piCore 11 (and possibly 10) Its just that Juanito and I were trying to commonize configs between x86_64 and piCore. We started with busybox, which is why "groups" got dropped and highlighted this issue.
We just have to figure out right solution.....without doing a big re-invention.
-
Openssh issue caused from confusion from x86_64, and different folks building things.
I've updated armv6/7 and aarch64 to openssh8.4p1 and commonized the privilege separation configuration with x86_64, which uses the user "nobody" as the non-privileged user. nobody is supplied as a standard user in the piCore image, so no need to check anything anymore.
-
I'd like to remind all users here to fix, recreate and backup the file.
/usr/local/etc/ssh/sshd_config
The new openssh extension is recompiled with a different libexecdir.
At line 108, 109 we have
# override default of no subsystems
Subsystem sftp /usr/local/libexec/sftp-server
Replace that with the new route
Subsystem sftp /usr/local/lib/openssh/sftp-server
That should fix any quirky ftp functions / behaviors.
-
Hi, a quick report. :)
Please append gnutls.tcz to vte.tcz.dep (12.x/aarch64)
vte won't run without it.
-
vte* deps adjusted - thanks for reporting this.