Seguí la guía " Yocto NFS & TFTP boot " de la base de conocimiento i.MX para hacer que mi dispositivo Linux incorporado ejecute un kernel y un sistema de archivos en mi máquina de desarrollo.
El kernel parece estar correctamente cargado a través de TFTP, pero el sistema no arranca correctamente y systemd entra en modo de mantenimiento.
Aquí está el primer error en el registro:
[ 10.637534] systemd[1]: dev-mqueue.mount: Mount process exited, code=exited, status=32/n/a [ 10.657077] systemd[1]: dev-mqueue.mount: Failed with result 'exit-code'. [ 10.666907] systemd[1]: Failed to mount POSIX Message Queue File System. [FAILED] Failed to mount POSIX Message Queue File System. See 'systemctl status dev-mqueue.mount' for details.Parece similar al registro incluido en un comentario sin respuesta en esa misma guía.
Mirando systemctl status dev-mqueue.mount veo:
* dev-mqueue.mount - POSIX Message Queue File System Loaded: loaded (/lib/systemd/system/dev-mqueue.mount; static) Active: failed (Result: exit-code) since Sun 2022-03-06 11:52:40 UTC; 5h 29min ago Where: /dev/mqueue What: mqueue Docs: man:mq_overview(7) https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Mar 06 11:52:40 pico-imx7 mount[180]: mount: /dev/mqueue: must be superuser to use mount. Notice: journal has been rotated since unit was started, output may be incomplete.No estoy seguro de qué está mal o por qué el sistema fallaría así.
El mensaje must be superuser to use mount es una pista de un problema de permisos.
El sistema Linux espera que la mayoría de los archivos del sistema sean propiedad del UID 0 (raíz), pero al leer el sistema de archivos NFS configurado en la guía, en realidad lee el UID 1000, o el UID de quien haya creado el sistema en la máquina de desarrollo. Si enumero el contenido de ${YOCTO_BUILD_DIR}/tmp/work/${TARGET}-poky-linux-gnueabi/${IMAGE}/1.0-r0/rootfs , obtengo:
drwxr-xr-x 20 1000 1000 4096 Mar 9 2018 ./ drwxr-xr-x 14 1000 1000 4096 Mar 5 19:19 ../ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 bin/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 boot/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 dev/ drwxr-xr-x 59 1000 1000 4096 Mar 9 2018 etc/ drwxr-xr-x 4 1000 1000 4096 Mar 9 2018 home/ drwxr-xr-x 10 1000 1000 4096 Mar 9 2018 lib/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 media/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 mnt/ drwxr-xr-x 4 1000 1000 4096 Mar 9 2018 opt/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 proc/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 run/ drwxr-xr-x 3 1000 1000 4096 Mar 9 2018 sbin/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 srv/ drwxr-xr-x 2 1000 1000 4096 Mar 9 2018 sys/ drwxr-xr-t 2 1000 1000 4096 Mar 9 2018 tmp/ drwxr-xr-x 38 1000 1000 4096 Mar 9 2018 unit_tests/ drwxr-xr-x 11 1000 1000 4096 Mar 9 2018 usr/ drwxr-xr-x 9 1000 1000 4096 Mar 9 2018 var/ Observe el 1000 como UID y GID.
Compare eso con la lista del tarball de la imagen del sistema de archivos, hecho con tar --exclude=\*/\*/\* --no-wildcards-match-slash -tjvf ${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.tar.bz2 :
drwxr-xr-x 0/0 0 2018-03-09 13:34 ./ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./bin/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./boot/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./dev/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./etc/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./home/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./lib/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./media/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./mnt/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./opt/ dr-xr-xr-x 0/0 0 2018-03-09 13:34 ./proc/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./run/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./sbin/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./srv/ dr-xr-xr-x 0/0 0 2018-03-09 13:34 ./sys/ drwxrwxrwt 0/0 0 2018-03-09 13:34 ./tmp/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./unit_tests/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./usr/ drwxr-xr-x 0/0 0 2018-03-09 13:34 ./var/ Aquí los directorios raíz pertenecen correctamente a root .
Los mismos permisos están en el archivo de imagen .ext4 , que forma parte del archivo de imagen SD/MMC.
Dos posibles soluciones:
${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.ext4 como bucle en un directorio, luego exporte ese directorio a través de NFS (puede requerir privilegios de root);${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.tar.bz2 en un directorio, luego exporte ese directorio a través de NFS; requerirá privilegios de root y algo más de tiempo para extraer el sistema de archivos incrustado.