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

Ha oui; donc en fait il n'a pas de table des partitions. Le miniroot est
destine a etre ecrit sur une parititon specifique, pas sur
le debut du disuqe.
La tu peux tenter de lui repondre "sd0c" quand il demande le root-device

Et ça permet d'aller un peu plus loin..
Ca monte la racine, ça trouve le filesystem, mais ça ne trouve pas
init..
http://kevin.denis.free.fr/images/sd0c.png
Après avoir lu le message de Miod, je pense effectivement que l'esp/DMA
ne tient pas la route côté qemu et que netBSD n'arrive donc pas à
chercher ce qu'il lui faut :(
J'ai essayé de mettre /bin/sh et le résultat est le même.

Pour info, qemu-system-sparc émule:
kevin@zipslack:/tmp$ qemu-system-sparc -M ?
Supported machines are:
SS-5       Sun4m platform, SPARCstation 5 (default)
SS-10      Sun4m platform, SPARCstation 10
SS-600MP   Sun4m platform, SPARCserver 600MP
SS-20      Sun4m platform, SPARCstation 20
SS-2       Sun4c platform, SPARCstation 2
SS-1000    Sun4d platform, SPARCserver 1000
SS-2000    Sun4d platform, SPARCcenter 2000

Les machines autres que Sun4m ne sont pas supportées par openBIOS (ça
se coupe par un message envoyé sur le port série qui dit que ça ne
fonctionne pas..)
Sur SS-600MP et SS-20, ça plante rigoureusement au même endroit.

J'ai essayé de mettre le0 comme root device. Ca effectue une requête
DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule
un serveur DHCP, un serveur tftp, et une annonce bootp:
qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net
Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau,
mais:
nfs_boot: trying DHCP/BOOTšP
nfs_boot: DHCP next-serveur 10.0.2.2
nfs_boot: my_addr=10.0.2.15
nfs_boot: my_mask=255.255.255.0
nfs_boot: gateway=10.0.2.2
nfs_boot: getfh - no pathname
no file system for le0
cannot mount roor, error = 79

Donc je pense que l'argument -bootp n'est pas passée. Le getfh, c'est
bien le nom du fichier à télécharger en tftp?
--
Kevin