Le 06-12-2008, JKB 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:
-racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur.
Je ne vois pas en quoi le fait d'avoir un noyau statique empêcherait
de demander un mot de passe.
Deux solutions: Un, tu met le mot de passe en dur dans le noyau et là, le
chiffrement devient inutile. Deux, tu demandes aux développeurs noyaux
d'insérer un bout de code qui va aller demander le mot de passe à
l'utilisateur.
Le second cas fonctionne, puisque NetBSD semble agir comme cela, mais
je trouve ça lourd, compliqué et pesant. Est-ce au développeur noyau
d'écrire un bout de code demandant un mot de passe? Et si je veux le
traduire en swahili, il faut faire un bug report? Et si je veux aller
chercher le mot de passe sur une clé USB?
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
J'ai des grappes de serveurs qui fonctionnent comme ça (des Txxx de
chez Sun) avec des noyaux statiques et ça ne pose strictement aucune
problème. De toute façon, tant que la racine n'est pas montée, je ne
vois pas ce que tu espères faire de ton système...
Là, j'ai une machine full USB avec lecteur CD, disque, clés, etc..
Effectivement, je peux mettre un timer de 2mn afin d'être sur que le
bon périphérique racine apparaisse, ou bien je peux attendre le
premier qui monte sans garantie que ce soit le bon. (paramètres rootwait
et rootdelay chez linux). C'est juste long, très long. S'il est
possible d'injecter un peu d'intelligence dans le processus de montage
de la racine, pourquoi s'en priver.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en
statique ? Et la réponse n'est pas une taille maximale de noyau, parce
que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas
chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur
un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que
ça. L'initramfs permet donc de répondre à ces nouvelles problématiques
de manière judicieuse.
Je ne vois toujours pas en quoi cela _interdit_ de coller en dur
ce qu'il faut pour accéder à sa racine (pilote hard et fs).
Parcequ'avoir un pilote hard et le fs en dur n'est tout simplement pas
suffisant. De plus, tu te trompes de problématique, l'aspect judicieux
de l'initrd ne réside pas dans la possibilité de mettre des modules
mais dans la possibilité que tu as, toi, de pouvoir scripter les
étapes successives permettant de monter la racine.
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Vouloir
absolument booter un linux (puisque c'est aussi de ça qu'on parle) sur
une machine de prod avec un noyau minimal et un système abscons de
modules pour monter la chaîne SCSI et le système de fichiers me semble
toujours d'une imbécillité crasse.
Encore une fois tu réduis la problématique à ce qui se faisait il y a
20 ans. Ce qui marchait il y a 20 ans fonctionne encore aujourd'hui,
donc oui, pourquoi ne pas tout mettre en dur lorsqu'il s'agit de
booter un disque en local. Je rappelle de plus qu'un initrd n'est en
rien obligatoire, et que l'initramfs peut être inclus dans le noyau
au lieu d'apparaître comme un fichier séparé.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Le 06-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:
-racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur.
Je ne vois pas en quoi le fait d'avoir un noyau statique empêcherait
de demander un mot de passe.
Deux solutions: Un, tu met le mot de passe en dur dans le noyau et là, le
chiffrement devient inutile. Deux, tu demandes aux développeurs noyaux
d'insérer un bout de code qui va aller demander le mot de passe à
l'utilisateur.
Le second cas fonctionne, puisque NetBSD semble agir comme cela, mais
je trouve ça lourd, compliqué et pesant. Est-ce au développeur noyau
d'écrire un bout de code demandant un mot de passe? Et si je veux le
traduire en swahili, il faut faire un bug report? Et si je veux aller
chercher le mot de passe sur une clé USB?
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
J'ai des grappes de serveurs qui fonctionnent comme ça (des Txxx de
chez Sun) avec des noyaux statiques et ça ne pose strictement aucune
problème. De toute façon, tant que la racine n'est pas montée, je ne
vois pas ce que tu espères faire de ton système...
Là, j'ai une machine full USB avec lecteur CD, disque, clés, etc..
Effectivement, je peux mettre un timer de 2mn afin d'être sur que le
bon périphérique racine apparaisse, ou bien je peux attendre le
premier qui monte sans garantie que ce soit le bon. (paramètres rootwait
et rootdelay chez linux). C'est juste long, très long. S'il est
possible d'injecter un peu d'intelligence dans le processus de montage
de la racine, pourquoi s'en priver.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en
statique ? Et la réponse n'est pas une taille maximale de noyau, parce
que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas
chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur
un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que
ça. L'initramfs permet donc de répondre à ces nouvelles problématiques
de manière judicieuse.
Je ne vois toujours pas en quoi cela _interdit_ de coller en dur
ce qu'il faut pour accéder à sa racine (pilote hard et fs).
Parcequ'avoir un pilote hard et le fs en dur n'est tout simplement pas
suffisant. De plus, tu te trompes de problématique, l'aspect judicieux
de l'initrd ne réside pas dans la possibilité de mettre des modules
mais dans la possibilité que tu as, toi, de pouvoir scripter les
étapes successives permettant de monter la racine.
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Vouloir
absolument booter un linux (puisque c'est aussi de ça qu'on parle) sur
une machine de prod avec un noyau minimal et un système abscons de
modules pour monter la chaîne SCSI et le système de fichiers me semble
toujours d'une imbécillité crasse.
Encore une fois tu réduis la problématique à ce qui se faisait il y a
20 ans. Ce qui marchait il y a 20 ans fonctionne encore aujourd'hui,
donc oui, pourquoi ne pas tout mettre en dur lorsqu'il s'agit de
booter un disque en local. Je rappelle de plus qu'un initrd n'est en
rien obligatoire, et que l'initramfs peut être inclus dans le noyau
au lieu d'apparaître comme un fichier séparé.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Le 06-12-2008, JKB 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:
-racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur.
Je ne vois pas en quoi le fait d'avoir un noyau statique empêcherait
de demander un mot de passe.
Deux solutions: Un, tu met le mot de passe en dur dans le noyau et là, le
chiffrement devient inutile. Deux, tu demandes aux développeurs noyaux
d'insérer un bout de code qui va aller demander le mot de passe à
l'utilisateur.
Le second cas fonctionne, puisque NetBSD semble agir comme cela, mais
je trouve ça lourd, compliqué et pesant. Est-ce au développeur noyau
d'écrire un bout de code demandant un mot de passe? Et si je veux le
traduire en swahili, il faut faire un bug report? Et si je veux aller
chercher le mot de passe sur une clé USB?
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
J'ai des grappes de serveurs qui fonctionnent comme ça (des Txxx de
chez Sun) avec des noyaux statiques et ça ne pose strictement aucune
problème. De toute façon, tant que la racine n'est pas montée, je ne
vois pas ce que tu espères faire de ton système...
Là, j'ai une machine full USB avec lecteur CD, disque, clés, etc..
Effectivement, je peux mettre un timer de 2mn afin d'être sur que le
bon périphérique racine apparaisse, ou bien je peux attendre le
premier qui monte sans garantie que ce soit le bon. (paramètres rootwait
et rootdelay chez linux). C'est juste long, très long. S'il est
possible d'injecter un peu d'intelligence dans le processus de montage
de la racine, pourquoi s'en priver.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en
statique ? Et la réponse n'est pas une taille maximale de noyau, parce
que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas
chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur
un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que
ça. L'initramfs permet donc de répondre à ces nouvelles problématiques
de manière judicieuse.
Je ne vois toujours pas en quoi cela _interdit_ de coller en dur
ce qu'il faut pour accéder à sa racine (pilote hard et fs).
Parcequ'avoir un pilote hard et le fs en dur n'est tout simplement pas
suffisant. De plus, tu te trompes de problématique, l'aspect judicieux
de l'initrd ne réside pas dans la possibilité de mettre des modules
mais dans la possibilité que tu as, toi, de pouvoir scripter les
étapes successives permettant de monter la racine.
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Vouloir
absolument booter un linux (puisque c'est aussi de ça qu'on parle) sur
une machine de prod avec un noyau minimal et un système abscons de
modules pour monter la chaîne SCSI et le système de fichiers me semble
toujours d'une imbécillité crasse.
Encore une fois tu réduis la problématique à ce qui se faisait il y a
20 ans. Ce qui marchait il y a 20 ans fonctionne encore aujourd'hui,
donc oui, pourquoi ne pas tout mettre en dur lorsqu'il s'agit de
booter un disque en local. Je rappelle de plus qu'un initrd n'est en
rien obligatoire, et que l'initramfs peut être inclus dans le noyau
au lieu d'apparaître comme un fichier séparé.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Le 06-12-2008, JKB a écrit :Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Certes.
:~ $ wc -l /usr/src/linux/Documentation/kernel-parameters.txt
2282 /usr/src/linux/Documentation/kernel-parameters.txt
On arrête quand l'inflation de la taille de ce fichier?Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
Ce n'est pas une limitation de l'OS, c'est une limitation physique de
l'imagination des développeurs du noyaux, associés avec une limitation
dans le temps accordé à la programmation. Je vais écrire un mail à Linux
en lui demandant d'ajouter un kernel parameter pour faire du root
over httpfs. Puis un second quelques jours après pour ajouter le
proxy. Et encore après un ajout pour un login/pass pour le proxy.
C'est sans fin. Et c'est donc bien une limitation de l'OS.C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
Aucun rapport. Mais alors absolument aucun.
Quand je dis root over httpfs, ou est ce que tu lis 'PC'? Quand je parle
de racine chiffrée, ou lis tu 'PC'? Quand j'écris Wifi, ou vois tu 'PC'?
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Sans initrd, il faut que j'aille développer moi même de nouveaux
paramètres à donner par le bootloader, ou à demander aux dévs
noyaux d'intégrer la possibilité de donner un canal, un mot de
passe et autres lors du boot.
Et ça, ça n'a _rien_ a voir avec le hard. (et by the way, j'ai longtemps
travaillé sous linux PPC, donc arrêtes avec ta rengaine 'sors du PC')
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Revenons au linux PPC. La distrib linux était sur disque USB. Ce bus
mettait entre 3 et 25s a apparaître. En premier usage j'ai utilisé
un rootdelay0 pour être sûr que ça boot correctement. Puis très
vite, j'ai écrit un initrd (sans modules, oui, tout était en dur)
qui vérifiait l'apparition du disque USB pour continuer le boot. Ca,
c'est pratique.D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Arguments? Exemples?
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Les défauts, je n'en ai pas encore vu. Je te rappelle que c'est débrayable.
Le 06-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Certes.
kevin@slackwall:~ $ wc -l /usr/src/linux/Documentation/kernel-parameters.txt
2282 /usr/src/linux/Documentation/kernel-parameters.txt
On arrête quand l'inflation de la taille de ce fichier?
Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
Ce n'est pas une limitation de l'OS, c'est une limitation physique de
l'imagination des développeurs du noyaux, associés avec une limitation
dans le temps accordé à la programmation. Je vais écrire un mail à Linux
en lui demandant d'ajouter un kernel parameter pour faire du root
over httpfs. Puis un second quelques jours après pour ajouter le
proxy. Et encore après un ajout pour un login/pass pour le proxy.
C'est sans fin. Et c'est donc bien une limitation de l'OS.
C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
Aucun rapport. Mais alors absolument aucun.
Quand je dis root over httpfs, ou est ce que tu lis 'PC'? Quand je parle
de racine chiffrée, ou lis tu 'PC'? Quand j'écris Wifi, ou vois tu 'PC'?
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Sans initrd, il faut que j'aille développer moi même de nouveaux
paramètres à donner par le bootloader, ou à demander aux dévs
noyaux d'intégrer la possibilité de donner un canal, un mot de
passe et autres lors du boot.
Et ça, ça n'a _rien_ a voir avec le hard. (et by the way, j'ai longtemps
travaillé sous linux PPC, donc arrêtes avec ta rengaine 'sors du PC')
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Revenons au linux PPC. La distrib linux était sur disque USB. Ce bus
mettait entre 3 et 25s a apparaître. En premier usage j'ai utilisé
un rootdelay0 pour être sûr que ça boot correctement. Puis très
vite, j'ai écrit un initrd (sans modules, oui, tout était en dur)
qui vérifiait l'apparition du disque USB pour continuer le boot. Ca,
c'est pratique.
D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Arguments? Exemples?
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Les défauts, je n'en ai pas encore vu. Je te rappelle que c'est débrayable.
Le 06-12-2008, JKB a écrit :Rien ne t'interdit d'avoir un paramètre dans ton bootloader pour
aller chercher le bon périphérique contenant ton mot de passe.
Certes.
:~ $ wc -l /usr/src/linux/Documentation/kernel-parameters.txt
2282 /usr/src/linux/Documentation/kernel-parameters.txt
On arrête quand l'inflation de la taille de ce fichier?Je ne
vois toujours pas en quoi le problème est une limitation de l'OS.
Ce n'est pas une limitation de l'OS, c'est une limitation physique de
l'imagination des développeurs du noyaux, associés avec une limitation
dans le temps accordé à la programmation. Je vais écrire un mail à Linux
en lui demandant d'ajouter un kernel parameter pour faire du root
over httpfs. Puis un second quelques jours après pour ajouter le
proxy. Et encore après un ajout pour un login/pass pour le proxy.
C'est sans fin. Et c'est donc bien une limitation de l'OS.C'est
plutôt une limitation du hard. Avec un truc comme Openboot de Sun ou la
console SRM de Digital (Compaq et peut-être HP maintenant), tu
n'aurais pas le problème. Tu pourrais avoir un paramètre indiquant dans
la nvram où chercher ton fameux mot de passe alors que tout le reste
serait statique dans ton noyau.
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Le développeur noyau n'a pas obligatoirement pensé à tous ces cas.
De facto, en tant qu'admin de ta machine, tu es limité aux deux ou
trois possibilités données par le dév.
Vire les oeillères issues du monde tu PC.
Aucun rapport. Mais alors absolument aucun.
Quand je dis root over httpfs, ou est ce que tu lis 'PC'? Quand je parle
de racine chiffrée, ou lis tu 'PC'? Quand j'écris Wifi, ou vois tu 'PC'?
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
Idem.
Actuellement, sans initrd, c'est impossible. Je dis juste ça comme ça.
Non, je persiste que c'est _à cause_ d'une limitation du hard du PC
que les développeurs ont fait ce choix. Ce n'est pas une limitation
intrinsèque à l'OS et on pourrait faire mieux.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Sans initrd, il faut que j'aille développer moi même de nouveaux
paramètres à donner par le bootloader, ou à demander aux dévs
noyaux d'intégrer la possibilité de donner un canal, un mot de
passe et autres lors du boot.
Et ça, ça n'a _rien_ a voir avec le hard. (et by the way, j'ai longtemps
travaillé sous linux PPC, donc arrêtes avec ta rengaine 'sors du PC')
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Je repose ma question. Que fais-tu avec une machine qui n'a pas
encore monté sa partition root ?
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Revenons au linux PPC. La distrib linux était sur disque USB. Ce bus
mettait entre 3 et 25s a apparaître. En premier usage j'ai utilisé
un rootdelay0 pour être sûr que ça boot correctement. Puis très
vite, j'ai écrit un initrd (sans modules, oui, tout était en dur)
qui vérifiait l'apparition du disque USB pour continuer le boot. Ca,
c'est pratique.D'ailleurs, je colle effectivement ces pilotes en dur dans
mes noyaux. Mais tu passes au delà de beaucoup de cas. Au hasard, je
veux monter ma racine over httpfs. Sous BSD, il faut demander l'avis
des dév, il faut prévoir tout ça dans le noyau et au final on se retrouve
avec une tripotée d'options à mettre dans le bootloader.
Sous linux, si je veux réaliser ceci, j'ai juste à écrire un script
et ça fonctionne. C'est souple, c'est fiable, c'est extensible.
Et parfaitement casse-gueule.
Arguments? Exemples?
Merci de me le signaler. J'ai arrêté de jouer avec initrd depuis que
j'administre des machines qui doivent avoir une haute disponibilité et
que je n'ai pas accès facilement auxdites machines. J'ai vu assez de
plantages lors de l'étape initrd pour ne jamais utiliser ça à distance !
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Pour finir, je dirais qu'avoir un système d'une flexibilité infinie me
paraît être d'une grande intelligence, mais que j'étais venu ici pour
savoir comment les BSD démarrent plutôt que de narrer les qualités de
l'initi[rd|amfs].
Qui pour moi sont des défauts et des sources d'emmerdes, mais chacun
voit midi à sa porte.
Les défauts, je n'en ai pas encore vu. Je te rappelle que c'est débrayable.
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Le jour où initrd/initramfs sera obligatoire sous Linux,
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Le jour où initrd/initramfs sera obligatoire sous Linux,
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Le jour où initrd/initramfs sera obligatoire sous Linux,
Le 06-12-2008, JKB a écrit :Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
Ok, alors, où? Du temps des noyaux 2.4 on pouvait indiquer en dur au
noyau à l'aide de la commande rdev ou était situé la racine, comment
la monter, etc.. O surprise, cette méthode a été abandonnée. Trop
rigide, trop figée.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Comme ça le jour ou le mot de passe change, il faut aller faire le tour
de toutes tes stations. C'est ballot, tout de même.
Ou alors, je te l'accorde, on peut imaginer que c'est ton openprom qui
demande le mot de passe. Mais à réflechir comme ça, tu as toujours un
train de retard. Si l'OS (ou le hard sous jacent) n'a pas prévu une
manière de booter, tu n'as pas de solutions. Ton openbootprom sur ton
archi 'x' permet de demander une clé WPA. Sur l'archi 'y', il n'y a pas.
Su l'archi 'z', pas plus.
Et si on unifiait tout ça?
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Et là, tu vas me dire que c'est la faute du hard? Et si l'OS est
effectivement incapable de voir la racine, on change le hard ou l'OS?
Donne moi une manière de savoir si la racine est là, je te donne un
cas particulier qui fait qu'elle ne monte pas.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
J'ai du mal à te suivre. Pour installer sur des machines un peu
exotiques, l'initramfs est idéal.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
Et bien évidemment, si la racine était le lecteur CD ça aurait
marché? Si le dev a oublié un pilote, il l'a oublié, point.
Ca n'a rien à voir avec un défaut d'initrd, c'est un défaut de
la distrib ou du mainteneur.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Oui. L'initramfs, c'est moi qui l'ait écrit, je sais ce qu'il fait, et il
fonctionne.Le jour où initrd/initramfs sera obligatoire sous Linux,
Mais personne ne dit ça. Je précise que l'initramfs est un moyen simple
et fiable permettant d'étendre la façon dont linux boote. Les choix
offerts sont gigantesques.
Maintenant, je t'accorde que l'initrd est superfétatoire dans pas mal
de cas. Mais le fait qu'il existe et les possibilités qu'il apporte
sont indéniables, et largement plus intéressantes que d'essayer de
se rattraper sur les options de démarrage ou le hard.
Le 06-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
Ok, alors, où? Du temps des noyaux 2.4 on pouvait indiquer en dur au
noyau à l'aide de la commande rdev ou était situé la racine, comment
la monter, etc.. O surprise, cette méthode a été abandonnée. Trop
rigide, trop figée.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Comme ça le jour ou le mot de passe change, il faut aller faire le tour
de toutes tes stations. C'est ballot, tout de même.
Ou alors, je te l'accorde, on peut imaginer que c'est ton openprom qui
demande le mot de passe. Mais à réflechir comme ça, tu as toujours un
train de retard. Si l'OS (ou le hard sous jacent) n'a pas prévu une
manière de booter, tu n'as pas de solutions. Ton openbootprom sur ton
archi 'x' permet de demander une clé WPA. Sur l'archi 'y', il n'y a pas.
Su l'archi 'z', pas plus.
Et si on unifiait tout ça?
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Et là, tu vas me dire que c'est la faute du hard? Et si l'OS est
effectivement incapable de voir la racine, on change le hard ou l'OS?
Donne moi une manière de savoir si la racine est là, je te donne un
cas particulier qui fait qu'elle ne monte pas.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
J'ai du mal à te suivre. Pour installer sur des machines un peu
exotiques, l'initramfs est idéal.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
Et bien évidemment, si la racine était le lecteur CD ça aurait
marché? Si le dev a oublié un pilote, il l'a oublié, point.
Ca n'a rien à voir avec un défaut d'initrd, c'est un défaut de
la distrib ou du mainteneur.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Oui. L'initramfs, c'est moi qui l'ait écrit, je sais ce qu'il fait, et il
fonctionne.
Le jour où initrd/initramfs sera obligatoire sous Linux,
Mais personne ne dit ça. Je précise que l'initramfs est un moyen simple
et fiable permettant d'étendre la façon dont linux boote. Les choix
offerts sont gigantesques.
Maintenant, je t'accorde que l'initrd est superfétatoire dans pas mal
de cas. Mais le fait qu'il existe et les possibilités qu'il apporte
sont indéniables, et largement plus intéressantes que d'essayer de
se rattraper sur les options de démarrage ou le hard.
Le 06-12-2008, JKB a écrit :Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
C'est toi qui me parle d'options sur la ligne de commande du noyau,
pas moi. Il y a d'autres systèmes qui sont largement mieux fichus sans
devoir utiliser le bricolage initrd.
Ok, alors, où? Du temps des noyaux 2.4 on pouvait indiquer en dur au
noyau à l'aide de la commande rdev ou était situé la racine, comment
la monter, etc.. O surprise, cette méthode a été abandonnée. Trop
rigide, trop figée.
C'est une plaisanterie? Le mot de passe WPA de ton réseau wifi, c'est une
limitation hard ou soft? Avec l'initrd, c'est immédiatement fonctionnel.
Si j'avais envie de bricoler un tel truc sur une de mes sparcs, je
collerais simplement le mot de passe WPA dans l'openpromfs.
Comme ça le jour ou le mot de passe change, il faut aller faire le tour
de toutes tes stations. C'est ballot, tout de même.
Ou alors, je te l'accorde, on peut imaginer que c'est ton openprom qui
demande le mot de passe. Mais à réflechir comme ça, tu as toujours un
train de retard. Si l'OS (ou le hard sous jacent) n'a pas prévu une
manière de booter, tu n'as pas de solutions. Ton openbootprom sur ton
archi 'x' permet de demander une clé WPA. Sur l'archi 'y', il n'y a pas.
Su l'archi 'z', pas plus.
Et si on unifiait tout ça?
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Alors que fais tu? Tu attends des plombes. Le seul fallback permettant
d'être sur que la racine soit là est le timer. Qui dure longtemps.
donc bon, attendre 20mn inutiles à chaque boot, pourquoi pas, mais très
peu pour moi.
Ça, c'est un autre problème. Si tu spécifies quelque part que ta
racine est sur tel périphérique et que tu dois attendre le timeout final
parce que tu es incapable (ou que l'OS est incapable) de voir que la
racine est là, c'est un problème de conception du mécanisme de boot.
Et là, tu vas me dire que c'est la faute du hard? Et si l'OS est
effectivement incapable de voir la racine, on change le hard ou l'OS?
Donne moi une manière de savoir si la racine est là, je te donne un
cas particulier qui fait qu'elle ne monte pas.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Sans parler de l'initramfs des derniers installeurs... Là, on frise le
grandiose. J'aimerais qu'on m'explique une fois pour toute pourquoi
l'installeur ne monte pas le media d'installation en racine (avec ce
qu'il faut pour bosser un minimum, source de noyaux...) pour pouvoir
installer le truc plus facilement sur des machines un peu exotiques.
J'ai du mal à te suivre. Pour installer sur des machines un peu
exotiques, l'initramfs est idéal.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Le
rootfs en RAM des installeurs qui foirent parce que tel dev à oublié tel
pilote ou que tel noyau est foireux sur telle architecture, j'en ai vu
quelques uns (en particulier justement sur ppc32 et sparc32/64).
Et bien évidemment, si la racine était le lecteur CD ça aurait
marché? Si le dev a oublié un pilote, il l'a oublié, point.
Ca n'a rien à voir avec un défaut d'initrd, c'est un défaut de
la distrib ou du mainteneur.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
L'initrd/ramfs, soit il est inexistant et il ne pose pas de problèmes, soit
il est présent et mal écrit, soit il est présent et bien écrit.
L'avantage c'est que tu as la liberté de te mettre dans le cas souhaité.
Et surprise (!) je n'ai jamais de problèmes avec mes initramfs.
Parfait, on ne doit pas avoir les mêmes critères de disponibilité.
Oui. L'initramfs, c'est moi qui l'ait écrit, je sais ce qu'il fait, et il
fonctionne.Le jour où initrd/initramfs sera obligatoire sous Linux,
Mais personne ne dit ça. Je précise que l'initramfs est un moyen simple
et fiable permettant d'étendre la façon dont linux boote. Les choix
offerts sont gigantesques.
Maintenant, je t'accorde que l'initrd est superfétatoire dans pas mal
de cas. Mais le fait qu'il existe et les possibilités qu'il apporte
sont indéniables, et largement plus intéressantes que d'essayer de
se rattraper sur les options de démarrage ou le hard.
Le hard, ça doit lancer le bootloader, rien d'autre.
Le hard, ça doit lancer le bootloader, rien d'autre.
Le hard, ça doit lancer le bootloader, rien d'autre.
Kevin Denis wrote:Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Kevin Denis <kevin@nowhere.invalid> wrote:
Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Kevin Denis wrote:Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
Parce que initramfs dépend d'un système _déjà_ en cours de boot et
n'est pas accessible directement sur une machine distante comme l'est
openprom.
En prenant le point le plus bloquant, donc le PC. Parfait, on
avance. Ce n'est pas parce qu'une architecture est moisie qu'il faut que
_toutes_ les architectures le deviennent. Nivellement par le bas, c'est
bien...
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Non. C'est un cataplasme sur une jambe de bois. Si ton initrd est
moisi pour une raison ou pour une autre, que ta machine est à l'autre
bout du monde, comment fais-tu ?
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Non. Là, par exemple, j'ai un superbe :
network-boot-arguments=rarp,file=tftp://192.168.1.254
root2.168.1.254:/export/home/srv/solaris10-tchaikovski/
boottype2.168.1.254:in
rootopts2.168.1.254:rsize92,vers=2,proto=udp
Et ça boote un serveur 32 procs sur un disque réseau.
Je me suis
trompé dans les adresses ? Le serveur distant est out ? Ça ne fait rien,
j'utilise le processeur de service pour changer les options directement
dans l'openprom.
Comment fais-tu avec un initrd puisque pour pouvoir le
modifier, il faut que ton système soit _accessible_ et _booté_ ?
Un timeout pour le montage de la racine est casse-gueule. Soit la
racine peut monter soit elle ne peut pas et on panique. Un timeout n'a
rien à faire là-dedans. Et c'est à l'OS de refuser de faire autre chose
tant que cette fichue racine n'est pas montée.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Si. Pose-toi une question. Pourquoi est-ce que _chaque fois que
c'est possible_, les concepteurs de gros systèmes collent dans un coin
d'une nvram (openprom, SRM ou autre) un paramètre contenant le disque de
boot ainsi que la partition racine ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Non encore une fois, parce que tu es _tributaire_ de l'initrd/ramfs
que tu ne peux pas modifier
s'il plante parce que pour le modifier, il
te faut une machine _fonctionnelle_ !
C'est un peu le même tonneau que
le message "Keyboard not found, hit F1" de MS-DOS ou l'inénarrable
"Kernel panic, hit key je ne sais plus quoi" sous Linux alors que tout
est planté ! Tu me parles de bricoler un truc _après_ avoir un noyau
bootable, sur une machine dont tu as un accès minimal à la console,
je te parle de booter une machine sur laquelle tu n'as aucun accès
physique.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Tu le fais exprès ? On n'est pourtant plus vendredi... Il ne faut
pas grand chose pour supporter la majorité
des lecteurs CD. Maintenant,
il existe des techniques bien documentées pour accéder de façon minimale
aux différents lecteurs sur toutes les architectures (comprendre sans
OS. Comment crois-tu qu'un bootloader se lance ?).
Sauf qu'avec un système à peu près utilisable, tu peux espérer
récupérer les trucs qui merdoient quitte à être obligé de mettre les
mains dans la mécanique. Quand ton initramfs est foireux et que le noyau
d'installation lance directement ce qui est dessus et que ça termine
mal, tu es comme un imbécile.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
Ça, c'est la théorie.
Pour me taper de l'administration de systèmes critiques, pour
bricoler moi-même dans le coeur d'OS, je trouve que le couple
initrd/initramfs est une sombre merde (et je pèse mes mots)
qui plus
est inventée pour palier à un manque de certaines architectures.
Libre à toi
de l'utiliser, mais ne cherche surtout pas à me convaincre
d'utiliser
une saloperie pareille. J'ai un esprit assez ouvert, j'ai utilisé
ces trucs mais à chaque fois que j'ai vu ce truc arriver, il a apporté
avec lui des palanquées et demi de problèmes qu'on aurait pu éviter.
JKB <EOT>
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
Parce que initramfs dépend d'un système _déjà_ en cours de boot et
n'est pas accessible directement sur une machine distante comme l'est
openprom.
En prenant le point le plus bloquant, donc le PC. Parfait, on
avance. Ce n'est pas parce qu'une architecture est moisie qu'il faut que
_toutes_ les architectures le deviennent. Nivellement par le bas, c'est
bien...
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Non. C'est un cataplasme sur une jambe de bois. Si ton initrd est
moisi pour une raison ou pour une autre, que ta machine est à l'autre
bout du monde, comment fais-tu ?
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Non. Là, par exemple, j'ai un superbe :
network-boot-arguments=rarp,file=tftp://192.168.1.254
root2.168.1.254:/export/home/srv/solaris10-tchaikovski/
boottype2.168.1.254:in
rootopts2.168.1.254:rsize92,vers=2,proto=udp
Et ça boote un serveur 32 procs sur un disque réseau.
Je me suis
trompé dans les adresses ? Le serveur distant est out ? Ça ne fait rien,
j'utilise le processeur de service pour changer les options directement
dans l'openprom.
Comment fais-tu avec un initrd puisque pour pouvoir le
modifier, il faut que ton système soit _accessible_ et _booté_ ?
Un timeout pour le montage de la racine est casse-gueule. Soit la
racine peut monter soit elle ne peut pas et on panique. Un timeout n'a
rien à faire là-dedans. Et c'est à l'OS de refuser de faire autre chose
tant que cette fichue racine n'est pas montée.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Si. Pose-toi une question. Pourquoi est-ce que _chaque fois que
c'est possible_, les concepteurs de gros systèmes collent dans un coin
d'une nvram (openprom, SRM ou autre) un paramètre contenant le disque de
boot ainsi que la partition racine ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Non encore une fois, parce que tu es _tributaire_ de l'initrd/ramfs
que tu ne peux pas modifier
s'il plante parce que pour le modifier, il
te faut une machine _fonctionnelle_ !
C'est un peu le même tonneau que
le message "Keyboard not found, hit F1" de MS-DOS ou l'inénarrable
"Kernel panic, hit key je ne sais plus quoi" sous Linux alors que tout
est planté ! Tu me parles de bricoler un truc _après_ avoir un noyau
bootable, sur une machine dont tu as un accès minimal à la console,
je te parle de booter une machine sur laquelle tu n'as aucun accès
physique.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Tu le fais exprès ? On n'est pourtant plus vendredi... Il ne faut
pas grand chose pour supporter la majorité
des lecteurs CD. Maintenant,
il existe des techniques bien documentées pour accéder de façon minimale
aux différents lecteurs sur toutes les architectures (comprendre sans
OS. Comment crois-tu qu'un bootloader se lance ?).
Sauf qu'avec un système à peu près utilisable, tu peux espérer
récupérer les trucs qui merdoient quitte à être obligé de mettre les
mains dans la mécanique. Quand ton initramfs est foireux et que le noyau
d'installation lance directement ce qui est dessus et que ça termine
mal, tu es comme un imbécile.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
Ça, c'est la théorie.
Pour me taper de l'administration de systèmes critiques, pour
bricoler moi-même dans le coeur d'OS, je trouve que le couple
initrd/initramfs est une sombre merde (et je pèse mes mots)
qui plus
est inventée pour palier à un manque de certaines architectures.
Libre à toi
de l'utiliser, mais ne cherche surtout pas à me convaincre
d'utiliser
une saloperie pareille. J'ai un esprit assez ouvert, j'ai utilisé
ces trucs mais à chaque fois que j'ai vu ce truc arriver, il a apporté
avec lui des palanquées et demi de problèmes qu'on aurait pu éviter.
JKB <EOT>
Donc le noyau doit connaître _a priori_ tous ces paramètres. Et donc
avoir été développés. Etc, etc.. Demain va sortir un clé bluetooth et
je souhaite faire du nfsroot over bluetooth. Sans initrd, je n'ai
pas d'autres choix que d'attendre que de nouveaux paramètres noyaux
fassent leur apparition, etc..
Openpromfs est assez souple.
Tiens, tu cherches de la souplesse? Et qu'offre initramfs si ce n'est
cette souplesse? Pourquoi vouloir s'appuyer sur le hard alors que tu
peux t'en passer? Là, c'est moi qui ne comprend pas.
Parce que initramfs dépend d'un système _déjà_ en cours de boot et
n'est pas accessible directement sur une machine distante comme l'est
openprom.
En prenant le point le plus bloquant, donc le PC. Parfait, on
avance. Ce n'est pas parce qu'une architecture est moisie qu'il faut que
_toutes_ les architectures le deviennent. Nivellement par le bas, c'est
bien...
Le hard, ça doit lancer le bootloader, rien d'autre. Le bootloader
peut être le noyau directement, ou bien un mécanisme qui charge un noyau, un
initrd et des arguments. Ca c'est fiable, c'est indépendant de l'archi
hard et c'est souple.
Non. C'est un cataplasme sur une jambe de bois. Si ton initrd est
moisi pour une raison ou pour une autre, que ta machine est à l'autre
bout du monde, comment fais-tu ?
Sur PC, sur PPC, ou sur Mips, tu peux mettre ton linux avec une
racine située n'importe où. Les solutions que tu propose ne font
que réduire ces possibilités.
Non. Là, par exemple, j'ai un superbe :
network-boot-arguments=rarp,file=tftp://192.168.1.254
root2.168.1.254:/export/home/srv/solaris10-tchaikovski/
boottype2.168.1.254:in
rootopts2.168.1.254:rsize92,vers=2,proto=udp
Et ça boote un serveur 32 procs sur un disque réseau.
Je me suis
trompé dans les adresses ? Le serveur distant est out ? Ça ne fait rien,
j'utilise le processeur de service pour changer les options directement
dans l'openprom.
Comment fais-tu avec un initrd puisque pour pouvoir le
modifier, il faut que ton système soit _accessible_ et _booté_ ?
Un timeout pour le montage de la racine est casse-gueule. Soit la
racine peut monter soit elle ne peut pas et on panique. Un timeout n'a
rien à faire là-dedans. Et c'est à l'OS de refuser de faire autre chose
tant que cette fichue racine n'est pas montée.
Le dernier gag des contrôleurs IDE qui sont passés en émulation
SCSI. Il faut que je développe ?
Ca me rappelle une aberration de la debian. Rien à voir avec les
bootloaders. Sauf que, même sur ce point, un initramfs bien conçu
t'aurait donné un shell rescue. Ce shell t'aurait permis de trouver
la racine, modifier la fstab et booter dessus.
Rien à voir avec un soit-disant défaut de l'initrd.
Si. Pose-toi une question. Pourquoi est-ce que _chaque fois que
c'est possible_, les concepteurs de gros systèmes collent dans un coin
d'une nvram (openprom, SRM ou autre) un paramètre contenant le disque de
boot ainsi que la partition racine ?
Un autre gag plus ancien avec le
'scan-scsi in background' qui rendait Linux ininstallable sur des
machines tout SCSI.
Et, oh surprise, avec un peu d'intelligence dans l'initramfs tu
peux installer sans soucis. Merci de ton soutien.
Non encore une fois, parce que tu es _tributaire_ de l'initrd/ramfs
que tu ne peux pas modifier
s'il plante parce que pour le modifier, il
te faut une machine _fonctionnelle_ !
C'est un peu le même tonneau que
le message "Keyboard not found, hit F1" de MS-DOS ou l'inénarrable
"Kernel panic, hit key je ne sais plus quoi" sous Linux alors que tout
est planté ! Tu me parles de bricoler un truc _après_ avoir un noyau
bootable, sur une machine dont tu as un accès minimal à la console,
je te parle de booter une machine sur laquelle tu n'as aucun accès
physique.
Ensuite, monter le media d'installation
comme racine, bof. Comment faire lorsque tu as deux CD? Ou un lecteur
CD IDE? Ou SCSI? Ou bien seulement l'image ISO? L'initrmafs permet
de s'adapter.
Tu le fais exprès ? On n'est pourtant plus vendredi... Il ne faut
pas grand chose pour supporter la majorité
des lecteurs CD. Maintenant,
il existe des techniques bien documentées pour accéder de façon minimale
aux différents lecteurs sur toutes les architectures (comprendre sans
OS. Comment crois-tu qu'un bootloader se lance ?).
Sauf qu'avec un système à peu près utilisable, tu peux espérer
récupérer les trucs qui merdoient quitte à être obligé de mettre les
mains dans la mécanique. Quand ton initramfs est foireux et que le noyau
d'installation lance directement ce qui est dessus et que ça termine
mal, tu es comme un imbécile.
Concernant l'installation de distribs linux, l'utilisation d'initramfs
est très judicieuse. On démarre avec trois fois rien, puis on va
chercher le media d'install ensuite. Ca me permet d'installer des
distros linux sans bruler de CD.
Ça, c'est la théorie.
Pour me taper de l'administration de systèmes critiques, pour
bricoler moi-même dans le coeur d'OS, je trouve que le couple
initrd/initramfs est une sombre merde (et je pèse mes mots)
qui plus
est inventée pour palier à un manque de certaines architectures.
Libre à toi
de l'utiliser, mais ne cherche surtout pas à me convaincre
d'utiliser
une saloperie pareille. J'ai un esprit assez ouvert, j'ai utilisé
ces trucs mais à chaque fois que j'ai vu ce truc arriver, il a apporté
avec lui des palanquées et demi de problèmes qu'on aurait pu éviter.
JKB <EOT>
Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Le hard, ça doit lancer le bootloader, rien d'autre.
Ben alors pourquoi Sun a développé OpenFirmware, et Intel EFI ?
Le 06-12-2008, Xavier 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?
Le 06-12-2008, Xavier <xavier@groumpf.org> 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?
Le 06-12-2008, Xavier 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?