Logo GNT
Actualités Tests & Guides Bons Plans
Prime Day iPhone 16 Copilot PS5 Pro Xiaomi 15 ChatGPT Tesla
Entraide Linux Autres OS BSD "openpty() failed", installing NetBSD 5.0.1 from netboot, on SPARC Station 4

"openpty() failed", installing NetBSD 5.0.1 from netboot, on SPARC Station 4

9 réponses
Avatar
Grunt
fu2: fr.comp.os.bsd

Bonjour,

(En espérant poster au bon endroit)
J'ai essayé d'installer NetBSD 5.0.1 depuis le réseau, sur une Station 4
de Sun.
L'installeur se lance correctement, mais plante au moment de labelliser
le disque dur, avec ce message:

"Status: openpty() failed
Commande: disklabel -w -r -f /tmp/disktab sd0 'CFP1080E SUN1.0'
Appuyez sur Entrie pour continuer"

J'ai essayé de mettre des noms gentils pour le disque, comme "sun" et
"SUN", ne sachant pas quelle était la longueur maximale ni les caractères
autorisés: ça ne change rien.

La seule piste que j'ai trouvée est un bug de NetBSD 4.0_RC4:
<http://gnats.netbsd.org/37433>

Dois-je comprendre que je vais devoir faire l'installation à la main?
(C'est la première fois que je touche à un BSD.)

Y a-t-il moyen d'en savoir plus au sujet de ce problème? Je ne sais pas
trop où chercher: /var/log est vide..

--
Cordialement\n Rémi
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Manuel Bouyer
In fr.comp.os.bsd Grunt wrote:
fu2: fr.comp.os.bsd



Bonjour,



(En espérant poster au bon endroit)
J'ai essayé d'installer NetBSD 5.0.1 depuis le réseau, sur une Station 4
de Sun.
L'installeur se lance correctement, mais plante au moment de labelliser
le disque dur, avec ce message:



"Status: openpty() failed
Commande: disklabel -w -r -f /tmp/disktab sd0 'CFP1080E SUN1.0'
Appuyez sur Entrie pour continuer"



Ca ressemble a un COMPAT_BSDPTY qui manque.
Quel kernel as-tu utilise ?

--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Avatar
grunt
Manuel Bouyer wrote:

In fr.comp.os.bsd Grunt wrote:
fu2: fr.comp.os.bsd



Bonjour,



(En espérant poster au bon endroit)
J'ai essayé d'installer NetBSD 5.0.1 depuis le réseau, sur une Station 4
de Sun.
L'installeur se lance correctement, mais plante au moment de labelliser
le disque dur, avec ce message:



"Status: openpty() failed
Commande: disklabel -w -r -f /tmp/disktab sd0 'CFP1080E SUN1.0'
Appuyez sur Entrie pour continuer"



Ca ressemble a un COMPAT_BSDPTY qui manque.
Quel kernel as-tu utilise ?



J'avais utilisé le "netbsd-GENERIC.MP".
Cette question m'en a fait essayer d'autres: le netbsd-GENERIC_SUN4U, qui
me paraissait logique. Même problème. Puis le netbsd-GENERIC, et ça ne
marche pas mieux.

Pourtant, COMPAT_BSDPTY est censé se trouver dans le noyau GENERIC, si j'en
crois ce que j'ai lu ça et là sur le Web.
Avatar
JKB
Le 24-01-2010, ? propos de
Re: "openpty() failed", installing NetBSD 5.0.1 from netboot, on SPARC Station 4,
?crivait dans fr.comp.os.bsd :
Manuel Bouyer wrote:

In fr.comp.os.bsd Grunt wrote:
fu2: fr.comp.os.bsd



Bonjour,



(En espérant poster au bon endroit)
J'ai essayé d'installer NetBSD 5.0.1 depuis le réseau, sur une Station 4
de Sun.
L'installeur se lance correctement, mais plante au moment de labelliser
le disque dur, avec ce message:



"Status: openpty() failed
Commande: disklabel -w -r -f /tmp/disktab sd0 'CFP1080E SUN1.0'
Appuyez sur Entrie pour continuer"



Ca ressemble a un COMPAT_BSDPTY qui manque.
Quel kernel as-tu utilise ?



J'avais utilisé le "netbsd-GENERIC.MP".
Cette question m'en a fait essayer d'autres: le netbsd-GENERIC_SUN4U, qui
me paraissait logique. Même problème. Puis le netbsd-GENERIC, et ça ne
marche pas mieux.

Pourtant, COMPAT_BSDPTY est censé se trouver dans le noyau GENERIC, si j'en
crois ce que j'ai lu ça et là sur le Web.



Si c'est une SS4 de Monsieur Sun, c'est une sparc32 avec un
MicroSparc II, donc le noyau est un GENERIC tout court. Le MP ne
sert à rien et le Sun4U non plus. Je n'ai jamais testé, mais le
Sun4U est destiné à faire tourner en 32 bits des machines prévues
pour 64 bits. Il pique sa configuration dans sparc64. Avec un peu de
chance, il nécessite un processeur sparc V8+.

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.
Avatar
Manuel Bouyer
wrote:
J'avais utilisé le "netbsd-GENERIC.MP".
Cette question m'en a fait essayer d'autres: le netbsd-GENERIC_SUN4U, qui
me paraissait logique. Même problème. Puis le netbsd-GENERIC, et ça ne
marche pas mieux.



Avec le netbsd-GENERIC_SUN4U ca m'etonnerais que ce soit le meme probleme:
celui la ne peut marcher que sur les ultrasparc, alors que netbsd-GENERIC.MP
et netbsd-GENERIC ne marche que sur les sparc non-ultra.
Si ca fait la meme chose avec netbsd-GENERIC_SUN4U et netbsd-GENERIC.MP,
c'est que tu ne boote pas le kernel que tu crois.
D'ailleur ca m'etonne que le netbsd-GENERIC.MP de la 5.0.1 boote tout
cours ...

--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Avatar
JKB
Le 24-01-2010, ? propos de
Re: "openpty() failed", installing NetBSD 5.0.1 from netboot, on SPARC Station 4,
Manuel Bouyer ?crivait dans fr.comp.os.bsd :
wrote:
J'avais utilisé le "netbsd-GENERIC.MP".
Cette question m'en a fait essayer d'autres: le netbsd-GENERIC_SUN4U, qui
me paraissait logique. Même problème. Puis le netbsd-GENERIC, et ça ne
marche pas mieux.



Avec le netbsd-GENERIC_SUN4U ca m'etonnerais que ce soit le meme probleme:
celui la ne peut marcher que sur les ultrasparc, alors que netbsd-GENERIC.MP
et netbsd-GENERIC ne marche que sur les sparc non-ultra.
Si ca fait la meme chose avec netbsd-GENERIC_SUN4U et netbsd-GENERIC.MP,
c'est que tu ne boote pas le kernel que tu crois.
D'ailleur ca m'etonne que le netbsd-GENERIC.MP de la 5.0.1 boote tout
cours ...



S'il n'y a qu'un seul processeur, je ne vois pas pourquoi (les
fameuses structures de description n'ont aucune raison d'être
référencées quelque par dans le code). Dans mon souvenir, j'ai
réussi à booter un GENERIC.MP sur une SS20 monopro.

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.
Avatar
grunt
De retour.

