Quando lo sviluppo inizia, spesso non è chiaro quali pacchetti andranno nel rootfs di destinazione.
In altre parole, è ancora presto per affrettarsi verso LFS, buildroot o yocto (o altro), ma è già tempo di iniziare. Per i più fortunati (nel mio caso, ho campioni pilota con 4GB di eMMC), c'è un modo per fornire agli sviluppatori una distribuzione che permetta di consegnare rapidamente ciò che manca al momento, e poi possiamo sempre creare elenchi di pacchetti e formare un elenco per il rootfs di destinazione.
Questo articolo non offre novità e rappresenta semplicemente una guida di copy-paste.
L'obiettivo dell'articolo è la costruzione del rootfs Ubuntu per schede ARM (nel mio caso basato su Colibri imx7d).
Costruzione dell'immagine
Prepariamo il rootfs di destinazione per la replicazione.
Scompattiamo Ubuntu Base
Scegliamo il rilascio in base alle necessità e alle preferenze personali. Qui ho riportato 20.
$ mkdir ubuntu20
$ cd ubuntu20
$ mkdir rootfs
$ wget http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-armhf.tar.gz
$ tar xf ubuntu-base-20.04-base-armhf.tar.gz -C rootfsVerifica del supporto BINFMT nel kernel
Se hai una distribuzione popolare, il supporto per BINFMT_MISC è già attivo e configurato. In caso contrario, sono sicuro che sai come abilitare il supporto per BINFMT nel kernel.
Assicurati che BINFMT_MISC sia abilitato nel kernel:
$ zcat /proc/config.gz | grep BINFMT
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_BINFMT_MISC=yOra dobbiamo verificare le impostazioni:
$ ls /proc/sys/fs/binfmt_misc
qemu-arm register status
$ cat /proc/sys/fs/binfmt_misc/qemu-arm
enabled
interpreter /usr/bin/qemu-arm
flags: OC
offset 0
magic 7f454c4601010100000000000000000002002800
mask ffffffffffffff00fffffffffffffffffeffffffPuoi registrarlo manualmente utilizzando, ad esempio, .
Configurazione di qemu static arm
Ora avremo bisogno di un'istanza di qemu compilata staticamente.
!!! ATTENZIONE!!!
Se intendi utilizzare un container per compilare qualcosa, leggi:
In questo caso, per host x86_64 e guest arm, è necessario utilizzare la versione i386 di qemu:
$ wget http://ftp.debian.org/debian/pool/main/q/qemu/qemu-user-static_5.0-13_amd64.deb
$ alient -t qemu-user-static_5.0-13_amd64.deb
# Il percorso in rootfs e il nome del file eseguibile devono corrispondere a /proc/sys/fs/binfmt_misc/qemu-arm
$ mkdir qemu
$ tar xf qemu-user-static-5.0.tgz -C qemu
$ file qemu/usr/bin/qemu-arm-static
qemu/usr/bin/qemu-arm-static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=be45f9a321cccc5c139cc1991a4042907f9673b6, for GNU/Linux 3.2.0, stripped
$ cp qemu/usr/bin/qemu-arm-static rootfs/usr/bin/qemu-arm
$ file rootfs/usr/bin/qemu-arm
rootfs/usr/bin/qemu-arm: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=be45f9a321cccc5c139cc1991a4042907f9673b6, for GNU/Linux 3.2.0, strippedChroot
Script semplice:
ch-mount.sh
#!/bin/bash
function mnt() {
echo "MOUNTING"
sudo mount -t proc /proc ${2}proc
sudo mount --rbind /sys ${2}sys
sudo mount --make-rslave ${2}sys
sudo mount --rbind /dev ${2}dev
sudo mount --make-rslave ${2}dev
sudo mount -o bind /dev/pts ${2}dev/pts
sudo chroot ${2}
}
function umnt() {
echo "UNMOUNTING"
sudo umount ${2}proc
sudo umount ${2}sys
sudo umount ${2}dev/pts
sudo umount ${2}dev
}
if [ "$1" == "-m" ] && [ -n "$2" ] ;
then
mnt $1 $2
elif [ "$1" == "-u" ] && [ -n "$2" ];
then
umnt $1 $2
else
echo ""
echo "Either 1'st, 2'nd or both parameters were missing"
echo ""
echo "1'st parameter can be one of these: -m(mount) OR -u(umount)"
echo "2'nd parameter is the full path of rootfs directory(with trailing '/')"
echo ""
echo "For example: ch-mount -m /media/sdcard/"
echo ""
echo 1st parameter : ${1}
echo 2nd parameter : ${2}
fiOsserviamo il risultato ottenuto:
$ ./ch-mount.sh -m rootfs/
# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
# uname -a
Linux NShubin 5.5.9-gentoo-x86_64 #1 SMP PREEMPT Mon Mar 16 14:34:52 MSK 2020 armv7l armv7l armv7l GNU/LinuxPer curiosità, misuriamo la dimensione prima e dopo l'installazione del pacchetto minimo (per me) richiesto:
# du -d 0 -h / 2>/dev/null
63M /Aggiorniamo:
# apt update
# apt upgrade --yesInstalliamo i pacchetti che ci interessano:
# SYSTEMD_IGNORE_CHROOT=yes apt install --yes autoconf kmod socat ifupdown ethtool iputils-ping net-tools ssh g++ iproute2 dhcpcd5 incron ser2net udev systemd gcc minicom vim cmake make mtd-utils util-linux git strace gdb libiio-dev iiodI file di intestazione del kernel, i moduli, meritano una discussione a parte. Non installeremo il bootloader, il kernel, i moduli e il device tree tramite Ubuntu. Arriveranno dall'esterno, li assembleremo noi stessi o ce li fornirà il produttore della scheda madre; in ogni caso, è oltre l'ambito di queste istruzioni.
Fino a un certo punto, è permesso uno scostamento delle versioni, ma è meglio prenderle dalla build del kernel.
# apt install --yes linux-headers-genericGuardiamo cosa abbiamo ottenuto, e non è poco:
# apt clean
# du -d 0 -h / 2>/dev/null
770M /Non dimenticate di impostare una password.
Impacchettiamo l'immagine
$ sudo tar -C rootfs --transform "s|^./||" --numeric-owner --owner=0 --group=0 -c ./ | tar --delete ./ | gzip > rootfs.tar.gzIn aggiunta, possiamo installare etckeeper con la configurazione autopush.
Supponiamo di aver distribuito la nostra build; ora, come meglio raccogliere varie versioni del nostro sistema?
Etckeeper può venire in nostro aiuto.
La sicurezza è un affare personale:
- puoi proteggere rami specifici
- generare una chiave unica per ogni dispositivo
- vietare il force push
- e così via…
# ssh-keygen
# apt install etckeeper
# etckeeper init
# cd /etc
# git remote add origin ...Configuriamo l'autopush.
Possiamo anche creare in anticipo rami sul dispositivo (ad esempio, fare uno script o un servizio che venga eseguito al primo avvio).
# cat /etc/etckeeper/etckeeper.conf
PUSH_REMOTE="origin"Oppure possiamo essere più furbi…
Il percorso comodo
Abbiamo bisogno di un identificatore unico, ad esempio un numero di serie del processore (o un MAC — le aziende serie acquistano un intervallo):
cat /proc/cpuinfo
# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 60.36
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 60.36
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : Freescale i.MX7 Dual (Device Tree)
Revision : 0000
Serial : 06372509Quindi possiamo usarlo come nome del ramo su cui faremo il push:
# cat /proc/cpuinfo | grep Serial | cut -d':' -f 2 | tr -d [:blank:]
06372509Creiamo uno script semplice:
# cat /etc/etckeeper/commit.d/40myown-push
#!/bin/sh
set -e
if [ "$VCS" = git ] && [ -d .git ]; then
branch=$(cat /proc/cpuinfo | grep Serial | cut -d':' -f 2 | tr -d [:blank:])
cd /etc/
git push origin master:${branch}
fiE tutto — dopo un po’ possiamo controllare le modifiche e generare un elenco dei pacchetti per il firmware di destinazione.
Materiale consigliato
problema getdents64
Fonte: habr.com
