je me pose des questions sur la manière dont les BSD bootent en le
comparant avec linux.
Dans le temps, linux avait besoin d'un noyau auquel on indiquait la
partition racine, soit directement en dur dans le noyau, soit à l'aide
de paramètres passés via un bootloader.
Puis, l'initrd est arrivé proposant un microsystème permettant de
rendre la racine accessible. Puis l'initramfs qui remplace complètement
le mécanisme qui monte la racine et lance le binaire /sbin/init.
Ma question, savez vous si un des BSD propose ce genre de manipulation?
Comment bootent ils en gros? Et si ils n'implémentent pas cette
méthode de boot en deux temps noyau+initramfs, pourquoi?
Le 07-12-2008, Manuel Bouyer 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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... n'importe quoi qui soit accessible par le kernel.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Kevin Denis <kevin@nowhere.invalid> wrote:
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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ...
n'importe quoi qui soit accessible par le kernel.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Le 07-12-2008, Manuel Bouyer 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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... n'importe quoi qui soit accessible par le kernel.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Kevin Denis
Le 08-12-2008, JKB a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Je vais d'ailleurs <snipper> un peu. Ca s'eternise et on tourne en rond.
Arrête, tu t'enfonces. Je ne me suis jamais penché sur le problème typiquement linuxien
Tu n'as jamais étudié le truc?!! et tu poses un jugement parcequ'un jour un initrd t'as claqué dans les doigts? Enorme. Mais tu t'épanches en disant que c'est de la merde patentée. Je comprends mieux pourquoi tu n'as pas compris l'avantage du truc.
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.
Il faut donc gruiker du code. Gruik de code/ Initramfs, même combat.
Sur des SS20, j'écrivais déjà des scripts dans Openprom. M'étonnerais que ça ait disparu depuis.
Précises moi ta pensée. Et ne vient pas me dire: "Dans openprom sur SS20 j'ai écrit des scripts qui s'appliquent entre le boot noyau et le montage de la racine" car c'est ni plus ni moins l'avantage d'initramfs. On est peut-être d'accord, en fait.
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.
Aucun? Vraiment. Tu n'as jamais eu à aller taper dans le code car il manquait quelquechose?
Non. Parce qu'avec certaines linuxeries dont je tairai les noms, tu peux te retrouver avec un noyau remplacé par un autre
Alors on dit qu'initrd c'est de la merde au lieu d'aller taper sur la linuxerie qui t'a pourri ton boot? (donnes le nom, qu'on rigole. Debian?) Quand sous solaris tu fais une connerie qui te dégage ton noyau, c'est le noyau qu'est moisi ou la connerie qui l'a dégagé?
Si tu utilises un protocole non géré par un bout du système, tu fais comment ?
ALLELUIA! Eh bien tu fais avec un initramfs qui te permet de contourner ce bout non géré par le système. Ex: nfs over wifi, racine chiffrée avec la clé située dans mon téléphone bluetooth, etc..
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.
Ah oui. C'est le pilote qui est mal branlé. J'oubliais. Sauf que même avec ce pilote mal branlé, je boote une racine nfs over wifi mon bon monsieur. C'est le pilote qui est mal branlé ou bien le concepteur qui n'a pas prévu _tous_ les cas d'utilisation? S'il n'a pas prévu tous les cas d'utilisation, peut il prévoir _tous_ les cas d'utilisation?
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é,
Ca alors!
mais ça fonctionne.
Tu sais que tu aurais pu éviter de faire du code gruik et faire en sorte que ça fonctionne tout de même sous linux?
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.
Pas seulement. L'initramfs te permet tout cela, il te permet bien d'autres choses, d'où son interêt. -- Kevin
Le 08-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres.
Apparemment, ils font sans.
Je vais d'ailleurs <snipper> un peu. Ca s'eternise et on tourne
en rond.
Arrête, tu t'enfonces. Je ne me suis jamais penché sur le problème
typiquement linuxien
Tu n'as jamais étudié le truc?!! et tu poses un jugement parcequ'un jour
un initrd t'as claqué dans les doigts? Enorme.
Mais tu t'épanches en disant que c'est de la merde patentée. Je comprends
mieux pourquoi tu n'as pas compris l'avantage du truc.
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.
Il faut donc gruiker du code. Gruik de code/ Initramfs, même combat.
Sur des SS20, j'écrivais déjà des
scripts dans Openprom. M'étonnerais que ça ait disparu depuis.
Précises moi ta pensée. Et ne vient pas me dire:
"Dans openprom sur SS20 j'ai écrit des scripts qui s'appliquent entre
le boot noyau et le montage de la racine" car c'est ni plus ni moins
l'avantage d'initramfs. On est peut-être d'accord, en fait.
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.
Aucun? Vraiment. Tu n'as jamais eu à aller taper dans le code car il
manquait quelquechose?
Non. Parce qu'avec certaines linuxeries dont je tairai les noms, tu
peux te retrouver avec un noyau remplacé par un autre
Alors on dit qu'initrd c'est de la merde au lieu d'aller taper sur la
linuxerie qui t'a pourri ton boot? (donnes le nom, qu'on rigole. Debian?)
Quand sous solaris tu fais une connerie qui te dégage ton noyau, c'est le
noyau qu'est moisi ou la connerie qui l'a dégagé?
Si tu utilises un protocole non géré par un bout du système, tu fais
comment ?
ALLELUIA! Eh bien tu fais avec un initramfs qui te permet de
contourner ce bout non géré par le système. Ex: nfs over wifi, racine
chiffrée avec la clé située dans mon téléphone bluetooth, etc..
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.
Ah oui. C'est le pilote qui est mal branlé. J'oubliais. Sauf que même
avec ce pilote mal branlé, je boote une racine nfs over wifi mon
bon monsieur. C'est le pilote qui est mal branlé ou bien le concepteur
qui n'a pas prévu _tous_ les cas d'utilisation? S'il n'a pas prévu
tous les cas d'utilisation, peut il prévoir _tous_ les cas d'utilisation?
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é,
Ca alors!
mais ça fonctionne.
Tu sais que tu aurais pu éviter de faire du code gruik et faire en sorte
que ça fonctionne tout de même sous linux?
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.
Pas seulement. L'initramfs te permet tout cela, il te permet bien
d'autres choses, d'où son interêt.
--
Kevin
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Je vais d'ailleurs <snipper> un peu. Ca s'eternise et on tourne en rond.
Arrête, tu t'enfonces. Je ne me suis jamais penché sur le problème typiquement linuxien
Tu n'as jamais étudié le truc?!! et tu poses un jugement parcequ'un jour un initrd t'as claqué dans les doigts? Enorme. Mais tu t'épanches en disant que c'est de la merde patentée. Je comprends mieux pourquoi tu n'as pas compris l'avantage du truc.
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.
Il faut donc gruiker du code. Gruik de code/ Initramfs, même combat.
Sur des SS20, j'écrivais déjà des scripts dans Openprom. M'étonnerais que ça ait disparu depuis.
Précises moi ta pensée. Et ne vient pas me dire: "Dans openprom sur SS20 j'ai écrit des scripts qui s'appliquent entre le boot noyau et le montage de la racine" car c'est ni plus ni moins l'avantage d'initramfs. On est peut-être d'accord, en fait.
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.
Aucun? Vraiment. Tu n'as jamais eu à aller taper dans le code car il manquait quelquechose?
Non. Parce qu'avec certaines linuxeries dont je tairai les noms, tu peux te retrouver avec un noyau remplacé par un autre
Alors on dit qu'initrd c'est de la merde au lieu d'aller taper sur la linuxerie qui t'a pourri ton boot? (donnes le nom, qu'on rigole. Debian?) Quand sous solaris tu fais une connerie qui te dégage ton noyau, c'est le noyau qu'est moisi ou la connerie qui l'a dégagé?
Si tu utilises un protocole non géré par un bout du système, tu fais comment ?
ALLELUIA! Eh bien tu fais avec un initramfs qui te permet de contourner ce bout non géré par le système. Ex: nfs over wifi, racine chiffrée avec la clé située dans mon téléphone bluetooth, etc..
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.
Ah oui. C'est le pilote qui est mal branlé. J'oubliais. Sauf que même avec ce pilote mal branlé, je boote une racine nfs over wifi mon bon monsieur. C'est le pilote qui est mal branlé ou bien le concepteur qui n'a pas prévu _tous_ les cas d'utilisation? S'il n'a pas prévu tous les cas d'utilisation, peut il prévoir _tous_ les cas d'utilisation?
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é,
Ca alors!
mais ça fonctionne.
Tu sais que tu aurais pu éviter de faire du code gruik et faire en sorte que ça fonctionne tout de même sous linux?
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.
Pas seulement. L'initramfs te permet tout cela, il te permet bien d'autres choses, d'où son interêt. -- Kevin
Kevin Denis
Le 08-12-2008, Manuel Bouyer a écrit :
> 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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... n'importe quoi qui soit accessible par le kernel.
Ok. On parle bien du binaire init, parent de tous les process? -- Kevin
Le 08-12-2008, Manuel Bouyer <bouyer@nerim.net> a écrit :
> 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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ...
n'importe quoi qui soit accessible par le kernel.
Ok. On parle bien du binaire init, parent de tous les process?
--
Kevin
> 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?
Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... n'importe quoi qui soit accessible par le kernel.
Ok. On parle bien du binaire init, parent de tous les process? -- Kevin
espie
In article , Kevin Denis wrote:
Le 08-12-2008, JKB a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans. Donc si tu veux declencher des flamewars en rapport avec du linux, la porte c'est par la ->
Pour le reste, agresse moins les gens au depart, et tu auras peut-etre des vraies reponses.
In article <slrngjr2nm.jtg.kevin@slackwall.local.tux>,
Kevin Denis <kevin@alinto.comNOSPAM> wrote:
Le 08-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres.
Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans.
Donc si tu veux declencher des flamewars en rapport avec du linux,
la porte c'est par la ->
Pour le reste, agresse moins les gens au depart, et tu auras peut-etre
des vraies reponses.
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans. Donc si tu veux declencher des flamewars en rapport avec du linux, la porte c'est par la ->
Pour le reste, agresse moins les gens au depart, et tu auras peut-etre des vraies reponses.
Kevin Denis
Le 09-12-2008, Marc Espie a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans.
Ok.
Donc si tu veux declencher des flamewars en rapport avec du linux,
my apologies, ce n'était vraiment pas le but initial. Je fais un halte au feu.
la porte c'est par la -> Pour le reste, agresse moins les gens au depart,
my apologies, encore une fois.
et tu auras peut-etre des vraies reponses.
bon, je vais retourner lire la doc. -- Kevin
Le 09-12-2008, Marc Espie <espie@lain.home> a écrit :
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres.
Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans.
Ok.
Donc si tu veux declencher des flamewars en rapport avec du linux,
my apologies, ce n'était vraiment pas le but initial. Je fais un halte
au feu.
la porte c'est par la ->
Pour le reste, agresse moins les gens au depart,
Il n'y a pas que Linux dans la vie (et heureusement),
Tutafé, je viens d'ailleurs voir sur ce groupe comment font les autres. Apparemment, ils font sans.
Ouais, d'ailleurs globalement ils se portent tres bien sans.
Ok.
Donc si tu veux declencher des flamewars en rapport avec du linux,
my apologies, ce n'était vraiment pas le but initial. Je fais un halte au feu.
la porte c'est par la -> Pour le reste, agresse moins les gens au depart,
my apologies, encore une fois.
et tu auras peut-etre des vraies reponses.
bon, je vais retourner lire la doc. -- Kevin
Manuel Bouyer
Kevin Denis wrote:
> Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... > n'importe quoi qui soit accessible par le kernel. > Ok. On parle bien du binaire init, parent de tous les process?
Oui
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Kevin Denis <kevin@nowhere.invalid> wrote:
> Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ...
> n'importe quoi qui soit accessible par le kernel.
>
Ok. On parle bien du binaire init, parent de tous les process?
Oui
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
> Sur ce qu'on veut: un ramdisk, une clef USB, un autre disque dur, ... > n'importe quoi qui soit accessible par le kernel. > Ok. On parle bien du binaire init, parent de tous les process?
Oui
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
