MD(ADM) support for piCore

[CentralWare]

@Paul_123: This one's probably right up your alley

With the advent of the RasPi 4x/5x and USB3, mini NAS-like SATA boards/hats/backplanes have popped up here and there over the past few years.
Yesterday, I plugged in an OTG hub with a few low power flash drives thinking I'd Soft-RAID5 the bunch and realized... there's no raid tool support in piCore.
Dating back to 10.x it looks like there's never been - and probably by assumption "...who would want or need RAID on RasPi?"
I am *assuming* ATA (IDE/SATA) support is already in the kernel and I think I saw RAID modules in 15.x in there as well, so all we should need is the mdadm tool.

https://www.kernel.org/pub/linux/utils/raid/mdadm/

Version: 4.3 (2024)
Build Deps: libudev-dev
Patch: mdadm-4.3/udev.c Line 94: Remove "udev =" in line (void assignment)
Just ran it - looks like everything went well; untested at the moment beyond --help

NOTE: I'm assuming raid-KERNEL is a dependency but LDD says everything's good, so we'll see!

Compiled under native RasPi piCore 15.x
  add flags accordingly
  Install and Strip should be run as SU

Code: [Select]

#!/bin/sh
CUR=$(pwd)

VERSION=4.3

HOST="https://www.kernel.org/pub/linux/utils/raid/mdadm"
DOWN="${HOST}/mdadm-${VERSION}.tar.gz"

EXTS="wget compiletc libudev-dev squashfs-tools"

for EXT in $EXTS
do
    EXT=${EXT/.tcz/}
    if [ ! -f /etc/sysconfig/tcedir/optional/${EXT}.tcz ]; then
        tce-load -w $EXT
    fi
done

for EXT in $EXTS
do
    EXT=${EXT/.tcz/}
    if [ ! -d /tmp/tcloop/${EXT} ]; then
        tce-load -i $EXT
    fi
done

nproc()
{
    CPUS=$(cat /proc/cpuinfo | grep processor | awk -F: '{print $2}')
    for CPU in $CPUS; do MAX=$(expr $CPU + 1 2>/dev/null); done; echo $MAX
}

[ ! -f mdadm-${VERSION}.tar.gz ] && wget --no-check-certificate $DOWN
[ ! -d mdadm-${VERSION} ] && tar -zxf mdadm-${VERSION}.tar.gz

cd mdadm-${VERSION}
sed -i 's/udev = udev_unref(udev)/udev_unref(udev)/g' udev.c

if [ ! ./.compiled ]; then
    make -j$(nproc) || exit 1
    touch ./.compiled
fi

make DESTDIR=/tmp/mdadm install || exit 1

if [ ! -f $CUR/mdadm-${VERSION}.tcz ]; then
    cd /tmp

    strip -s mdadm/sbin/mdadm
    strip -s mdadm/sbin/mdmon

    mkdir mdadm_doc
    cp /tmp/mdadm/usr ./mdadm_doc -R
    mksquashfs mdadm_doc $CUR/mdadm-${VERSION}-doc.tcz
    rm mdadm_doc -fR

    rm mdadm/usr -fR
    mksquashfs mdadm $CUR/mdadm-${VERSION}.tcz

    cd $CUR
    md5sum mdadm-${VERSION}.tcz > mdadm-${VERSION}.tcz.md5.txt
    md5sum mdadm-${VERSION}-doc.tcz > mdadm-${VERSION}-doc.tcz.md5.txt
fi


[Paul_123]

You did that much, just submit the extension.

[CentralWare]

That'll take a bit (to compile for each platform, test accordingly, etc.) but, as you wish.
@Juanito normally runs the x86/64 maint. but it's been copied over since version 4.0 (2017)

[Juanito]

I can update the x86/x86_64 mdadm extensions if you’d like?

[Paul_123]

I don’t run raid on my raspi devices, nor do I have hardware.  So I cannot test.  Which is why I suggested for you to do it.

[CentralWare]

...nor do I have hardware

Understood; after @bmarkus stepped down I thought you were passed the baton as the Go To Pi Guy

@Juanito: Don't worry about the PC versions - compared to ARM testing, those are rather easy.

piCore 15x armhf
Raspberry Pi Zero(W) compiled successfully, failed at make test telling me I had to run ./test as root...  while I was su'ed -- today's just been one of those days!

Created a 7 segment RAID5 array using an OTG adapter, 7 port hub and seven 256GB USB flash drives (Pretty Blinky Lights!) so I'm going to write it off as a success.

I'll submit as testing allows for each flavor to be completed once the builder's been refit as a Simple project

Take care, gang!

[Paul_123]

Yes, I picked up the baton, but that does not mean I’m the sole person who can build extensions for piCore.  We take user submissions just the same.

[CentralWare]

...but that does not mean I’m the sole person who can build extensions for piCore...

Yes you are! Nobody else has any!
(They all sold their Raspberry's for 3000x what they're worth during COVID!!!)

Okay, I've assigned a pair of Optiplex boxes to handle x86/x64 quickie-builds
ARMv8/64 will have to wait a bit as I don't have a Pi4/Pi5 rig at the house and I'd prefer to "see" USB3 along with MD working hand-in-hand.
ARMv6 and v7 are already tested through some of the basics but I want to fix the internal make test && sudo ./test BUT...

As luck would have it, this is one of the many times I've run across naming chaos.

Arm Extension: libudev-dev.tcz
x86 Extension: udev-dev.tcz

Left Hand - Meet Right Hand...

Is this intentional in some instances or something??

(If not, it's in the cross-hairs)

[CentralWare]

LMAO!

TCL 4.x was just put to pasture a week or so ago.
mdadm_build doesn't exist in x86 or x64 from 5.x to current
but it's in 4.x 

15xARM: libudev-dev
15x86:   udev-dev
15x64:   udev-lib-dev

Must be a Monday...

[Paul_123]

Udev was renamed to match x86_64 in, I believe, piCore 14.

And it’s

udev-lib-dev.tcz
udev-lib.tcz

[CentralWare]

That's what's funny...
In repo.tinycorelinux.net you'll find:

Code: [Select]

14.x aarch64 udev-lib-dev.tcz
14.x armv6 udev-lib-dev.tcz
14.x armv7 udev-lib-dev.tcz
14.x x86_64 udev-lib-dev.tcz
14.x x86 udev-dev.tcz <-- The Oddball

But...

Code: [Select]

15.x aarch64 libudev-dev.tcz
15.x armhf libudev-dev.tcz
15.x x86_64 udev-lib-dev.tcz
15.x x86 udev-dev.tcz
...at least it has a pair of matching arms!

[Paul_123]

Since we are stuck at udev-174. Extensions have not been updated in a while.

Although I see that LFS is now building much newer versions of udev without systems support.  So perhaps we can update.

[Juanito]

The last time I looked at it, later versions of udev required several MB of hwdb.

That being said I have used later versions of udev/gudev to make gnome-session work in CorePure64.

[Paul_123]

Agree,  at one point I thought I saw Bluez was going to require >195 or so.   Sooner or later we’ll get forced into it.