Boot des différents BSD

JKB :

[...oops...]
Pour un accès DMA foireux, le noyau Linux panique. Bref, ce n'est
pas idiot de ne pas paniquer lorsqu'on sait qu'on ne risque rien.

Sachant que quelque chose à foiré quelque part, j'aurais du mal à croire que
qui ou quoi que ce soit «_sache_» que «l'on ne risque rien».


--
http://www.freebsd.org/fr/ http://www.arcadehits.net/
http://www.diablotins.org/

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Le hard, ça doit lancer le bootloader, rien d'autre.

Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?

Bonne question. Pourquoi?
En quoi cela permet de répondre à toutes les possibilités ouvertes par
un initrd/ramfs?

Parce que dans Openprom au hasard, il y a la notion de scripts, de
configuration ouverte (et pas que de nfs, je t'ai filé plus haut un
exemple) et que initrd n'apporte rien en plus si tu _sais_ utiliser
correctement le truc.

tu entretiens une confusion entre:
-booter un noyau
-monter la racine.
Je découpe, à dessein, le process en deux temps. Ton openprom permet
de booter un noyau, j'en suis ravi. Je te parle de ce qui se passe
ensuite.
Selon tes propres dire "le noyau n'a rien à faire tant que la racine
n'est pas montée".
Je maintiens que si. Et on est loin de ton openprom, puisque le noyau
est _déjà_ booté.
On reprend les arguments:
-racine chiffrée. C'est l'openprom qui te demande le mot de passe?
Si oui, donnes moi un exemple avec support de LuKS sur du LVM.
-racine nfs over-wifi. C'est l'openprom qui te demande la clé WPA? (et
encore, c'est peut être le seul exemple ou, éventuellement, ça
pourrait fonctionner)
-détection environnementale[1]. C'est l'openprom?
-Un splashscreen, c'est l'openprom enore? Idem, donnes moi un exemple
de splashscreen avec une barre de progression qui suit le processus
de boot, avec, par exemple, une racine chiffrée située sur du nfs
over wifi, juste par exemple, hein.

Ta si fameuse openprom si ce n'est donner deux trois paramètres au noyau
puis lancer un noyau, que fait elle? Pas grand chose. Sépares bien les
deux évenements: 1, je boote le noyau. 2, je monte la racine. Entre 1 et
2 il y a la place de faire beaucoup de choses.

Entre 1 et 2, tu as le choix. Soit de laisser faire, soit d'intervenir.
L'interêt est là. Que tu trouves ça bancal car tu n'est tombé que sur
des scripts écrit avec les pieds, c'est une chose. Que tu dises que c'est
de la merde patentée, pourquoi pas, mais je suis en désaccord. Que tu
dises que tu puisses dans tous les cas le remplacer par un openprom, là,
c'est soit de la méconnaissance, soit de la mauvaise foi.

[1]Comme par exemple de faire une détection bluetooth pour savoir
si _mon_ téléphone est dans un environ proche. Si je suis là, ça
démarre normalement. Si je ne suis pas là, cela veut dire que c'est
une personne non autorisée qui allume l'ordinateur. Et là, il est
possible d'agir. C'est de la fausse sécurité, mais ça coute pas cher :)
--
Kevin

Salut,

Kevin Denis a écrit :

Le 05-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine.

Trois cas concrets:

[...]

N'est-ce pas aussi nécessaire lorsque la racine est en LVM sur un volume
RAID soft ?

Le 07-12-2008, ? propos de
Re: Boot des différents BSD,
Kevin Denis ?crivait dans fr.comp.os.bsd :

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Le hard, ça doit lancer le bootloader, rien d'autre.

Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?

Bonne question. Pourquoi?
En quoi cela permet de répondre à toutes les possibilités ouvertes par
un initrd/ramfs?

Parce que dans Openprom au hasard, il y a la notion de scripts, de
configuration ouverte (et pas que de nfs, je t'ai filé plus haut un
exemple) et que initrd n'apporte rien en plus si tu _sais_ utiliser
correctement le truc.

tu entretiens une confusion entre:
-booter un noyau
-monter la racine.
Je découpe, à dessein, le process en deux temps. Ton openprom permet
de booter un noyau, j'en suis ravi. Je te parle de ce qui se passe
ensuite.
Selon tes propres dire "le noyau n'a rien à faire tant que la racine
n'est pas montée".
Je maintiens que si. Et on est loin de ton openprom, puisque le noyau
est _déjà_ booté.
On reprend les arguments:
-racine chiffrée. C'est l'openprom qui te demande le mot de passe?

Tu peux l'avoir en dur ou y coller un script.

Si oui, donnes moi un exemple avec support de LuKS sur du LVM.
-racine nfs over-wifi. C'est l'openprom qui te demande la clé WPA? (et
encore, c'est peut être le seul exemple ou, éventuellement, ça
pourrait fonctionner)

Idem.

-détection environnementale[1]. C'est l'openprom?
-Un splashscreen, c'est l'openprom enore? Idem, donnes moi un exemple
de splashscreen avec une barre de progression qui suit le processus
de boot, avec, par exemple, une racine chiffrée située sur du nfs
over wifi, juste par exemple, hein.

Je te parle de fonctionnement, pas de trucs jolis au boot. Dans un
système normalement conçu, tu commences par monter ta racine et ce sont
les utilitaires _sur_ ta racine qui détectent l'environnement si le
noyau n'est pas capable de le faire. Je ne vois toujours pas en quoi
rajouter une étape (montage d'un ramfs, parce que c'est de ça qu'on
parle même si ce montage résulte d'un fonctionnement du bootloader) va
régler le problème. C'est même pour cela qu'historiquement, on fait une
différence (enfin généralement...) entre / et /usr.

Ta si fameuse openprom si ce n'est donner deux trois paramètres au noyau
puis lancer un noyau, que fait elle? Pas grand chose. Sépares bien les
deux évenements: 1, je boote le noyau. 2, je monte la racine. Entre 1 et
2 il y a la place de faire beaucoup de choses.

Qui n'ont pas leur place normalement là. Je rajouterai qu'entre le
montage de la racine (généralement en ro et single user) et le lancement
multiuser, il y a pas mal d'étapes qui devraient contenir ce que tu
essayes de coller en initrd.

Entre 1 et 2, tu as le choix. Soit de laisser faire, soit d'intervenir.
L'interêt est là. Que tu trouves ça bancal car tu n'est tombé que sur
des scripts écrit avec les pieds, c'est une chose. Que tu dises que c'est
de la merde patentée, pourquoi pas, mais je suis en désaccord. Que tu
dises que tu puisses dans tous les cas le remplacer par un openprom, là,
c'est soit de la méconnaissance, soit de la mauvaise foi.

Ce n'est pas parce que linux le fait que c'est une bonne chose. Je
prétends simplement que tous les exemples que tu m'as filé jusqu'à
présent se résolvent facilement avec un truc comme SRM ou Openprom et
unne détection de l'environnement après le montage de la racine (puisque
tu sembles tenir à ce point).

[1]Comme par exemple de faire une détection bluetooth pour savoir
si _mon_ téléphone est dans un environ proche. Si je suis là, ça
démarre normalement. Si je ne suis pas là, cela veut dire que c'est
une personne non autorisée qui allume l'ordinateur. Et là, il est
possible d'agir. C'est de la fausse sécurité, mais ça coute pas cher :)

Rien ne t'empêche de le faire juste après le montage de la racine et
de coller un shutdown immédiat (avant la bascule en init 2, 3, 4 ou 5 si
on continue de causer Linux).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Le hard, ça doit lancer le bootloader, rien d'autre.

Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?

Bonne question. Pourquoi?

tu entretiens une confusion entre:
-booter un noyau
-monter la racine.
Je découpe, à dessein, le process en deux temps. Ton openprom permet
de booter un noyau, j'en suis ravi. Je te parle de ce qui se passe
ensuite.
Selon tes propres dire "le noyau n'a rien à faire tant que la racine
n'est pas montée".
Je maintiens que si. Et on est loin de ton openprom, puisque le noyau
est _déjà_ booté.
On reprend les arguments:
-racine chiffrée. C'est l'openprom qui te demande le mot de passe?

