# [INITRAMFS] mount ?? - ARM, hardened musl, /usr (résolu)

## Mr. T.

Bonjour !

Le contexte (configuration) : Le système d'exploitation du Raspberry Pi 2 (architecture ARM) doit être protégé car il sera employé comme serveur web. 

Pour cela, le système d'exploitation a un profil "hardened-musl-armv7a". Afin d'accroître la protection du serveur, les fichiers sont enregistrés sur plusieurs partitions, 

notamment la partition "usr".

Le problème : Malheureusement, le système n'est pas amorçable : la partition "racine" n'est pas détectée et en conséquent le montage du système de fichiers "racine" échoue.

Toutefois, le montage manuel du système de fichiers "racine" fonctionne en exécutant les commandes dans le shell de Busybox.

J'ai installé le dépôt d'ebuilds "musl". Il me semble que le script "init" exploite la version modifiée de Busybox. 

J'ai exploité différents scripts "init" (notamment ceux du Wiki) et différents "initramfs" mais sans parvenir à lancer Gentoo automatiquement.

Il s'agit peut-être d'un bogue issu de Busybox (musl) ou d'une mauvaise configuration ?

Je serai vraiment content que l'on m'aide à résoudre ce problème !

édition : L'amorçage de Gentoo fonctionne en utilisant l'archive 3 "standard" en ayant un point de montage /usr. Le problème résulte vraiment de la configuration : ARM, hardened musl, /usr.Last edited by Mr. T. on Thu Jun 15, 2017 7:55 pm; edited 2 times in total

----------

## Mr. T.

Il me semble que je pourrais isoler les facteurs pouvant engendrer le problème en procédant à un test.

La difficulté du test résulte lors de l'installation d'un compilateur croisé (cross build environment) adapté à musl et compatible avec l'architecture ARM (cf. tiny-initramfs).

Honêttement, je ne suis pas enclin à faire le test (j'ai un doute infondé par rapport à la qualité de l'article).

édition : 

```
localhost helecho $ man crossdev

Aucune entrée de manuel pour crossdev

localhost helecho $ info crossdev

localhost helecho $
```

On remonte à la source : crossdev. Bref, je suis ... au même point !

