Recent Posts

41

General TC Talk / Re: Building Another Logger

« Last post by MTCAT on January 23, 2026, 07:38:17 PM »

Hi Rich,

Here's a screen-shot of the output of "sudo fdisk -l" from the fully functioning "BASE" receiver,


sorry I've forgotten how to insert the image directly in the text of the post.

Thanks,

David

    [Edit]: Placed image inline.  Rich

42

General TC Talk / Re: Building Another Logger

« Last post by MTCAT on January 23, 2026, 07:18:26 PM »

Hi Rich,

Forgot to say, the output of "lsblk -f" above is in Lubuntu with only the 128 GB CF-card plugged in.

Thanks,

David

43

General TC Talk / Re: Building Another Logger

« Last post by MTCAT on January 23, 2026, 07:16:15 PM »

Hi Rich,

I found a problem, that I totally forgot about, in October, 2021, you helped me re-size partitions on the 128 GB CF-card, with gparted.

Right now, as per Oct, 2021, the CF-card is formatted as shown below, so I'm only "seeing" 6 GB as usable space for saving data from the acquisition program.

I have to read more carefully through the extensive posts from Oct, 2021 (in thread TC3.8_4 Real Time Upgrade), but a quick look seems like I ended up deleting the "swap" partition completely and then was able to resize sda5 to almost 120 GB (deleted sda2 as well?, not sure yet).

Not sure if that's maybe the cause of the TinyCore boot up not working, but certainly isn't helping, here's what the output of "lsblk -f" looks like in Lubuntu.

Code: [Select]

Device          Boot       Start          End        Sectors      Size     Id              Type
/dev/sda1       *          2048      2088959   2086912   1019M   82    Linux Swap / Solaris
/dev/sda2                2091006   14678015  12587010    6G       5           Extended
/dev/sda5                2091008   14678015  12587008    6G      83             Linux
Thanks,

David

    [Edit]: Added code tags.  Rich

44

General TC Talk / Re: Building Another Logger

« Last post by Rich on January 23, 2026, 05:31:26 PM »

Hi MTCAT

UUIDs are unique for each device. ...

Assuming they were created by formatting, or
maybe it occurs when partitions get created, I
forget.

If you clone one device to another, the UUIDs
get cloned too. Using the  dd  command to copy
one device to another is an example of how that
could occur.

45

General TC Talk / Re: Building Another Logger

« Last post by MTCAT on January 23, 2026, 05:23:22 PM »

Hi Rich,

Thanks for the help, I was wrong, surprise, surprise  , there isn't a problem with the UUID in extlinux.conf for the new build "ROVER" receiver.

I plugged in the cloned TC boot pen drive (for the ROVER) in Lubuntu and typed "lsblk -f" and saw that the UUID for the cloned TC boot pen drive is the same UUID that's in the extlinux.conf, so that's good.

So then I also turned on my existing "BASE" station system, the fully functioning receiver, that boots properly and runs the acquisition program just fine, I checked on the UUID of the CF-card on the "BASE" receiver by typing "blkid /dev/sda5" and it's the same as the UUID of the new "ROVER" CF-card that I checked on in Lubuntu (the UUID for the boot pen drive is also the same on both systems).

So it seems like it's not a problem with UUID's, but does it seem strange that two different CF-cards in two different computers have the same UUID?, unless it's because both CF-cards were copied/created from the same Lubuntu image file?