Tu peux l'avoir en dur ou y coller un script.

Donne moi un cas concret. Aussi concret que les variables de ta
racine nfs.

Nous sommes dans le cas ou le noyau démarre
et où, avant d'avoir monté la racine et _après_ avoir
booté le noyau, tu as des choses à faire. NetBSD a du
dépecher un dev noyau pour écrire ce bout de script. Est-ce
son job? Est-ce la seule solution? N'est-ce pas limité?

Si oui, donnes moi un exemple avec support de LuKS sur du LVM.

Pas de réponse.

-racine nfs over-wifi. C'est l'openprom qui te demande la clé WPA? (et
encore, c'est peut être le seul exemple ou, éventuellement, ça
pourrait fonctionner)

Idem.

Le cas concret? Avec un script openprom?

-détection environnementale[1]. C'est l'openprom?
-Un splashscreen, c'est l'openprom enore? Idem, donnes moi un exemple
de splashscreen avec une barre de progression qui suit le processus
de boot, avec, par exemple, une racine chiffrée située sur du nfs
over wifi, juste par exemple, hein.

Je te parle de fonctionnement,

En fait, tu limites toi même les possibles. En partant de là, bien
sur que l'initrd est inutile. Je paraphrase de manière
ironique:
-Mr JKB, est-ce que l'initrd est utile?
-dans tous les cas ou l'initrd est inutile, je dis que l'initrd
est inutile.

pas de trucs jolis au boot.

Donc on évacue le problème. C'est sur que c'est simple de
se passer d'initrd dans ce cas. Ce n'est pas faisable sans
initrd? Alors je m'en passe et je dis que l'initrd est
inutile.

Dans un
système normalement conçu, tu commences par monter ta racine

Et _comment_ tu la montes cette racine scrogneugneu? Chez toi,
ça semble être magique, le noyau démarre, pouf la racine est
là. Je te donne des cas concret, et en face, tu ne donnes que
des "bah ça devrait", "openprom est magique", etc..

et ce sont
les utilitaires _sur_ ta racine qui détectent l'environnement si le
noyau n'est pas capable de le faire. Je ne vois toujours pas en quoi
rajouter une étape (montage d'un ramfs, parce que c'est de ça qu'on
parle même si ce montage résulte d'un fonctionnement du bootloader) va
régler le problème. C'est même pour cela qu'historiquement, on fait une
différence (enfin généralement...) entre / et /usr.

C'est vrai, mais c'est hors sujet. Tu parles de distinction entre /
et /usr. C'est forcément _après_ que la racine soit montée. Donc
hors sujet.

Ta si fameuse openprom si ce n'est donner deux trois paramètres au noyau
puis lancer un noyau, que fait elle? Pas grand chose. Sépares bien les
deux évenements: 1, je boote le noyau. 2, je monte la racine. Entre 1 et
2 il y a la place de faire beaucoup de choses.

Qui n'ont pas leur place normalement là. Je rajouterai qu'entre le
montage de la racine (généralement en ro et single user) et le lancement
multiuser, il y a pas mal d'étapes qui devraient contenir ce que tu
essayes de coller en initrd.

On revient à la même chose. Comment tu l'as montée cette racine?
Ensuite, on peut mettre tous les zigouigouis qu'on souhaite dans
le rc., mais ce n'est pas la question.

Entre 1 et 2, tu as le choix. Soit de laisser faire, soit d'intervenir.
L'interêt est là. Que tu trouves ça bancal car tu n'est tombé que sur
des scripts écrit avec les pieds, c'est une chose. Que tu dises que c'est
de la merde patentée, pourquoi pas, mais je suis en désaccord. Que tu
dises que tu puisses dans tous les cas le remplacer par un openprom, là,
c'est soit de la méconnaissance, soit de la mauvaise foi.

Ce n'est pas parce que linux le fait que c'est une bonne chose.

Non. Comme je te le répete, je trouve que c'est une solution élégante
à tout un tas de problèmes, et surtout sur le fait que cela étend de
manière illimitée la manière de booter un système.
D'où mon post sur ce groupe, BSD, qui demande pourquoi d'autres systèmes
ne l'implémentent pas.

A ce sujet, j'ai eu deux réponses:
-l'initrd ne servirait qu'a charger des modules, auquel cas c'est inutile.
-le noyau NetBSD à implémenté en dur dans le code du noyau une option
pour booter sur une partition chiffrée.

Je suis tout à fait d'accord avec le premier cas, sauf qu'un initrd
peut servir à tout un tas d'autres choses que de charger des modules.
Le second semble me dire qu'il y a une réelle nécessité d'intervenir
entre le chargement du noyau et le montage de la racine.

Je prétends simplement que tous les exemples que tu m'as filé jusqu'à
présent se résolvent facilement avec un truc comme SRM ou Openprom et

Donne moi la solution pour monter ma racine chiffrée.
Donne moi la solution pour l'installeur quand tu as plus d'un media
d'installation.
Donne moi la solution pour la clé WPA.
Donne moi la solution pour une racine situé sur un nouveau
périphérique. Genre imaginons sur ta machine, tu installes une carte
PCI qui a besoin d'un firmware qui va te donner un bus USB3 à
temps d'allumage variable qui a de nouveau besoin d'un firmware
pour une grappe en RAID5. Magiquement ton openprom antérieur à la
carte PCI, à l'USB3 et à toutes ces sortes de trucs va te donner
toutes les bonnes options pour charger les firmware, attendre
le tout, et lancer on ne sait comment le raid soft linux? Restons
sérieux.

Si c'est si facile, pourquoi ne les donnes tu pas?
Ta réponse, c'est "ca serait éventuellement possible". Bien, donc face à
un problème, il faut attendre une solution _a posteriori_,
l'initramfs te donne une solution _a priori_.

unne détection de l'environnement après le montage de la racine (puisque
tu sembles tenir à ce point).

Non, je parle de manière générale. Des exemples de ce que l'on
peut faire avec un initramfs, il y en a pleins. Largement plus
nombreux que ce que je peux imaginer. Et c'est justement là ou
intervient la finesse de son utilisation. Ce n'est pas un
système figé, c'est un système parfaitement modulable pour le
plier à tes besoins.
Sans ce système, tu es bloqué aux quelques cas d'utilisation
prévus par les développeurs noyaux.
D'où la myriade d'options passées en paramètre au noyau lui
permettant de trouver sa racine. Mais par définition, cette
série d'options est _limitée_. L'initramfs t'apporte la
solution.

[1]Comme par exemple de faire une détection bluetooth pour savoir
si _mon_ téléphone est dans un environ proche. Si je suis là, ça
démarre normalement. Si je ne suis pas là, cela veut dire que c'est
une personne non autorisée qui allume l'ordinateur. Et là, il est
possible d'agir. C'est de la fausse sécurité, mais ça coute pas cher :)

Rien ne t'empêche de le faire juste après le montage de la racine et
de coller un shutdown immédiat (avant la bascule en init 2, 3, 4 ou 5 si
on continue de causer Linux).

Un autre principe consiste à télécharger la clé de la racine chiffrée
sur mon téléphone bluetooth. Ou tout autre chose. Systématiquement
tu réduis les cas d'utilisations sans voir ce que cela peut apporter.
--
Kevin

Le 07-12-2008, ? propos de
Re: Boot des différents BSD,
Kevin Denis ?crivait dans fr.comp.os.bsd :

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Le hard, ça doit lancer le bootloader, rien d'autre.

Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?

Bonne question. Pourquoi?

tu entretiens une confusion entre:
-booter un noyau
-monter la racine.
Je découpe, à dessein, le process en deux temps. Ton openprom permet
de booter un noyau, j'en suis ravi. Je te parle de ce qui se passe
ensuite.
Selon tes propres dire "le noyau n'a rien à faire tant que la racine
n'est pas montée".
Je maintiens que si. Et on est loin de ton openprom, puisque le noyau
est _déjà_ booté.
On reprend les arguments:
-racine chiffrée. C'est l'openprom qui te demande le mot de passe?

