Boot des différents BSD

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

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

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

Trois cas concrets:
-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.

-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.

Idem.

-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...

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). 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.

JKB

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

JKB:

Non, pas forcément. Un Oops, c'est un plantage d'une partie non
cruciale du noyau (du style pilote foireux d'une carte son) qui
n'empêche pas d'arrêter correctementle système. Un panic, c'est un peu
plus violent.

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :

JKB:

Non, pas forcément. Un Oops, c'est un plantage d'une partie non
cruciale du noyau (du style pilote foireux d'une carte son) qui
n'empêche pas d'arrêter correctementle système. Un panic, c'est un peu
plus violent.

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Je préfère de loin un Oops pour ce qui n'est pas crucial, ça permet
généralement d'arrêter un système de façon propre. C'est utile lorsqu'on
a un serveur de fichiers utilisé par une palanquée et demi
d'utilisateurs et que pour une raison ou pour une autre le pilote du
CDROM décide de déréférencer un pointeur nul. On peut avertir les
utilisateurs qu'on va rebooter le serveur plutôt que leur dire que le
serveur a planté et qu'ils ont perdu le travail en cours façon serveur
Windows. C'est bien aussi lorsqu'on a un volume raid soft (j'ai horreur
des raids hard pour des raisons qui n'engagent que moi) de quelques To
qu'on aimerait autant que faire se peut arrêter proprement...

JKB

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

JKB:

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Je préfère de loin un Oops pour ce qui n'est pas crucial, ça permet
généralement d'arrêter un système de façon propre.

D'accord mais comment savoir si c'est crucial ou pas ?
J'aurais moyennement confiance dans un noyau qui en est arrivé à
déréfencer un pointeur NULL. Il a pu se passer tout et n'importe quoi.

Même une carte son ou un pilote de Cdrom (et que je te fais du DMA entre
n'importe quoi, et que je tape dans le bus pci...).

Enfin chacun fait ce qu'il lui plait.

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :

JKB:

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Je préfère de loin un Oops pour ce qui n'est pas crucial, ça permet
généralement d'arrêter un système de façon propre.

D'accord mais comment savoir si c'est crucial ou pas ?
J'aurais moyennement confiance dans un noyau qui en est arrivé à
déréfencer un pointeur NULL. Il a pu se passer tout et n'importe quoi.

Justement, le but du oops, c'est d'éviter qu'il ne se passe
n'importe quoi. Si on ne sait pas ce qui se passe, le noyau panique. Si
on peut récupérer le truc, il fait un oops. Le fonctionnement est plutôt
sain (en tout cas, plus sain qu'un Solaris 2.8 pour ne citer que lui qui
panique plus vite que son ombre pour tout et n'importe quoi).

Même une carte son ou un pilote de Cdrom (et que je te fais du DMA entre
n'importe quoi, et que je tape dans le bus pci...).

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

Enfin chacun fait ce qu'il lui plait.

JKB

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

In article <slrngjkib9.bcl.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :

JKB:

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Je préfère de loin un Oops pour ce qui n'est pas crucial, ça permet
généralement d'arrêter un système de façon propre.

D'accord mais comment savoir si c'est crucial ou pas ?
J'aurais moyennement confiance dans un noyau qui en est arrivé à
déréfencer un pointeur NULL. Il a pu se passer tout et n'importe quoi.

Justement, le but du oops, c'est d'éviter qu'il ne se passe
n'importe quoi. Si on ne sait pas ce qui se passe, le noyau panique. Si
on peut récupérer le truc, il fait un oops. Le fonctionnement est plutôt
sain (en tout cas, plus sain qu'un Solaris 2.8 pour ne citer que lui qui
panique plus vite que son ombre pour tout et n'importe quoi).

Même une carte son ou un pilote de Cdrom (et que je te fais du DMA entre
n'importe quoi, et que je tape dans le bus pci...).

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

Enfin chacun fait ce qu'il lui plait.

JKB

L'enfer est pave de bonnes intentions.

A chaque fois qu'on permet a un *bug* dans un bout un peu critique du
systeme (le noyau quand meme !!!) de continuer apres avoir fait des
cochonneries (genre, avoir tape dans de la memoire qui ne lui appartient pas,
c'est le noyau, quand meme), on *encourage* les gens a continuer comme si de
rien n'etait, voire a ne pas corriger le bug (c'est pas grave).

Pour moi, l'exemple-meme de systeme qui marche salement, c'est windows. Il
y a des tonnes d'aberrations dedans, et des tonnes de comportement fuzzy
pour que ca continue de marchotter meme quand ca devrait pas.

Linux vient juste derriere, avec sa cohorte de hacks "au cas ou" qui permet
au hacker en herbe de s'amuser comme un petit fou, et de se pondre sa config
a lui qui fait des trucs tordus 'achtement bien avec un minimum (voire moins)
d'aspects standards du systeme. D'ou une Balkanisation des config, et des
bugs qui restent tres longtemps, parce qu'on ne sait jamais trop si c'est le
systeme qui deconne ou l'utilisateur qui va avec...

Bref, je ne suis pas du tout fan de cette philosophie, si par hasard tu
n'avais pas compris. Les effets les plus deleteres en etant les multiples
"patch" de iptables (au cas ou) ou la configuration invraisemblablement
complexe de pam...

JKB <knatschke@koenigsberg.fr> wrote:

Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
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...

Si on veut prendre en compte tout les cas, ca revient a mettre
tout les pilotes controleur de disque, tout les pilotes de carte
reseau, les pilotes USB et firewire, et tout les systemes de fichier
dans le kernel (en gros il n'y a que les cartes son qu'on puisse virer -
encore qu'il y en a eu qui integraient un controlleur IDE).
Ca fait beaucoup, d'autant plus que certain drivers on besoin d'un firmware
a charger dans la carte de plusieurs 100aine de Ko. Donc, dans le cas
general, charger par module ce qu'il faut pour / ca n'est pas deraisonnable.

Apres il n'est pas interdit de se recompiler un kenrel avec tout ce
qu'il faut en statique, et c'est meme recommande pour des serveurs de
prod AMHA.

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

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Manuel Bouyer ?crivait dans fr.comp.os.bsd :

JKB <knatschke@koenigsberg.fr> wrote:

Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
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...

Si on veut prendre en compte tout les cas, ca revient a mettre
tout les pilotes controleur de disque, tout les pilotes de carte
reseau, les pilotes USB et firewire, et tout les systemes de fichier
dans le kernel (en gros il n'y a que les cartes son qu'on puisse virer -
encore qu'il y en a eu qui integraient un controlleur IDE).
Ca fait beaucoup, d'autant plus que certain drivers on besoin d'un firmware
a charger dans la carte de plusieurs 100aine de Ko. Donc, dans le cas
general, charger par module ce qu'il faut pour / ca n'est pas deraisonnable.

Je n'ai jamais prétendu que pour une installation, le traitement
ne devait pas être différent (de toute façon, on se retrouve plus ou
moins avec un / sur un cdrom ou un ramdisk). Je parle d'un noyau
statique dans le cas d'une utilisation normale.

Apres il n'est pas interdit de se recompiler un kenrel avec tout ce
qu'il faut en statique, et c'est meme recommande pour des serveurs de
prod AMHA.

Nous sommes donc bien d'accord.

JKB

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

Le 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].
--
Kevin

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Marc Espie ?crivait dans fr.comp.os.bsd :

In article <slrngjkib9.bcl.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:

Le 06-12-2008, ? propos de
Re: Boot des différents BSD,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :

JKB:

Ça me semble curieux comme concept. Sous BSD, ça panique point.

Je préfère de loin un Oops pour ce qui n'est pas crucial, ça permet
généralement d'arrêter un système de façon propre.

D'accord mais comment savoir si c'est crucial ou pas ?
J'aurais moyennement confiance dans un noyau qui en est arrivé à
déréfencer un pointeur NULL. Il a pu se passer tout et n'importe quoi.

Justement, le but du oops, c'est d'éviter qu'il ne se passe
n'importe quoi. Si on ne sait pas ce qui se passe, le noyau panique. Si
on peut récupérer le truc, il fait un oops. Le fonctionnement est plutôt
sain (en tout cas, plus sain qu'un Solaris 2.8 pour ne citer que lui qui
panique plus vite que son ombre pour tout et n'importe quoi).

Même une carte son ou un pilote de Cdrom (et que je te fais du DMA entre
n'importe quoi, et que je tape dans le bus pci...).

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

Enfin chacun fait ce qu'il lui plait.

JKB

L'enfer est pave de bonnes intentions.

A chaque fois qu'on permet a un *bug* dans un bout un peu critique du
systeme (le noyau quand meme !!!) de continuer apres avoir fait des
cochonneries (genre, avoir tape dans de la memoire qui ne lui appartient pas,
c'est le noyau, quand meme), on *encourage* les gens a continuer comme si de
rien n'etait, voire a ne pas corriger le bug (c'est pas grave).

Pour moi, l'exemple-meme de systeme qui marche salement, c'est windows. Il
y a des tonnes d'aberrations dedans, et des tonnes de comportement fuzzy
pour que ca continue de marchotter meme quand ca devrait pas.

Linux vient juste derriere, avec sa cohorte de hacks "au cas ou" qui permet
au hacker en herbe de s'amuser comme un petit fou, et de se pondre sa config
a lui qui fait des trucs tordus 'achtement bien avec un minimum (voire moins)
d'aspects standards du systeme. D'ou une Balkanisation des config, et des
bugs qui restent tres longtemps, parce qu'on ne sait jamais trop si c'est le
systeme qui deconne ou l'utilisateur qui va avec...

Bref, je ne suis pas du tout fan de cette philosophie, si par hasard tu
n'avais pas compris. Les effets les plus deleteres en etant les multiples
"patch" de iptables (au cas ou) ou la configuration invraisemblablement
complexe de pam...

Je ne suis pas un fanatique non plus de la solution 'on continue
même si quelque chose a planté quelque part'. Un oops, c'est un truc qui
nécessite un reboot rapide. Je ne fais non plus aucune
supposition sur la personne qui administre la machine en question. Je
prétends simplement que j'ai moins de problème avec des serveurs Linux
lorsqu'ils fonds des oops [qui sont récupérés automatiquement par un
script qui reboote proprement la machine] qu'avec des *BSD qui paniquent
directement alors qu'ils auraient pu faire (un peu) mieux.

À l'extrème limite, le oops devrait lui-même faire un sync correct
des disques s'il en est encore capable _puis_ paniquer (c'est un peu ce
que fait VMS et je ne pense pas que ce système soit des plus laxistes).

Cordialement,

JKB

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