```
localhost crossdev-20151026 $ ls -l

total 56

-rwxrwxr-x 1 root root 37545 26 oct.   2015 crossdev

-rw-rw-r-- 1 root root   517 26 oct.   2015 Makefile

-rw-rw-r-- 1 root root   219 26 oct.   2015 settings.mk

-rw-rw-r-- 1 root root   290 26 oct.   2015 TODO

drwxrwxr-x 4 root root  4096 26 oct.   2015 wrappers

localhost crossdev-20151026 $ ls -l wrappers/

total 28

-rwxrwxr-x 1 root root 1055 26 oct.   2015 cross-emerge

-rwxrwxr-x 1 root root 2406 26 oct.   2015 cross-fix-root

-rwxrwxr-x 1 root root 4037 26 oct.   2015 cross-pkg-config

-rwxrwxr-x 1 root root 3619 26 oct.   2015 emerge-wrapper

drwxrwxr-x 3 root root 4096 26 oct.   2015 etc

-rw-rw-r-- 1 root root  860 26 oct.   2015 Makefile

drwxrwxr-x 2 root root 4096 26 oct.   2015 site

localhost crossdev-20151026 $ ls -l wrappers/site/

total 96

-rw-rw-r-- 1 root root  616 26 oct.   2015 armeb-linux-uclibc

-rw-rw-r-- 1 root root   25 26 oct.   2015 arm-linux-gnu

-rw-rw-r-- 1 root root  616 26 oct.   2015 arm-linux-gnueabi

-rw-rw-r-- 1 root root  616 26 oct.   2015 arm-linux-uclibc

-rw-rw-r-- 1 root root  616 26 oct.   2015 avr32-linux-uclibc

-rwxrwxr-x 1 root root 1346 26 oct.   2015 config.site

-rw-rw-r-- 1 root root   26 26 oct.   2015 cris-linux-uclibc

-rw-rw-r-- 1 root root  139 26 oct.   2015 darwin

-rw-rw-r-- 1 root root  616 26 oct.   2015 i386-linux-uclibc

-rw-rw-r-- 1 root root   25 26 oct.   2015 i686-linux-gnu

-rw-rw-r-- 1 root root  616 26 oct.   2015 i686-linux-uclibc

-rw-rw-r-- 1 root root 1832 26 oct.   2015 linux

-rw-rw-r-- 1 root root 2474 26 oct.   2015 linux-gnu

-rw-rw-r-- 1 root root 9399 26 oct.   2015 linux-gnueabi

-rw-rw-r-- 1 root root 1846 26 oct.   2015 linux-uclibc

-rw-rw-r-- 1 root root 6562 26 oct.   2015 mipsel-linux-gnu

-rw-rw-r-- 1 root root  616 26 oct.   2015 mipsel-linux-uclibc

-rw-rw-r-- 1 root root  616 26 oct.   2015 mips-linux-uclibc

-rw-rw-r-- 1 root root  616 26 oct.   2015 powerpc-linux-uclibc

-rw-rw-r-- 1 root root   25 26 oct.   2015 x86_64-linux-gnu

-rw-rw-r-- 1 root root  616 26 oct.   2015 x86_64-linux-uclibc

localhost crossdev-20151026 $ ls -Rl wrappers/etc/

wrappers/etc/:

total 4

drwxrwxr-x 2 root root 4096 26 oct.   2015 portage

wrappers/etc/portage:

total 4

-rw-rw-r-- 1 root root 485 26 oct.   2015 make.conf

```

helecho.

----------

## Mr. T.

 *Embedded Handbook wrote:*   

> A command-line front-end called crossdev will run emerge with all of the proper environment variables and install all the right packages to generate arbitrary cross-compilers based on the need of the user.

 

```
helecho@localhost /tmp/crossdev-20151026 $ file crossdev 

crossdev: Bourne-Again shell script, ASCII text executable
```

Il n'y a pas de documentation mais l'information peut être obtenue via crossdev --help ou bien en lisant le script "crossdev" (et éventuellement en se renseignant sur la compilation croisée).

----------

## Mr. T.

 *wiki article wrote:*   

> To build the failed packages it is needed to compile them "natively", which means in this case, that the packages need to be compiled in the target chroot environment. If the target host has a different architecture a qemu-chroot is needed. For targets that the build host cpu can handle directly the following steps can be skipped and you can chroot directly into the target environment. 

 

L'image UEFI (EFI Stub Kernel), résultant de l'activation des modules du noyau relatifs à QEMU, est rejetée par la plateforme micrologicielle UEFI de mon ordinateur : elle est invalide.

Le Wiki de Gentoo fournit peu d'informations sur musl. Il faudrait éventuellement étudier les autres projets ?