Tu peux l'avoir en dur ou y coller un script.

Donne moi un cas concret. Aussi concret que les variables de ta
racine nfs.

Nous sommes dans le cas ou le noyau démarre
et où, avant d'avoir monté la racine et _après_ avoir
booté le noyau, tu as des choses à faire. NetBSD a du
dépecher un dev noyau pour écrire ce bout de script. Est-ce
son job? Est-ce la seule solution? N'est-ce pas limité?

Tu as bien avoué plus haut avoir écrit toi-même tes scripts
initramfs. Je ne vois pas la différence.

<snip>

Je te parle de fonctionnement,

En fait, tu limites toi même les possibles. En partant de là, bien
sur que l'initrd est inutile. Je paraphrase de manière
ironique:
-Mr JKB, est-ce que l'initrd est utile?
-dans tous les cas ou l'initrd est inutile, je dis que l'initrd
est inutile.

pas de trucs jolis au boot.

Donc on évacue le problème. C'est sur que c'est simple de
se passer d'initrd dans ce cas. Ce n'est pas faisable sans
initrd? Alors je m'en passe et je dis que l'initrd est
inutile.

Tu ne m'as pas donné un argument dans lequel initrd (ou initramfs)
était indispensable à un fonctionnement donné sur une machine de prod
(ie pas une machine qu'on reboote tous les quarts d'heures). Des
machines qui bootent sur des trucs bizarres, j'en ai (même une sparc T2+
qui boote actuellement sur un disque USB _chiffré_), et je n'ai jamais
eu besoin d'avoir recours à ce mécanisme foireux.

Dans un
système normalement conçu, tu commences par monter ta racine

Et _comment_ tu la montes cette racine scrogneugneu? Chez toi,
ça semble être magique, le noyau démarre, pouf la racine est
là. Je te donne des cas concret, et en face, tu ne donnes que
des "bah ça devrait", "openprom est magique", etc..

Non, je te dis que la racine est indiquée dans un coin de la nvram
et que le noyau normalement constitué va chercher ses paramètres dans
l'arborescence de la nvram. C'est ce qui se passe sous Sparc, sous Mac
dans une certaine mesure, sous IA64 et prédécesseurs (VAX et Alpha) et
sous bien d'autres classes de serveurs. Je n'ai jamaisnprétendu que le
truc était magique, simplement qu'il permettait d'indiquer de façon
_simple_ et efficaces des configurations souvent compliquées de boot.
Openprom est même assez bien fichu pour avoir plusieurs configurations
de boot sur plusieurs serveurs distants pour pouvoir booter dès que l'un
deux est fonctionnel. Je vais donc faire un dessin dans le cas openprom :

Openprom -> boot loader -> kernel -> montage de openpromfs ->
récupération des paramètres (racine, protocole d'accès à la racine, mot
de passe le cas échéant...) -> montage de la racine / en ro -> lancement des
scripts système -> montage des autres partitions et remontage de la racine
en rw -> basculement en multiuser

Que veux-tu de plus dans le cas d'un système _normal_ (pas un truc
destiner à lancer une installation, parce que là, on peut ergoter) ?

et ce sont
les utilitaires _sur_ ta racine qui détectent l'environnement si le
noyau n'est pas capable de le faire. Je ne vois toujours pas en quoi
rajouter une étape (montage d'un ramfs, parce que c'est de ça qu'on
parle même si ce montage résulte d'un fonctionnement du bootloader) va
régler le problème. C'est même pour cela qu'historiquement, on fait une
différence (enfin généralement...) entre / et /usr.

C'est vrai, mais c'est hors sujet. Tu parles de distinction entre /
et /usr. C'est forcément _après_ que la racine soit montée. Donc
hors sujet.

J'ai surtout l'impression que c'est toi qui mélange un peu ce qu'il
y a dans / et dans /usr. Un système doit pouvoir booter sur / dès lors
qu'il y trouve /bin, /sbin et /etc. Tu peux donc coller dans ces
répertoire ce que tu colles actuellement dans ton initramfs et utiliser
le reste avec du chiffrement. Tu peux aussi utiliser un / chiffré pour
peu que le système sache où chercher ta clef de chiffrement (ce que tu
peux indiquer par une variable openprom ou SRM). Ne me dit surtout pas
qu'il faut la prévoir et la lire, parce que tes scripts initramfs, il
faut aussi les écrire.

Ta si fameuse openprom si ce n'est donner deux trois paramètres au noyau
puis lancer un noyau, que fait elle? Pas grand chose. Sépares bien les
deux évenements: 1, je boote le noyau. 2, je monte la racine. Entre 1 et
2 il y a la place de faire beaucoup de choses.

Qui n'ont pas leur place normalement là. Je rajouterai qu'entre le
montage de la racine (généralement en ro et single user) et le lancement
multiuser, il y a pas mal d'étapes qui devraient contenir ce que tu
essayes de coller en initrd.

On revient à la même chose. Comment tu l'as montée cette racine?
Ensuite, on peut mettre tous les zigouigouis qu'on souhaite dans
le rc., mais ce n'est pas la question.

Ce sont pourtant tes arguments. Lancer des scripts sur un système
qui n'a pas monté sa partition racine. J'essaye de t'expliquer qu'il est
tout à fait possible (et plus fiable) de faire exactement ce que tu veux
en utilisant des scripts rc et un mécanisme un peu mieux foutu.
Je suis d'accord avec toi si tu me dis que sur i386 et amd64, on est
assez vite limité par le hard et que cela apporte des choses. Pour
toutes les autres architectures, c'est faux. D'ailleurs je pense que si
ça apportait quelque chose, les unices proprio auraient _tous_ intégré
un tel système. Au lieu de ça, ils se sont tous orientés vers une
configuration contenue dans une arborescence mémoire (et tous avec un
forth minimal, mais c'est un autre débat). Même Intel s'y est mis.

Entre 1 et 2, tu as le choix. Soit de laisser faire, soit d'intervenir.
L'interêt est là. Que tu trouves ça bancal car tu n'est tombé que sur
des scripts écrit avec les pieds, c'est une chose. Que tu dises que c'est
de la merde patentée, pourquoi pas, mais je suis en désaccord. Que tu
dises que tu puisses dans tous les cas le remplacer par un openprom, là,
c'est soit de la méconnaissance, soit de la mauvaise foi.

Ce n'est pas parce que linux le fait que c'est une bonne chose.

Non. Comme je te le répete, je trouve que c'est une solution élégante
à tout un tas de problèmes, et surtout sur le fait que cela étend de
manière illimitée la manière de booter un système.
D'où mon post sur ce groupe, BSD, qui demande pourquoi d'autres systèmes
ne l'implémentent pas.

A ce sujet, j'ai eu deux réponses:
-l'initrd ne servirait qu'a charger des modules, auquel cas c'est inutile.
-le noyau NetBSD à implémenté en dur dans le code du noyau une option
pour booter sur une partition chiffrée.

Je suis tout à fait d'accord avec le premier cas, sauf qu'un initrd
peut servir à tout un tas d'autres choses que de charger des modules.
Le second semble me dire qu'il y a une réelle nécessité d'intervenir
entre le chargement du noyau et le montage de la racine.

Quelle nécessité ? Tu n'as une nécessité qu'à partir du moment où tu
ne peux spécifier d'une manière ou d'une autre ta méthode de
chiffrement. Si tu colles l'endroit où chercher tes paramètres dans une
variable (du style va chercher sur /dev/qqch), je ne vois pas où est le
problème. Si la variable n'existe pas, le module te demande de spécifier
comme ton script. Où est le problème ?

Je prétends simplement que tous les exemples que tu m'as filé jusqu'à
présent se résolvent facilement avec un truc comme SRM ou Openprom et

Donne moi la solution pour monter ma racine chiffrée.

Je te l'ai donnée. Après, que sous Linux, les types aient décidé de
faire autrement et d'ignorer ce qu'on peut faire avec des techniques de
configuration en arborescence mémoire, c'est un autre problème.

Donne moi la solution pour l'installeur quand tu as plus d'un media
d'installation.

La question ne devrait pas se poser (au moins dans le cas d'un
CDROM). Maintenant, si tu tiens à installer un système au travers d'une
clef USB ou d'une disquette, la philosophie est différente et il faut
effectivement bricoler. Mais ce n'est pas parce qu'on implante des trucs
tordus pour installer un système qu'il faut utiliser ces mêmes trucs
dans l'utilisation courante du même système.

Donne moi la solution pour la clé WPA.

Ton problème est bien la clef WPA. Tu la colles dans ton openprom,
sa console SRM ou ce que tu veux et tu demande à ton pilote wifi d'aller
la lire à cet endroit.

Donne moi la solution pour une racine situé sur un nouveau
périphérique. Genre imaginons sur ta machine, tu installes une carte
PCI qui a besoin d'un firmware qui va te donner un bus USB3 à
temps d'allumage variable qui a de nouveau besoin d'un firmware
pour une grappe en RAID5. Magiquement ton openprom antérieur à la
carte PCI, à l'USB3 et à toutes ces sortes de trucs va te donner
toutes les bonnes options pour charger les firmware, attendre
le tout, et lancer on ne sait comment le raid soft linux? Restons
sérieux.

Justement, restons sérieux. Tu n'as jamais regardé Openprom ni SRM
et tu es en train de le montrer. Tous ces systèmes sont _extensibles_.
Par exemple, j'ai des paramètres dans une SS20 qui me sert à gruiker
qui n'ont _jamais_ été prévus par les concepteurs de la prom 2.25W (en
particulier, j'ai joué avec une carte wifi dans un slot sbus-pcmcia et
justement, j'ai ajouté des paramètres sans aucun problème pour que ça
fonctionne).

Si c'est si facile, pourquoi ne les donnes tu pas?
Ta réponse, c'est "ca serait éventuellement possible". Bien, donc face à
un problème, il faut attendre une solution _a posteriori_,
l'initramfs te donne une solution _a priori_.

Non, et c'est bien ce que j'essaye de te dire, mais tu es
visiblement bouché. Tout ce que ton initramfs fait, tu _peux_ le faire
autrement sur la grande majorité des architectures. Il n'y a pas de a
priori ou a posteriori là-dedans. _Ton_ problème est que _ton_ noyau va
chercher des informations qui sont sur un disque local ou dans ton
initramfs et non dans une arborescence de configuration d'une part, et
que tu ne t'es jamais penché sur un truc comme ça ni sur la flexibilité
que cela peut apporter puisque c'est _accessible_ avant le boot.

Tu as dit _toi-même_ plus haut qu'il valait mieux avoir une seconde
machine sous la main pour corriger l'initramfs en cas de merdoiement.
Rien que ça, c'est problématique et une arborescence de configuration te
permet d'éviter une seconde machine parce que la première reste
accessible (du moins sa partie configuration) sans avoir de système
bootable.

unne détection de l'environnement après le montage de la racine (puisque
tu sembles tenir à ce point).