Again, the 128 GB CF-card in the BASE receiver (the fully functioning one) and the CF-card in the new "ROVER" receiver (the one I'm trying to get going) have the same UUID.

In the "BASE" receiver the boot pen drive is mounted as sdb1 and the CF-card as sda5.

The only other thing I don't recall yet is how you helped me make a symbolic link on the CF-card so that acquisition data gets saved to home/tc/data, could that be hanging the boot up process? I need to check my piles of chicken scratches called notes how you helped me do that!

Thanks,

David

46

General TC Talk / Re: Building Another Logger

« Last post by Rich on January 23, 2026, 04:33:23 PM »

Hi MTCAT
UUIDs are unique for each device. Once you know the device
name of the drive, you can run lsblk against it for its UUIDs.
You may need to use  sudo  for this. Here's what happens
on Tinycore with and without sudo ...

without sudo:

Code: [Select]

tc@E310:~$ lsblk -f /dev/sda
NAME   FSTYPE LABEL UUID MOUNTPOINT
sda                     
|-sda1                   /mnt/sda1
|-sda2                   
|-sda3                   
|-sda4                   
|-sda5                   [SWAP]
|-sda6                   
`-sda7
with sudo:

Code: [Select]

tc@E310:~$ sudo lsblk -f /dev/sda
NAME   FSTYPE LABEL       UUID                                 MOUNTPOINT
sda                                                           
|-sda1 ext4   TC10        543cac60-3224-4cab-b1d5-008407dd9ce8 /mnt/sda1
|-sda2 ext4   TC10_backup 22559ae7-7e12-4a3b-9efa-6f8c8a9a8a6a
|-sda3 ext4               bedfc958-a562-4225-ad9d-cf150e7cdb4e
|-sda4                                                         
|-sda5 swap   Swap        81c9827f-5952-4bb2-b1b2-298be789abee [SWAP]
|-sda6 ext4               7b839431-514c-44a7-a1d3-9baeffb595e0
`-sda7 ext4               f4d4b4d3-5869-492a-bf56-25a2970dc432

47

Raspberry Pi / Re: Rust on piCore: Computing π to 10,000 digits

« Last post by Rich on January 23, 2026, 04:17:36 PM »

Hi patrikg
The first 337 characters from your command match the result
posted in reply #5 perfectly.

48

General TC Talk / Re: Building Another Logger

« Last post by MTCAT on January 23, 2026, 04:11:55 PM »

Hello again everyone,

As per the original install, I copied the compressed Lubuntu 16.04 image file onto the 128 GB CF-card with HDDRawCopy, with Lubuntu booted up, I did a bit of poking around to find the address of the 100 MBit ethernet port and my router, I also found the UUID of the CF-card, and then updated the BIOS for "direct-drive" LVDS operation of the PixelQi screen, and lastly changed serial port one to 9600 bps (for U-Blox module) and made the USB the first try for booting.

I connected my U-Blox GPS module RS232 output to serial port one, and +5V power of course, and plugged in a digitemp USB temperature sensor, plugged in my cloned TinyCore 3.8.4 with real-time patch, and powered on the Vortex DX3, unfortunately it didn't boot and hangs up after the 10 second "pause" count-down  is completed.

Trying again and hitting Tab in that screen shows me some (all?) of the content of extlinux.conf (I think) where a lot of UUID's are seen, I think for the boot pen drive and the CF-card, I need to change these UUID's. I do know the UUID of the CF-card, but would booting up Lubuntu, plugging in the TinyCore boot drive, and typing "lsblk -f" work to get the UUID of the pen drive as well?

Then could I edit the extlinux.conf file on my Slackware Linux desktop entering in the new UUID's for the new CF-card and pen drive? Does that sound correct?

Thanks,

David

49

Raspberry Pi / Re: Running Alpine Linux Inside piCore on Raspberry Pi 400 (Chroot Method)

« Last post by patrikg on January 23, 2026, 03:46:17 PM »

I'm glad you're very committed to Tiny Core and PiCore, but it would be much better if you instead of posting messages here, you can submit your suggestions and examples of using TinyCore and PiCore by posting them on our wiki instead.

50

Raspberry Pi / Running Alpine Linux Inside piCore on Raspberry Pi 400 (Chroot Method)

« Last post by geev03 on January 23, 2026, 03:35:45 PM »

Here is clean way to run Alpine Linux inside piCore64 on a Raspberry Pi 400. This gives you Alpine’s full apk package ecosystem while keeping piCore’s minimal, RAM‑based design untouched. The setup works reliably and is useful for development, compiling, and sandboxing.

Below is a summary of the process and the important notes.
Why use Alpine inside piCore
piCore stays tiny, fast, and read‑only

Alpine provides a full userland with thousands of packages

No risk to the base system

Great for building software or running tools not available as .tcz

-----------------------------------------
1. Download and unpack Alpine (aarch64)

Code: [Select]

wget https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/aarch64/alpine-minirootfs-3.20.0-aarch64.tar.gz
mkdir /mnt/alpine
tar -xzf alpine-minirootfs-*.tar.gz -C /mnt/alpine

2. Mount required filesystems (from piCore host)

Code: [Select]

mount -t proc /proc /mnt/alpine/proc
mount -t sysfs /sys /mnt/alpine/sys
mount --bind /dev /mnt/alpine/dev
mount --bind /dev/pts /mnt/alpine/dev/pts

Fix DNS inside Alpine
Alpine may not ship with /etc/resolv.conf, so create it:

Code: [Select]

touch /mnt/alpine/etc/resolv.conf
mount --bind /etc/resolv.conf /mnt/alpine/etc/resolv.conf
3. Enter the Alpine environment

Code: [Select]

chroot /mnt/alpine /bin/sh

4. Update and install packages

Code: [Select]

apk update
apk add  fastfetch nano build-base python3 rust

5. What works well
Full Alpine package ecosystem

Compilers and build tools (gcc, clang, rust, cmake, etc.)

Networking and DNS

Fastfetch, shells, editors

Running Alpine apps directly on piCore’s kernel

6. What does not work
Podman / Docker
Podman fails during unpacking due to missing kernel features:

overlayfs with advanced options

cgroups v2

fuse-overlayfs

user namespace support

piCore’s kernel is intentionally minimal, so container runtimes are not viable.

proot
Alpine does not provide proot for aarch64 in any repo.
It must be installed manually from upstream binaries or built from source if needed.

7. System snapshot
Inside the chroot, tools like fastfetch correctly report:

OS: Alpine Linux

Kernel: piCore’s 6.x kernel

Packages: apk

Hardware: Raspberry Pi 400

This confirms Alpine is running entirely on the piCore kernel.

Conclusion
Running Alpine inside piCore on the Raspberry Pi 400 is a clean and effective way to get a full Linux userland without sacrificing piCore’s minimalism. It’s ideal for development and experimentation. Just note that container runtimes like Podman/Docker won’t work due to kernel limitations.

Code: [Select]

root@box:/# date
Fri Jan 23 20:34:53 UTC 2026
root@box:/# fastfetch
       .hddddddddddddddddddddddh.           root@box
      :dddddddddddddddddddddddddd:          --------
     /dddddddddddddddddddddddddddd/         OS: Alpine Linux 3.20.0 aarch64
    +dddddddddddddddddddddddddddddd+        Host: Raspberry Pi 400 Rev 1.0
  `sdddddddddddddddddddddddddddddddds`      Kernel: Linux 6.12.25-piCore-v8
 `ydddddddddddd++hdddddddddddddddddddy`     Uptime: 9 hours, 32 mins
.hddddddddddd+`  `+ddddh:-sdddddddddddh.    Packages: 74 (apk)
hdddddddddd+`      `+y:    .sddddddddddh    Shell: sh
ddddddddh+`   `//`   `.`     -sddddddddd    Display (    EZCAP28X): 1920x1080 @z
ddddddh+`   `/hddh/`   `:s-    -sddddddd    Terminal: sudo
ddddh+`   `/+/dddddh/`   `+s-    -sddddd    CPU: ARM CPU (4) @ 1.80 GHz
ddd+`   `/o` :dddddddh/`   `oy-    .yddd    Memory: 1.24 GiB / 3.71 GiB (33%)
hdddyo+ohddyosdddddddddho+oydddy++ohdddh    Swap: 0 B / 918.54 MiB (0%)
.hddddddddddddddddddddddddddddddddddddh.    Local IP (eth0): 192.168.1.194/24 *
 `yddddddddddddddddddddddddddddddddddy`     Locale: C
  `sdddddddddddddddddddddddddddddddds`
    +dddddddddddddddddddddddddddddd+        ████████████████████████
     /dddddddddddddddddddddddddddd/         ████████████████████████
      :dddddddddddddddddddddddddd:
       .hddddddddddddddddddddddh.
root@box:/#