J'ai procédé en deux étapes afin de pouvoir compiler les programmes nativement avec musl :

 Partitionnement basique (amorçage réussi) : boot, swap et la racine (archivage / création d'une image amorçable adaptée au second partitionnement).

 Partitionnement élaboré (amorçage bloqué) : boot, swap, var, usr, racine, etc.

Ce procédé est peu pratique : la durée des opérations n'est pas négligeable.

----------

## Mr. T.

Je suis dans l'enfer paradisiaque de Gentoo.   :Evil or Very Mad: 

----------

## xaviermiller

Bonjour,

Pourrais-tu, pour commencer, démarrer une installation de base Gentoo sans initramfs, en suivant les pages du wiki Gentoo consacrées au Raspberry Pi ?

Le Raspberry Pi n'est pas UEFI, c'est un autre système... et je ne comprends pas trop le contenu des messages qui vont un peu dans tous les sens.

Pour cross-compiler des paquets sous Gentoo, c'est arm***-emerge, et passer par QEMU est encore plus lent que via le Raspberry Pi.

Ce que je fais avec mon RPI1, c'est un filesystem sur un disque USB (oublie de compiler sur la carte SD, tu la tueras en 10 secondes) ou plus récemment, sur NFS.

Je cross-compile des gros paquets comme gcc ou glibc, et le reste via (cross-)distcc.

----------

## Mr. T.

 *xaviermiller wrote:*   

> Le Raspberry Pi n'est pas UEFI, c'est un autre système... et je ne comprends pas trop le contenu des messages qui vont un peu dans tous les sens. 

 

Oui, la présentation doit paraître confuse. J'ai installé QEMU sur mon ordinateur portable (architecture x86_64, plateforme UEFI) afin de créer une chaîne de compilation croisée 

composé de la bibliothèque musl.

 *xaviermiller wrote:*   

> Pourrais-tu, pour commencer, démarrer une installation de base Gentoo sans initramfs, en suivant les pages du wiki Gentoo consacrées au Raspberry Pi ? 

 

J'ai déjà réussi l'installation basique avec et sans initramfs. J'ai également réussi l'installation basée sur musl sans initramfs. 

Toutefois, je ne parviens pas à amorcer le RPi 2 avec l'initramfs et musl (partitionnement avancé).

 *xaviermiller wrote:*   

> oublie de compiler sur la carte SD, tu la tueras en 10 secondes

 

J'ai dégradé une carte SD à cause des nombreux formattages mais je pense que le système du RPi 2 ne sera pas modifié très souvent.

J'ai également réussi à amorcer Gentoo en utilisant un disque dur externe sauf qu'il est désormais exploité pour une autre activité.

----------

## Mr. T.

 *xaviermiller wrote:*   

>  Pour cross-compiler des paquets sous Gentoo, c'est arm***-emerge, et passer par QEMU est encore plus lent que via le Raspberry Pi. 

 

Je m'en souviendrais lorsque la chaîne de compilation (armv7a, musl, etc.) sera fonctionnelle. Il serait éventuellement bénéfique que j'ouvre un fil de discussion dans

le forum anglophone (édition : j'ai ouvert un autre fil de discussion).

édition : Toutefois, il semblerait qu'il y ait peu d'utilisateurs de musl et du RPi2 donc je progresserai mieux en apprenant par moi-même.

 *helecho wrote:*   

> Le Wiki de Gentoo fournit peu d'informations sur musl. Il faudrait éventuellement étudier les autres projets ?

 

----------

## xaviermiller

De mon côté, j'utilise glibc sans aucun souci.

Essaie de découpler les problèmes, et ajoute la complexité petit à petit.

----------

## Mr. T.

 *xaviermiller wrote:*   

> Essaie de découpler les problèmes, et ajoute la complexité petit à petit.

 

J'ai ajouté la complexité progressivement et j'essaye désormais de résoudre le problème avec l'initramfs et musl (cf. la discussion)

 *helecho wrote:*   

> L'image UEFI (EFI Stub Kernel), résultant de l'activation des modules du noyau relatifs à QEMU, est rejetée par la plateforme micrologicielle UEFI de mon ordinateur : elle est invalide.

 

Il semblerait que la plateforme micrologicielle soit dégradée ou endommagée (à cause de moi).

----------

## Mr. T.

Je vais essayer de créer un initramfs à partir de zéro sans BusyBox. Je pense que je n'ai pas les compétences pour résoudre le problème.

----------

## Mr. T.

NeddySeagoon a trouvé la cause du problème : la détection des périphériques n'a pas été terminé au bon moment.

La solution est d'insérer "sleep 3" dans le fichier init, après l'instruction "mount devtmpfs none /dev", afin d'augmenter le temps d'allocation 

attribué pour la détection des périphériques.

helecho.

----------