Pour installer NetBSD sur ma Sun Station4, j'ai décidé de repartir de zéro,
en suivant scrupuleusement ce tutoriel:

http://www.netbsd.org/docs/network/netboot/intro.sun.html

- Le serveur rarpd est lancé et configuré:
/etc/ethers:
08:00:20:79:96:41 Station4
/etc/hosts:
192.168.1.150 Station4 (entre autres)

Détail, le serveur rarpd est lancé avec les paramètres par défaut (-e -v).

Ensuite je démarre la station 4, je vois apparaître ceci dans les logs:
RARP request from 08:00:20:79:96:41 on eth0
RARP response to 08:00:20:79:96:41 192.168.1.150 on eth0

Normalement, tout marche bien. Sauf que, d'après la documentation, je
devrais avoir le message "boot: client IP address: 192.168.1.150", et ce
n'est pas le cas. Je n'ai pas non plus de message d'erreur: la station reste
sur "Boot device: /iommu.... File and args:", et attend indéfiniment.

Le clavier ne répond pas. Avant de passer à la configuration du serveur
tftp, je fais quoi? Je ne comprends vraiment pas pourquoi je reste bloqué
dans cette situation.
Avatar
grunt
Miod Vallat wrote:

Normalement, tout marche bien. Sauf que, d'après la documentation, je
devrais avoir le message "boot: client IP address: 192.168.1.150", et ce
n'est pas le cas. Je n'ai pas non plus de message d'erreur: la station
reste sur "Boot device: /iommu.... File and args:", et attend
indéfiniment.



S'il n'y a qu'un serveur rarpd configuré, c'est normal.

La sun a obtenu son adresse IP, c'est bien, mais ça lui fait une belle
jambe. Ensuite elle envoie une requête bootparams qui doit être traitée
par un serveur bootparams ou un serveur dhcp ; c'est une fois la réponse
à cette requête obtenue que la machine affichera plus de messages.



Oui, ça paraît logique en y repensant.