Non, je parle de manière générale. Des exemples de ce que l'on
peut faire avec un initramfs, il y en a pleins. Largement plus
nombreux que ce que je peux imaginer. Et c'est justement là ou
intervient la finesse de son utilisation. Ce n'est pas un
système figé, c'est un système parfaitement modulable pour le
plier à tes besoins.
Sans ce système, tu es bloqué aux quelques cas d'utilisation
prévus par les développeurs noyaux.
D'où la myriade d'options passées en paramètre au noyau lui
permettant de trouver sa racine. Mais par définition, cette
série d'options est _limitée_. L'initramfs t'apporte la
solution.

Encore non. Pour accéder à une racine chiffrée au travers d'un
protocole à la con, tu as forcément un truc qui sert de pilote, et ce
truc, quelqu'un l'a écrit. Après, que tu l'utilises au travers d'un
initramfs ou de tout autre mécanisme ne regarde que toi. Je prétends
simplement que si le truc est écrit correctement (c'est-à-dire pas
gruiké par un dev sur un coin de table et à l'arrache), ce bout de code
doit pouvoir prendre sa configuration à un endroit logique. Et je me
répète : si la machine a une arborescence de configuration, il n'y a
aucune raison de la mettre ailleurs (exemple : les nombreux drivers de
solaris attaquant la console prenant leurs paramètres directement dans
l'openprom). Si maintenant elle n'a pas un tel mécaniquem, j'arrive
encore à comprendre qu'on veuille l'émuler par un initramfs ou un autre
mécanisme, mais je prétends que ce n'est pas nécessaire dans l'immense
majorité des cas, parce que tout cela pourrait être fait par un script rc
bien senti. Ne me ressort surtout pas le coup de la partition racine en
wifi avec une clef WPA, parce que là, le problème provient de
l'architecture du PC qui oblige à des contorsions (encore que tu
pourrais avoir ta clef WPA sur une clef USB et indiquer directement au
noyau que la clef est dans tel fichier de ta clef USB).

[1]Comme par exemple de faire une détection bluetooth pour savoir
si _mon_ téléphone est dans un environ proche. Si je suis là, ça
démarre normalement. Si je ne suis pas là, cela veut dire que c'est
une personne non autorisée qui allume l'ordinateur. Et là, il est
possible d'agir. C'est de la fausse sécurité, mais ça coute pas cher :)

Rien ne t'empêche de le faire juste après le montage de la racine et
de coller un shutdown immédiat (avant la bascule en init 2, 3, 4 ou 5 si
on continue de causer Linux).

Un autre principe consiste à télécharger la clé de la racine chiffrée
sur mon téléphone bluetooth. Ou tout autre chose. Systématiquement
tu réduis les cas d'utilisations sans voir ce que cela peut apporter.

œ Non, c'est toi qui est braqué sur ton initramfs en refusant de voir
que tu pourrais tout à fait faire autrement. J'ai fait de la prestation
dans une grosse boîte qui bossait avec des clusters sous OpenVMS 8.2.
La technique de boot ressemblait un peu à la tienne. Pour des raisons de
sécurité, toutes les machines étaient rebootées à 7h00 _tous_ les
jours. Chaque machine ne bootait sur son disque interne chiffré que si
elle trouvait un serveur de clef sur son réseau local. Bizarrement, la
seule configuration était deux variables de la console SRM, l'une avec
l'adresse DECNET du serveur de clef, l'autre avec l'adresse DECNET du
client. Ça fonctionnait parfaitement sans jamais avoir d'initramfs ou
d'autre procédé plus abscons encore. Maintenant, tu es tellement convaincu
qu'initramfs est _la_ solution que je vais te laisser discuter tout seul,
j'ai des mutexes à débugguer.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Kevin Denis <kevin@nowhere.invalid> wrote:

[...]
-le noyau NetBSD à implémenté en dur dans le code du noyau une option
pour booter sur une partition chiffrée.

Non ca n'est pas du tout ca qui a ete dit. J'ai dis que NetBSD avait
implemente quelque chose qui ressemblait, entre autre pour pouvoir
avoir un / crypte, mais je n'ai jamais dit que c'etait dans le kernel.
En l'occurence c'est dans init.

--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Tu as bien avoué plus haut avoir écrit toi-même tes scripts
initramfs. Je ne vois pas la différence.

La différence est énorme. Entre attendre qu'un dev noyau écrive le code
qui colle à tes besoins ou le faire toi même tout de suite, c'est
énorme.

Tu ne m'as pas donné un argument dans lequel initrd (ou initramfs)
était indispensable à un fonctionnement donné sur une machine de prod

Tu évacues le problème encore une fois. "Sur mes machines _de prod_ je
n'ai pas besoin d'initrd, alors c'est inutile dans tous les cas".

Non, je te dis que la racine est indiquée dans un coin de la nvram
et que le noyau normalement constitué va chercher ses paramètres dans
l'arborescence de la nvram. C'est ce qui se passe sous Sparc, sous Mac
dans une certaine mesure, sous IA64 et prédécesseurs (VAX et Alpha) et
sous bien d'autres classes de serveurs.

Diantre. Sur PC, le noyau va le chercher dans /proc/cmdline.
Mais pose toi la question. Une fois que tu as une variable, tu en fais
_quoi_?
Et by the way, peux tu me donner le /proc/cmdline d'une machine linux
sous sparc par exemple? Juste pour vérifier un truc.

Openprom -> boot loader -> kernel -> montage de openpromfs ->
récupération des paramètres (racine, protocole d'accès à la racine, mot
de passe le cas échéant...) -> montage de la racine / en ro -> lancement des
scripts système -> montage des autres partitions et remontage de la racine
en rw -> basculement en multiuser

Indique moi la différence avec
bootloader -> kernel+arguments -> lecture des arguments (racine, protocole
d'accès à la racine, mot de passe le cas échéant...) -> montage de la
racine / en ro etc..

Tu peux aussi utiliser un / chiffré pour
peu que le système sache où chercher ta clef de chiffrement (ce que tu
peux indiquer par une variable openprom ou SRM).

Nous y voilà. Tu vois, tu y arrives. "Pour peu que le système sache ou
chercher la clef de chiffrement". Eh bien dans beaucoup de cas, le système
il peut _peu_. (ceci dit, je ne voudrais pas ergoter, mais coller en dur
ta clé de chiffrement de disque dans une variable locale à la machine, bof.)

Ne me dit surtout pas
qu'il faut la prévoir et la lire, parce que tes scripts initramfs, il
faut aussi les écrire.

Exactement. Tu commences à saisir la différence entre une solution
_a priori_ et une solution _a posteriori_. La solution à priori, c'est
ce à quoi a pensé le dev noyau. Genre, le noyau sait lire les variables
et sait comment les traiter. Par exemple, s'il lit "root=/dev/hda3 ro"
Le noyau monte sa racine. Le jour ou un dev noyau se sera penchée sur
les paramètres "channel wpakey=ma_cle_wifi mode=tkip-aes", on les
mettra dans l'openprom ou le bootloader.

Maintenant, que fais tu lorsque tu es dans un cas auquel n'a pas pensé
le développeur noyau? C'est une vraie question.

Quand je te parle d'extension des différentes manières de booter,
c'est bien parceque tu peux les écrire tes initramfs. C'est libre,
c'est open, c'est à ta guise. Tu n'es pas réduit aux 'x' variables
prévues par le développeur d'un pilote.

Ce sont pourtant tes arguments. Lancer des scripts sur un système
qui n'a pas monté sa partition racine.

Exactement. C'est ce que j'appelle "ajouter de l'intelligence".

J'essaye de t'expliquer qu'il est
tout à fait possible (et plus fiable) de faire exactement ce que tu veux
en utilisant des scripts rc et un mécanisme un peu mieux foutu.

Lequel? Ajouter une variable? Qui dira quoi? Et si la variable n'est
pas prévue? Je reprends le cas de la racine over httpfs. Quelle
valeur à mettre dans quelle variable? Cette variable sera lue (et
surtout prise en compte) par _qui_? Personne? Donc la racine over
httpfs est impossible? Fin de l'histoire.

Fin de l'histoire? Vraiment?
http://httpfs.sourceforge.net/net_boot.htm

Je suis d'accord avec toi si tu me dis que sur i386 et amd64, on est
assez vite limité par le hard et que cela apporte des choses. Pour
toutes les autres architectures, c'est faux.

La seule chose que tu apportes avec openprom c'est que tu peux affecter
des valeurs à des variables. Si le noyau ne sait pas intérpréter tes
variables, il n'en fera _rien_.

Quelle nécessité ? Tu n'as une nécessité qu'à partir du moment où tu
ne peux spécifier d'une manière ou d'une autre ta méthode de
chiffrement. Si tu colles l'endroit où chercher tes paramètres dans une
variable (du style va chercher sur /dev/qqch),

Que tu précises _comment_? Encore une fois avec Variable=Valeur? Retombons
sur du concret. On parle de racine chiffrée, tu me dis que tu peux mettre
la clé dans une variable openprom. Bien bien bien. Ecris le moi. Tu ne
peux pas? Pourquoi? Parceque ce n'est pas prévu? Ah oui, mais ça "serait
possible", il faut juste attendre qu'un noyau soit développé afin qu'il
sache comment appréhender cette variable.

Tu commences à saisir l'interêt d'un initramfs? Ta variable, d'où qu'elle
provienne, tu peux agir avec.

Si la variable n'existe pas, le module te demande de spécifier
comme ton script. Où est le problème ?

-Si la variable n'existe pas, le module ne sait pas comment faire. Donc
problème.
-Si la variable n'existe pas, je peux écrire un script qui saura
comment l'exploiter et je monte ma racine. Donc solution.

Je prétends simplement que tous les exemples que tu m'as filé jusqu'à
présent se résolvent facilement avec un truc comme SRM ou Openprom et

Donne moi la solution pour monter ma racine chiffrée.

Je te l'ai donnée.

De manière aussi concrète que ta racine nfs? Non. Sais tu pourquoi?

Donne moi la solution pour l'installeur quand tu as plus d'un media
d'installation.

La question ne devrait pas se poser (au moins dans le cas d'un
CDROM).

Tu évacues encore le problème. Dès que c'est génant. Hop, on le
fait disparaitre.
(et by the way, la slackware utilises deux CD d'installations. C'est la
faute de la slackware? Bien sur, bien sur).

Donne moi la solution pour la clé WPA.

Ton problème est bien la clef WPA. Tu la colles dans ton openprom,
sa console SRM ou ce que tu veux et tu demande à ton pilote wifi

Eh bien on avance. Tu le demandes _comment_ à ton pilote wifi?
kevin@zipslack:/usr/src/linux/Documentation$ grep -iE "WEP|WPA|wifi" kernel-parameters.txt
kevin@zipslack:/usr/src/linux/Documentation$
La réponse, c'est que tu ne le demandes pas, car tu ne le peux pas.

Justement, restons sérieux. Tu n'as jamais regardé Openprom ni SRM
et tu es en train de le montrer.

J'en ai vu d'autres. Ca reste limité au passage de paramètres
variable=valeur. Selon toi, c'est la panacée universelle et tout les
constructeurs devraient le faire. D'une part, même avec une architecture
de bouse comme le PC on sait passer des valeurs au noyau, et d'autre
part, je ne vois toujours rien de révolutionnaire.

Non, et c'est bien ce que j'essaye de te dire, mais tu es
visiblement bouché. Tout ce que ton initramfs fait, tu _peux_ le faire
autrement sur la grande majorité des architectures. Il n'y a pas de a
priori ou a posteriori là-dedans.

Relis bien les phrases du dessus. Avec l'initramfs je suis capable de
répondre à des problèmes qui ne sont même jamais venus à l'esprit
du développeur noyau ou du pilote.
Face à un problème de ce genre, tu peux attendre benoitement qu'un dev
vienne t'écrire le bout de code nécessaire à la résolution à ton
problème en évaluant une variable quelconque, soit utiliser initramfs
et solutionner tout de suite tes problèmes (avec aussi une variable
si ça te chante).

_Ton_ problème est que _ton_ noyau va
chercher des informations qui sont sur un disque local ou dans ton
initramfs et non dans une arborescence de configuration d'une part, et
que tu ne t'es jamais penché sur un truc comme ça ni sur la flexibilité
que cela peut apporter puisque c'est _accessible_ avant le boot.

Tu as dit _toi-même_ plus haut qu'il valait mieux avoir une seconde
machine sous la main pour corriger l'initramfs en cas de merdoiement.

De la même manière que si ton noyau est moisi, tu as besoin d'une seconde
machine pour en recompiler un. Mais tu continues de t'enferrer dans
la rengaine "ben si c'est moisi alors c'est pas bien". Oui, je suis
d'accord avec toi, cent fois oui. Si c'est pas bien, alors c'est pas bien.
On peut discuter, maintenant?

Rien que ça, c'est problématique et une arborescence de configuration te
permet d'éviter une seconde machine parce que la première reste
accessible (du moins sa partie configuration) sans avoir de système
bootable.

Tu fais le procès du bootloader et non de l'initramfs. Tant que mon
bootloader est accessible, tout est rattrapable. Jusqu'a lancer un
autre noyau, par exemple.

Encore non. Pour accéder à une racine chiffrée au travers d'un
protocole à la con, tu as forcément un truc qui sert de pilote, et ce
truc, quelqu'un l'a écrit.

Exactement. Et il n'a peut être pas pensé à tout. Et peut être pas à
tous les protocoles à la con, comme tu dis. Donc soit tu es limité
aux quelques cas d'utilisation auquel à pensé le dev, soit tu évolues
avec un initramfs.

Après, que tu l'utilises au travers d'un
initramfs ou de tout autre mécanisme ne regarde que toi. Je prétends
simplement que si le truc est écrit correctement (c'est-à-dire pas
gruiké par un dev sur un coin de table et à l'arrache), ce bout de code
doit pouvoir prendre sa configuration à un endroit logique.

Et donc prévu par le développeur. Merci de ton soutien. Et si tu veux
faire un truc non prévu par le développeur? Et si tu as besoin
d'autre chose?

Et je me
répète : si la machine a une arborescence de configuration, il n'y a
aucune raison de la mettre ailleurs

En fait tu confonds bootloader et initramfs. L'initramfs sait aussi
utiliser (éventuellement) les paramètres passés par le bootloader, tout
comme il est capable de s'appuyer sur une arborescence de configuration,
oui, pas de problèmes, la question n'est pas là.

Si maintenant elle n'a pas un tel mécaniquem, j'arrive
encore à comprendre qu'on veuille l'émuler par un initramfs

Non. Ton openprom, ça n'est rien d'autre que l'équivalent de la ligne
append="..." des bootloaders sous PC. La ligne append est passée en
argument au noyau qui va la lire, c'est tout.

mécanisme, mais je prétends que ce n'est pas nécessaire dans l'immense
majorité des cas, parce que tout cela pourrait être fait par un script rc
bien senti.

rc qui est accessible, une fois de plus, seulement une fois la racine
montée. On s'en fiche de ce qui est fait dans les rc. Je te parle de
monter la racine.

Ne me ressort surtout pas le coup de la partition racine en
wifi avec une clef WPA,

encore une fois, pouf, on évacue le problème.

parce que là, le problème provient de l'architecture du PC

En quoi ai-je parlé des PC nom de nom! Parceque les mac PPC ne savent pas
faire du wifi peut être? Tes sparcs, elles font du wifi? Comment
répond tu à ce problème? Avec une variable magique?

qui oblige à des contorsions (encore que tu
pourrais avoir ta clef WPA sur une clef USB et indiquer directement au
noyau que la clef est dans tel fichier de ta clef USB).

Que tu indiques comment?

Non, c'est toi qui est braqué sur ton initramfs en refusant de voir
que tu pourrais tout à fait faire autrement.

Je te pose des questions concrètes, tes seules réponses sont "ça _pourrait_"
se faire différemment (et je passe sur le rant concernant les PC qui n'a
rien à voir).
Avec l'initramfs, je peux. Aujourd'hui. Tout de suite.

Maintenant, tu es tellement convaincu
qu'initramfs est _la_ solution

Non, ce n'est pas la solution. C'est une _ouverture_ qui te démultiplie
les manières de booter un système et qui te sors du carcan des quelques
variables proposées par les devs noyaux.

que je vais te laisser discuter tout seul,
j'ai des mutexes à débugguer.

Je te laisse, j'ai une recette de pates à la carbonara à débugger.
--
Kevin

Le 07-12-2008, Manuel Bouyer <bouyer@nerim.net> a écrit :

-le noyau NetBSD à implémenté en dur dans le code du noyau une option
pour booter sur une partition chiffrée.

Non ca n'est pas du tout ca qui a ete dit. J'ai dis que NetBSD avait
implemente quelque chose qui ressemblait, entre autre pour pouvoir
avoir un / crypte, mais je n'ai jamais dit que c'etait dans le kernel.
En l'occurence c'est dans init.

Et init est situé ou?
--
Kevin

Le 08-12-2008, ? propos de
Re: Boot des différents BSD,
Kevin Denis ?crivait dans fr.comp.os.bsd :

Le 07-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :

Tu as bien avoué plus haut avoir écrit toi-même tes scripts
initramfs. Je ne vois pas la différence.

La différence est énorme. Entre attendre qu'un dev noyau écrive le code
qui colle à tes besoins ou le faire toi même tout de suite, c'est
énorme.

Tu ne m'as pas donné un argument dans lequel initrd (ou initramfs)
était indispensable à un fonctionnement donné sur une machine de prod

Tu évacues le problème encore une fois. "Sur mes machines _de prod_ je
n'ai pas besoin d'initrd, alors c'est inutile dans tous les cas".

Ce n'est pas ce que je dis. Relis-moi _attentivement_ !

Non, je te dis que la racine est indiquée dans un coin de la nvram
et que le noyau normalement constitué va chercher ses paramètres dans
l'arborescence de la nvram. C'est ce qui se passe sous Sparc, sous Mac
dans une certaine mesure, sous IA64 et prédécesseurs (VAX et Alpha) et
sous bien d'autres classes de serveurs.

Diantre. Sur PC, le noyau va le chercher dans /proc/cmdline.
Mais pose toi la question. Une fois que tu as une variable, tu en fais
_quoi_?
Et by the way, peux tu me donner le /proc/cmdline d'une machine linux
sous sparc par exemple? Juste pour vérifier un truc.

Il n'y a pas que Linux dans la vie (et heureusement), et ce n'est
pas parce linux fonctionne de la même façon partout (donc avec le
facteur limitant de l'architecture la plus merdique), que c'est bien.

Openprom -> boot loader -> kernel -> montage de openpromfs ->
récupération des paramètres (racine, protocole d'accès à la racine, mot
de passe le cas échéant...) -> montage de la racine / en ro -> lancement des
scripts système -> montage des autres partitions et remontage de la racine
en rw -> basculement en multiuser

Indique moi la différence avec
bootloader -> kernel+arguments -> lecture des arguments (racine, protocole
d'accès à la racine, mot de passe le cas échéant...) -> montage de la
racine / en ro etc..

Tu oublies ton fameux initrd que je n'ai pas dans ma technique de
boot.

Tu peux aussi utiliser un / chiffré pour
peu que le système sache où chercher ta clef de chiffrement (ce que tu
peux indiquer par une variable openprom ou SRM).

Nous y voilà. Tu vois, tu y arrives. "Pour peu que le système sache ou
chercher la clef de chiffrement". Eh bien dans beaucoup de cas, le système
il peut _peu_. (ceci dit, je ne voudrais pas ergoter, mais coller en dur
ta clé de chiffrement de disque dans une variable locale à la machine, bof.)

Tu pourrais très bien y coller l'emplacement de ton fichier sur un
device ou un serveur de clef si le désirais. C'est _exactement_ ce que
j'ai écrit plus haut.

Ne me dit surtout pas
qu'il faut la prévoir et la lire, parce que tes scripts initramfs, il
faut aussi les écrire.

Exactement. Tu commences à saisir la différence entre une solution
_a priori_ et une solution _a posteriori_. La solution à priori, c'est
ce à quoi a pensé le dev noyau. Genre, le noyau sait lire les variables
et sait comment les traiter. Par exemple, s'il lit "root=/dev/hda3 ro"
Le noyau monte sa racine. Le jour ou un dev noyau se sera penchée sur
les paramètres "channel wpakey=ma_cle_wifi mode=tkip-aes", on les
mettra dans l'openprom ou le bootloader.

Maintenant, que fais tu lorsque tu es dans un cas auquel n'a pas pensé
le développeur noyau? C'est une vraie question.

Là, tu commences à m'énerver. Un pilote wifi, ça nécessite une clef
WPA (ou au moins un fichier de conf). Il n'y a aucune raison de ne pas
passer a priori les paramètres au système lors du boot si on veut une
racine montée en NFS over Wifi. Ça va un peu mieux ? Si le pilote du
noyau va chercher ça dans un fichier (et uniquement dans un fichier),
c'est un problème de conception dudit module, rien de plus.

Quand je te parle d'extension des différentes manières de booter,
c'est bien parceque tu peux les écrire tes initramfs. C'est libre,
c'est open, c'est à ta guise. Tu n'es pas réduit aux 'x' variables
prévues par le développeur d'un pilote.

Un pilote bien écrit devrait commencer par traiter des variables
disponibles au boot. S'il ne le fait pas, c'est encore un problème de
conception. Utiliser un initramfs est simplement un truc fait pour
contourner ce problème de conception.

Ce sont pourtant tes arguments. Lancer des scripts sur un système
qui n'a pas monté sa partition racine.

Exactement. C'est ce que j'appelle "ajouter de l'intelligence".

Et c'est ce que je prétends être une connerie dans l'immense
majorité des cas.

J'essaye de t'expliquer qu'il est
tout à fait possible (et plus fiable) de faire exactement ce que tu veux
en utilisant des scripts rc et un mécanisme un peu mieux foutu.

Lequel? Ajouter une variable? Qui dira quoi? Et si la variable n'est
pas prévue? Je reprends le cas de la racine over httpfs. Quelle
valeur à mettre dans quelle variable? Cette variable sera lue (et
surtout prise en compte) par _qui_? Personne? Donc la racine over
httpfs est impossible? Fin de l'histoire.

Fin de l'histoire? Vraiment?
http://httpfs.sourceforge.net/net_boot.htm

Mais tu le fais exprès ? Qui est-ce qui va écrire ton fameux script
dans ton initramfs ? Avec quels paramètres ? Le problème est exactement
le même sauf que tu ne colles ni le script ni les paramètres dans un
initramfs. Donc tu peux modifier tes paramètres s'il le faut sans avoir
une machine bootée.

Je suis d'accord avec toi si tu me dis que sur i386 et amd64, on est
assez vite limité par le hard et que cela apporte des choses. Pour
toutes les autres architectures, c'est faux.

La seule chose que tu apportes avec openprom c'est que tu peux affecter
des valeurs à des variables. Si le noyau ne sait pas intérpréter tes
variables, il n'en fera _rien_.

Et s'il ne peut pas utiliser les variables de ton fameux script ? Le
problème est le même !

Quelle nécessité ? Tu n'as une nécessité qu'à partir du moment où tu
ne peux spécifier d'une manière ou d'une autre ta méthode de
chiffrement. Si tu colles l'endroit où chercher tes paramètres dans une
variable (du style va chercher sur /dev/qqch),

Que tu précises _comment_? Encore une fois avec Variable=Valeur? Retombons
sur du concret. On parle de racine chiffrée, tu me dis que tu peux mettre
la clé dans une variable openprom. Bien bien bien. Ecris le moi. Tu ne
peux pas? Pourquoi? Parceque ce n'est pas prévu? Ah oui, mais ça "serait
possible", il faut juste attendre qu'un noyau soit développé afin qu'il
sache comment appréhender cette variable.

Arrête, tu t'enfonces. Je ne me suis jamais penché sur le problème
typiquement linuxien (parce que pour des machines de prod, linux est de
plus en plus à la ramasse, mais c'est un autre débat...), mais je peux
te dire que si je devais regarder de près, ça ne me prendrait pas plus
longtemps qu'essayer de bricoler un initramfs. Tes variables sont
accessibles au travers d'une API bien documentée sous Linux. Demander à
un bout de noyau de lire ce qui est dans la hiérarchie openprom à la
place de ce qui est passé sur la ligne de commande (ou ailleurs) est du
domaine du trivial.

Tu commences à saisir l'interêt d'un initramfs? Ta variable, d'où qu'elle
provienne, tu peux agir avec.

Non, je n'en vois toujours pas l'intérêt (au moins dans l'immense
majorité des cas). Je vois simplement que dans certains cas, il est
difficile de faire autrement sur un (p)pc parce que l'architecture est
faite de telle manière qu'il n'est pas possible d'utiliser une
hiérarchie de configuration (et ses scripts).

Si la variable n'existe pas, le module te demande de spécifier
comme ton script. Où est le problème ?

-Si la variable n'existe pas, le module ne sait pas comment faire. Donc
problème.

Idem dans le cas initramfs. Et si le noyau ne sait pas utiliser une
variable, c'est un problème de modèle de développement.

-Si la variable n'existe pas, je peux écrire un script qui saura
comment l'exploiter et je monte ma racine. Donc solution.

Et les scripts dans les hiérarchies de conf, c'est de la roupie de
sansonnet ?

Je prétends simplement que tous les exemples que tu m'as filé jusqu'à
présent se résolvent facilement avec un truc comme SRM ou Openprom et

Donne moi la solution pour monter ma racine chiffrée.

Je te l'ai donnée.

De manière aussi concrète que ta racine nfs? Non. Sais tu pourquoi?

Donne moi la solution pour l'installeur quand tu as plus d'un media
d'installation.

La question ne devrait pas se poser (au moins dans le cas d'un
CDROM).

Tu évacues encore le problème. Dès que c'est génant. Hop, on le
fait disparaitre.
(et by the way, la slackware utilises deux CD d'installations. C'est la
faute de la slackware? Bien sur, bien sur).

Tu me parles toujours d'installation, je te parle d'utilisation
_normale_. Maintenant, je prétends qu'aucun système au monde n'a besoin
de plus d'un CD pour une installation minimale (réseau compris) en vue
d'installer le reste. Que slack, debian, solaris, openvms fassent autre
chose, c'est leur problème et non le mien. Enfin si, c'est aussi le mien
parce que lorsque l'installeur merdoie, c'est pour ma pomme. Rien
n'empêche d'avoir un installeur qui monte une racine minimale d'un CD
(dans le cas d'une installation CDrom puisque c'est de cela que tu
parles) et qui permette d'installer le reste du système, plutôt qu'un
truc qui bricole directement une image mémoire. J'ai assez joué avec des
boot.img, root.img et consorts pour juger que le système est _foireux_
par essence. Installe un Solaris sparc pour voir. Il y a un noyau par
architecture et tu peux de démerder avec le seul premier CD _quelle que
soit_ l'architecture sparc de destination (32 ou 64 bits). Le jour où linux
sera à l'installation capable de faire ça, on aura progressé.

Donne moi la solution pour la clé WPA.

Ton problème est bien la clef WPA. Tu la colles dans ton openprom,
sa console SRM ou ce que tu veux et tu demande à ton pilote wifi

Eh bien on avance. Tu le demandes _comment_ à ton pilote wifi?
kevin@zipslack:/usr/src/linux/Documentation$ grep -iE "WEP|WPA|wifi" kernel-parameters.txt
kevin@zipslack:/usr/src/linux/Documentation$
La réponse, c'est que tu ne le demandes pas, car tu ne le peux pas.

Encore une fois parce que le pilote est écrit n'importe comment (et
certainement parce que le dev du pilote en question développe sur PC et
n'a aucune idée de ce qui peut se passer ailleurs).

Justement, restons sérieux. Tu n'as jamais regardé Openprom ni SRM
et tu es en train de le montrer.

J'en ai vu d'autres. Ca reste limité au passage de paramètres
variable=valeur.

Non. Tu as sauter des specs. Sur des SS20, j'écrivais déjà des
scripts dans Openprom. M'étonnerais que ça ait disparu depuis.

Selon toi, c'est la panacée universelle et tout les
constructeurs devraient le faire. D'une part, même avec une architecture
de bouse comme le PC on sait passer des valeurs au noyau, et d'autre
part, je ne vois toujours rien de révolutionnaire.

Une hiérarchie de configuration ne sert pas qu'à passer des
paramètres au noyau.

Non, et c'est bien ce que j'essaye de te dire, mais tu es
visiblement bouché. Tout ce que ton initramfs fait, tu _peux_ le faire
autrement sur la grande majorité des architectures. Il n'y a pas de a
priori ou a posteriori là-dedans.

Relis bien les phrases du dessus. Avec l'initramfs je suis capable de
répondre à des problèmes qui ne sont même jamais venus à l'esprit
du développeur noyau ou du pilote.

Le pilote prend un certain nombre de paramètres pour exploiter le
matériel. Soit le paramètre est prévu, soit il ne l'est pas, et ce
indépendamment de la position de ladite variable. Donc ton problème
n'en est pas un.

Exemple : Solaris 9 traite dans l'ordre
- variable openprom (résolution de l'écran)
- configuration dans /etc

et ça n'a jamais posé aucun problème. Le seul problème est d'écrire
_correctement_ les pilotes de base.

Face à un problème de ce genre, tu peux attendre benoitement qu'un dev
vienne t'écrire le bout de code nécessaire à la résolution à ton
problème en évaluant une variable quelconque, soit utiliser initramfs
et solutionner tout de suite tes problèmes (avec aussi une variable
si ça te chante).

Solutionner n'existe par, on dit résoudre en français. Maintenant,
je ne vais pas me répéter une fois de plus.

_Ton_ problème est que _ton_ noyau va
chercher des informations qui sont sur un disque local ou dans ton
initramfs et non dans une arborescence de configuration d'une part, et
que tu ne t'es jamais penché sur un truc comme ça ni sur la flexibilité
que cela peut apporter puisque c'est _accessible_ avant le boot.

Tu as dit _toi-même_ plus haut qu'il valait mieux avoir une seconde
machine sous la main pour corriger l'initramfs en cas de merdoiement.

De la même manière que si ton noyau est moisi, tu as besoin d'une seconde
machine pour en recompiler un. Mais tu continues de t'enferrer dans
la rengaine "ben si c'est moisi alors c'est pas bien". Oui, je suis
d'accord avec toi, cent fois oui. Si c'est pas bien, alors c'est pas bien.
On peut discuter, maintenant?

Change pas de débat. Tu me parles d'une configuration de pilotes au
travers d'initrd ou initramfs, pas de recompilation de noyau. Je vais
enfoncer le clou :

1/ initramfs moisi à l'extrême : il faut une autre machine si la
première refuse de booter
2/ hiérarchie foirée : tu la modifies sur la même machine.

C'est plus clair ?

Rien que ça, c'est problématique et une arborescence de configuration te
permet d'éviter une seconde machine parce que la première reste
accessible (du moins sa partie configuration) sans avoir de système
bootable.

Tu fais le procès du bootloader et non de l'initramfs. Tant que mon
bootloader est accessible, tout est rattrapable. Jusqu'a lancer un
autre noyau, par exemple.

Non. Parce qu'avec certaines linuxeries dont je tairai les noms, tu
peux te retrouver avec un noyau remplacé par un autre dont le initrd est
foiré et tu te retrouves avec un panic au boot (sans forcément avoir le
dernier noyau accessible si tu as un bon vieux lilo écrasé par une mise
à jour).

Encore non. Pour accéder à une racine chiffrée au travers d'un
protocole à la con, tu as forcément un truc qui sert de pilote, et ce
truc, quelqu'un l'a écrit.

Exactement. Et il n'a peut être pas pensé à tout. Et peut être pas à
tous les protocoles à la con, comme tu dis. Donc soit tu es limité
aux quelques cas d'utilisation auquel à pensé le dev, soit tu évolues
avec un initramfs.

Non, parce que le protocole à la con est géré par un pilote à
configurer !

Après, que tu l'utilises au travers d'un
initramfs ou de tout autre mécanisme ne regarde que toi. Je prétends
simplement que si le truc est écrit correctement (c'est-à-dire pas
gruiké par un dev sur un coin de table et à l'arrache), ce bout de code
doit pouvoir prendre sa configuration à un endroit logique.

Et donc prévu par le développeur. Merci de ton soutien. Et si tu veux
faire un truc non prévu par le développeur? Et si tu as besoin
d'autre chose?

Si tu utilises un protocole non géré par un bout du système, tu fais
comment ? Parce que c'est de ce que tu parles !

Et je me
répète : si la machine a une arborescence de configuration, il n'y a
aucune raison de la mettre ailleurs

En fait tu confonds bootloader et initramfs. L'initramfs sait aussi
utiliser (éventuellement) les paramètres passés par le bootloader, tout
comme il est capable de s'appuyer sur une arborescence de configuration,
oui, pas de problèmes, la question n'est pas là.

Premièrement, je ne confonds rien du tout; deuxièmement, je ne parle
pas de paramètres passés par un bootloader. Je parle aussi de scripts
par exemple, mais c'est tellement facile d'éluder le problème...

Si maintenant elle n'a pas un tel mécaniquem, j'arrive
encore à comprendre qu'on veuille l'émuler par un initramfs

Non. Ton openprom, ça n'est rien d'autre que l'équivalent de la ligne
append="..." des bootloaders sous PC. La ligne append est passée en
argument au noyau qui va la lire, c'est tout.

Raté. Essaie encore une fois.

mécanisme, mais je prétends que ce n'est pas nécessaire dans l'immense
majorité des cas, parce que tout cela pourrait être fait par un script rc
bien senti.

rc qui est accessible, une fois de plus, seulement une fois la racine
montée. On s'en fiche de ce qui est fait dans les rc. Je te parle de
monter la racine.

C'est un peu facile de couper ce qui précède. Je t'ai expliqué dans
ce que tu as coupé comment faire avec un script rc. Je n'ai jamais dit
que le script rc était accessible sans avoir / montée.

Ne me ressort surtout pas le coup de la partition racine en
wifi avec une clef WPA,

encore une fois, pouf, on évacue le problème.

Je n'ai pas évacué le problème comme tu as évacué mes explications.

parce que là, le problème provient de l'architecture du PC

En quoi ai-je parlé des PC nom de nom! Parceque les mac PPC ne savent pas
faire du wifi peut être? Tes sparcs, elles font du wifi? Comment
répond tu à ce problème? Avec une variable magique?

Simplement. J'ai écrit un module pour une RT5200 (au travers d'un bridge
sbus-pcmcia) qui se branchait sur un openSolaris et qui prenait ses
paramètres dans l'openprom. Le module est un peu gruiké, mais ça
fonctionne.

qui oblige à des contorsions (encore que tu
pourrais avoir ta clef WPA sur une clef USB et indiquer directement au
noyau que la clef est dans tel fichier de ta clef USB).

Que tu indiques comment?

Avec une bête variable du style de celles qu'on utilise pour
booter sur sparc, quelle question ?

WPA_FILE=/pci@1f,0/pci@1,1/ide@3/disk@0,0:a[wpa.conf]
WPA_FILE=/pci@1f,0/pci@1,1/usb@3/usb@0,0:wpa.conf

Non, c'est toi qui est braqué sur ton initramfs en refusant de voir
que tu pourrais tout à fait faire autrement.

Je te pose des questions concrètes, tes seules réponses sont "ça _pourrait_"
se faire différemment (et je passe sur le rant concernant les PC qui n'a
rien à voir).
Avec l'initramfs, je peux. Aujourd'hui. Tout de suite.

Maintenant, tu es tellement convaincu
qu'initramfs est _la_ solution

Non, ce n'est pas la solution. C'est une _ouverture_ qui te démultiplie
les manières de booter un système et qui te sors du carcan des quelques
variables proposées par les devs noyaux.

En utilisant les mêmes modules au travers des mêmes variables de
configuration.

que je vais te laisser discuter tout seul,
j'ai des mutexes à débugguer.

Je te laisse, j'ai une recette de pates à la carbonara à débugger.

C'est bien. Tu demandais pourquoi les dev des *BSD n'ont pas quelque
chose de similaire à initrd/initramfs de Linux, je te réponds "parce que
ce n'est pas nécessaire" dans la grande majorité des cas. J'ai donc répondu
à la question et argumenté. Fin de la discussion en ce qui me concerne.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.