Bon, je viens de configurer tout ça bien comme il faut, seulement il y a une
chose qui me chiffonne.
En mettant -> option root-path "/srv/tftpboot/" <- dans la config du serveur
dhcp, la station Sun trouve ses fichiers, elle commence à démarrer.
Le problème, c'est que quand elle passe au NFS boot, j'ai ça:
"nfs_boot: trying DHCP/BOOTP"
Puis:
"root on 192.168.1.1:/srv/tftpboot/"

Autrement dit, il semblerait que BOOTP serve à la fois pour le tout premier
boot (celui qui sert à charger le bootloader, C0A80196.SUN4M dans on cas),
mais également pour savoir où se trouve la racine NFS.

J'avoue que je suis un peu perdu. J'ai parcouru dans tous les sens la
documentation de NetBSD: http://www.netbsd.org/docs/network/netboot/ , j'ai
cherché sur Google les messages d'erreur, mais la combinaison "OS peu
utilisé" et "matériel peu utilisé" fait que je ne tombe pas sur quelque
chose qui corresponde exactement à ce que je fais.

Quelqu'un aurait-il assez de temps à perdre pour m'expliquer comment
fonctionnent les choses?

De ce que je sais:
- la station démarre,
- elle lance une requête rarp,
- le serveur rarpd lui répond, et lui donne un nom de machine, ainsi qu'une
adresse IP,
- la station lance une requête BOOTP,
- le serveur DHCP lui indique où se trouvent les serveurs TFTP et NFS,
- la station demande un fichier construit d'après son adresse Mac, donc
C0A80196.SUN4M, qui lui sert de bootloader,
- elle démarre sur ce bootloader puis va chercher le reste (noyau, système
de base, installeur) via NFS, en utilisant le chemin donné par le serveur
DHCP.

C'est bien ça?
Avatar
Manuel Bouyer
In fr.comp.os.bsd wrote:
Oui, ça paraît logique en y repensant.



Bon, je viens de configurer tout ça bien comme il faut, seulement il y a une
chose qui me chiffonne.
En mettant -> option root-path "/srv/tftpboot/" <- dans la config du serveur
dhcp, la station Sun trouve ses fichiers, elle commence à démarrer.
Le problème, c'est que quand elle passe au NFS boot, j'ai ça:
"nfs_boot: trying DHCP/BOOTP"
Puis:
"root on 192.168.1.1:/srv/tftpboot/"



Autrement dit, il semblerait que BOOTP serve à la fois pour le tout premier
boot (celui qui sert à charger le bootloader, C0A80196.SUN4M dans on cas),
mais également pour savoir où se trouve la racine NFS.



Exactement.


J'avoue que je suis un peu perdu. J'ai parcouru dans tous les sens la
documentation de NetBSD: http://www.netbsd.org/docs/network/netboot/ , j'ai
cherché sur Google les messages d'erreur, mais la combinaison "OS peu
utilisé" et "matériel peu utilisé" fait que je ne tombe pas sur quelque
chose qui corresponde exactement à ce que je fais.



Quelqu'un aurait-il assez de temps à perdre pour m'expliquer comment
fonctionnent les choses?



De ce que je sais:
- la station démarre,
- elle lance une requête rarp,
- le serveur rarpd lui répond, et lui donne un nom de machine, ainsi qu'une
adresse IP,



Uniquement une adresse IP

- la station lance une requête BOOTP,



plutot bootparam non ? Pour ce que je me rapelle du fonctionnement de
l'openfirmware des Sun.

- le serveur DHCP lui indique où se trouvent les serveurs TFTP et NFS,



Donc ca serait plutot le serveur bootparam qui repond

- la station demande un fichier construit d'après son adresse Mac, donc
C0A80196.SUN4M, qui lui sert de bootloader,
- elle démarre sur ce bootloader puis va chercher le reste (noyau, système
de base, installeur) via NFS, en utilisant le chemin donné par le serveur
DHCP.



C'est ca, vu de tres loin.
En fait (la encore de memoire) le bootloader fait une requete dhcp
pour recuperer les parametres et utilise la reponse pour trouver le kernel
(je ne sais plus s'il le charge par tftp ou NFS par contre). Si dhcp ne repond
pas il essaiera bootparams.
Le kernel, une fois initialise, refait une requete dhcp (et si ca ne marche
pas il devrait essayer bootparams) pour trouver ses parametres reseau
et la racine NFS.

Donc chaque etape refait une requete dhcp ou bootparams pour pouvoir
passer a l'etape suivante.

--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Avatar
espie
De maniere toute bete, faire tourner un tcpdump sur le brin de reseau ne
devrait-il pas suffire a debugguer une bonne partie du probleme ?

On doit facilement voir la requete qui bloque, non ?