Le contexte: récupération d'une vielle Sun SS20: c'est aujourd'hui une machine obsolète, mais qui reste d'une grande qualité. Beaucoup de plaisir pour bien peu d'argent !
On commence par quelques aventures avec le matériel, histoire de fouiner un peu avant les choses sérieuses, installer une version d'OpenBSD par le réseau sur cette nouvelle meeEeeEeEEErveille.
Sun SS20 - Sparc Station 20 ; processeur 50 Mhz. ; disque 1 Go SCSI,
carte Ethernet 10Mb, sbus. Pas d'écran, de terminal ni de clavier.Ça
fait rêver. On va tenter un boot
par le réseau (net-boot
) en
surveillant tout cela via le port série, connecté à un pc portable.
Au sujet du cable série: la sun SS20 dispose d'un port série 25 femelle, il lui faut donc un 25 mâle, à connecter au port série 9 mâle pécé (il faut donc sur le cable un 9 femelle). Soit:
SS20 |-----------------| P.C. 25 mâle 9 femelle
note: cette filasse est assez difficile à trouver, mais elle se bricole, au pire, assez facilement à partir d'autres cables qu'on trouve, assemble et désosse.
Bon, histoire d'améliorer le google rank de cette page, parlons de nos premiers émois, en tournant autour de la station quelques jours, avec respect. Laissons-la booter, pour entendre sa poésie même si on ne sait rien d'elle pour le moment.
L'application minicom
a d'abord été utiliées pour controler le
boot de la sun depuis le port série d'un pc, auquel est connectée la
sun, mais cela n'a pas bien marché pour des raisons restées assez
obscures, on parlera donc ici du logiciel cu
(du paquet uucp
)
qui a finalement été préféré et cela marche maintenant très
bien. Voici des traces après avoir allumé la sun:
$ cu -s 9600 -l /dev/ttyS0
ok help
ok test-all Testing /memory@0,0 Testing /obio/SUNW,fdtwo@0,700000 Testing floppy disk system. A formatted disk should be in the drive. Recalibrate failed. The floppy drive is either missing, improperly connected, or defective. Selftest failed. Return code = -1 Testing /obio/zs@0,0 No Keyboard Selftest failed. Return code = -1 Testing /obio/zs@0,100000 Testing /iommu@f,e0000000/sbus@f,e0001000/ledma@f,400010/le@f,c00000 Using AUI Ethernet Interface Internal loopback test -- succeeded. External loopback test -- Lost Carrier (transceiver cable problem?) send failed. Using TP Ethernet Interface Internal loopback test -- succeeded. External loopback test -- Lost Carrier (transceiver cable problem?) send failed. Selftest failed. Return code = -1 Testing /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000
Plein de poésie donc, mais violente et engagée. Après une lente
exégèse purificatrice, on comprend qu'apparemment, ethernet ne marche
pas bien. On reboot, mais cette fois, on prend bien soin de lui avoir
envoyé un signal BREAK lors du boot. Ah, à propos, pour lancer un
break
avec cu
se fait, lors du démarrage, en tapant ~#
.
Là, la mélodie secrète de la SS20 est bien plus harmonieuse.
$ cu -s 9600 -l /dev/ttyS0 Connected. SMCC SPARCstation 10/20 UP/MP POST version 3.1 (11/19/93) CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache CPU_#1 ******* NOT installed ******* CPU_#2 ******* NOT installed ******* CPU_#3 ******* NOT installed ******* >>>>> Power On Self Test (POST) is running .... <<<<< SPARCstation 20 (1 X 390Z50), No Keyboard ROM Rev. 2.15, 128 MB memory installed, Serial #7407019. Ethernet address 8:0:20:1a:a6:00, Host ID: 727105ab. Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: SunOS Release 5.6 Version Generic_105181-23 [UNIX(R) System V Release 4.0] Copyright (c) 1983-1997, Sun Microsystems, Inc. configuring network interfaces: le0. Hostname: musun98007 The / file system (/dev/rdsk/c0t3d0s0) is being checked. /dev/rdsk/c0t3d0s0: 41250 files, 739256 used, 161262 free /dev/rdsk/c0t3d0s0: (4910 frags, 19544 blocks, 0.5% fragmentation) The system is coming up. Please wait. add net default: gateway 123.456.789.123 NIS domainname is sc41 starting rpc services: rpcbind keyserv
HMmhmHMhmHMHMHMhmhmHMmhhmhmm !! ELLE PARLE ! ELLE CHANTE ! LE CHANT DU MONDE !
Le système semble rester bloqué sur starting rpc services: rpcbind
keyserv
; au meme moment, un tcpdump sur le pc donne comme
résultat:
tcpdump: listening on eth0 17:16:46.791504 123.456.789.123.32785 > 123.456.255.255.sunrpc: udp 96 (DF) [ttl 1]
plein de fois. Mais plein.
Pas de doute, c'est la sun qui pleure sa maman car elle n'arrive pas à
se connecter sur yp
.
Cela veut dire aussi que juste avant, un break
astucieusement
lancé a permis d'avoir le bootloader
. Bon à savoir pour la suite,
faudra faire cela tout le temps.
Histoire d'espérer un boot normal après un `time-out` sur les
tentatives de connexion sunrpc
, on laisse la babasse mariner
tranquillement pendant un gros weekend. Elle en profite pour brailler
continuellement et remplir les logs du firewall avec ses tentatives de
connexion permanentes (oups, pardon gentil admin). En résumé, elle
refuse de booter sans ses connexions sunrpc, autrement dit, une partie
essentielle du système est distante. Le système seul n'est pas
autonome, donc, pas de timeout, elle s'entête, la bougresse !
Pour tenter de booter quand même, tentons un:
ok> boot -s
qui réussit, mais le système réclame le mot de passe root pour la
maintenance (ou, comme toujours CTRL-D
pour le processus normal de
démarrage). Mot de passe qu'on ne connait pas, pour cause de
récupération.
D. me conseille de faire un montage complet par nfs avec un système entièrement configuré. On repère:
ok> boot net -s
Mais il faut creuser un peu plus. Donc, dans les docs NetBSD sur le port Sparc32, on lit:
Ramdisk kernel This one is no trouble at all. Place the ramdisk kernel at the root of your nfs mountpoint, named netbsd. This ramdisk kernel contains the /dev entries and install tools. The bootloader should just load this kernel and immediately start the install tools.
Donc, si on en croit la doc (haha, pourtant, ne jamais faire, cela famous last words), cela devrait juste marcher.
Pour mémoire:
Why do you want an "installer" if you are so far, that you have a complete system running diskless? Installing the system on a disk from a diskless boot is easy and straightforward:
disklabel sd0 > /tmp/dl # read in core default label disklabel -r -R sd0 /tmp/dl # write it to the disk disklabel -i sd0 # and edit it. -i needs a valid
Et alors …:
newfs /dev/rsd0a newfs .... mount -o async /dev/sd0a /mnt # async speeds things up during... mount ... tar xzpf /where/ever/your/dist/sets/are.tgz -C /mnt tar ... cd /mnt/dev && ./MAKEDEV all cd /mnt/usr/mdec ../installboot .... # works only in singe user mode cd /mnt/etc vi rc.conf # look at /etc/defaults/rc.conf vi fstab echo sunshine > myname echo inet 192.168.1.1 netmask 255.255.255.0 > ifconfig.le0 echo 192.168.1.254 > mygate # or what ever you want / need vi ... reboot # from disk. Thats all. No fscking "installer" needed. p.s. for a in /your/dist/sets/*.tgz ; do tar xzpf $a -C /mnt ; done does the unTARing all in one line.
Bon, en fait, tout cela est bien marrant, mais changeons de jeu, car on n'a pas eu le temps de tenter ce truc, qui pourrait être convi: en gros, ca pourrait être un peu «comme booter sur un CD-ROM Live CD ou une clef USB Live-Key» mais, par le réseau. Malgré l'envie, ce point n'a pas été creusé.
Finalement, on décide que la gentille machine va servir à quelque chose et on va lui donner un joli système, ca sera, hop, OpenBSD (la version utilisée pour ce truc est celle disponible à ce moment, c'est à dire 3.7, oula, ca ne nous rajeunit pas tout cela).
L'installation se fait à partir d'une machine OpenBSD (3.7 pour cet exemple) sur un pc, en vue d'installer OpenBSD 3.7 sur la SS20. Suivez bien.
On récupère l'archive 3.7/sparc d'OpenBSD sur la machine courante (le PC).
Sur le pc: créer deux fichiers: /etc/ethers
et /etc/bootparams
.
/etc/ethers
contient l'adresse MAC et le nom symbolique du système
à installer. Le fichier /etc/bootparams
contient les montages NFS
nécessaires pour le système de boot en réseau (netboot ou netinstall)
depuis le système hote vers le système à installer.
Dans le fichier /etc/ethers
:
% cat /etc/ethers 8:0:20:1a:a6:45 ss20
Dans le fichier /etc/bootparams
:
% cat /etc/bootparams ss20 root=vob:/usr/local/home/ss20/root swap=vob:/usr/local/home/ss20/swap
On récupère ces infos, notamment l'adresse MAC de la SS20, évidemment, en fouinant sur la machine comme on l'a fait ci-dessus. Vous aviez de toute façon bien suivi, hein ?
Le dépôt local OpenBSD sur le pc est ici par exemple, /usr/local/home/ss20/root simplement parce que la partition /usr/local avec plein de place libre.
Ne pas oublier à renseigner, dans /etc/hosts
, à la fois le système
hote et le système cible:
192.168.43.21 vob ## pc qui sera le serveur de boot 192.168.43.31 ss20 ## station à installer
Il faut ensuite préparer les répertoires propres à l'installation,
ici, /usr/local/home/ss20
:
# mkdir -p /usr/local/home/ss20/root # dd if=/dev/zero of=/usr/local/home/ss20/swap bs=1k count=16000 # cd /usr/local/home/ss20/root # tar xzpf /chemin/archive/openbsd/sparc/base37.tgz # cp /chemin/archive/openbsd/sparc/bsd.rd . # ln -s bsd.rd bsd
Frisson magique ! on a préparé le lit de la petite !
On doit donc avoir dans le répertoire:
% pwd ; ls -F /usr/local/home/ss20/root altroot/ bsd@ dev/ home/ root/ stand/ usr/ bin/ bsd.rd etc/ mnt/ sbin/ tmp/ var/
Songeons maintenant à exporter par NFS le répertoire principal, toujours sur le pc:
% cat /etc/exports # [...] /usr/local/home/ss20/ -alldirs -network 192.168.43 -mask 255.255.255.0
Modifiez bien évidemment votre réseau (par exemple 10.0.0 ou 192.168.0) pour que cela corresponde à votre configuration). En cas de problème sur NFS, voir ci après, y'a d'autres enjeux. Parfois.
On va aussi placer quelques fichiers aussi pour l'utilisation du
protocole tftp
. tftp
pour trivial ftp est le canal magique
par lequel la SS20 va naître au monde, ce qui permet de faire le Bien
à partir du rien.
# mkdir /tftpboot # cp /chemin/archive/openbsd/sparc/boot.net /tftpboot/
Reste maintenant à lancer les démons bas niveau qui vont permettre à
notre sun à installer de configurer automatiquement son réseau. C'est
l'objet des démons rarpd
et rpc.bootparamd
. Sur le système
servant à l'installation, taper:
# rpc.bootparamd # rarpd -l -f le1
(le1
étant bien évidemment à remplacer par le nom de la carte réseau
qui relie le système hote à au système à installer).
Maintenant, une belle difficulté nous arrive … La sun aura besoin d'un paramètre supplémentaire, que nous ne connaissons pas encore: son nom interne.
Lorsqu'on va faire un boot net
avec la sun, elle va demander un
fichier d'un nom bizarre sur le serveur tftp. Ce nom bizarre doit être
un lien symbolique avec notre fichier boot.net
… Le problème est
donc qu'on ne connait pas ce nom. Avec un serveur tftp Linux/Debian,
les options de log et de debug peuvent, lorsque la sun se connecte,
nous dire le nom du fichier recherché par la SS20. Mais sous OpenBSD
sur le PC (système qui fait office de serveur tftp), ces options
n'existent pas. On va donc ruser, en utilisant la commande d'analyse
réseau tcpdump
(encore une fois, il faut remplacer le1
par
l'interface réseau qui va bien):
# tcpdump -i le1 port tftp
Faire maintenant booter la sun:
1. mettre la sous tension 2. envoyer un BREAK 3. au prompt de l'OpenPROM, la commande suivante:
ok> boot net
Si boot
net échoue (et il a échoué ici plusieurs fois) tapez:
ok> boot net-tpe
Sur le système hote qui fait le tcpdump, on doit voir apparaître:
# tcpdump -i le1 port tftp 03:47:58.153426 ss20.maleloria.org.1263 > vob.maleloria.org.tftp: 23 RRQ "C0A42B2F.SUN4M"
HAhaHAHAHaHaHahaHAHA : l'a lâché le morceau !
Le mot bizarre après le RRQ est le nom magique. On file vers
/tftpboot
et on tape:
# cd /tftpboot && ln -s boot.net C0A42B2F.SUN4M
Si vous devez faire cela, mettez, bien sûr, le nom que votre sun crachera. Arrêter le boot de la sun, puis la redémarrer. L'installation commence alors tout simplement:
ok ok boot net-tpe Boot device: /iommu/sbus/ledma@f,400010:tpe/le@f,c00000 File and args: Lost Carrier (transceiver cable problem?) Twisted pair cable problem or hub link-test disabled. Use the PROM command "help ethernet" for more information. ARP/RARP send failed. Check Ethernet cable and transceiver. 10600 >> OpenBSD BOOT 2.2 boot: client IP address: 192.168.43.31 boot: client name: ss20 root addr=192.168.43.21 path=/usr/local/home/ss20/root Booting bsd @ 0x4000 [...]
On ronronne de plaisir.
Il arrive parfois que le logiciel cu
se déconnecte. Cela n'a pas
grande importance. On s'y reconnecte.
Après l'installation, qui est très classique, même sur cette architecture, le boot est très long. C'est lié à la création des clefs cryptographiques du système:
ssh-keygen: generating new DSA host key... done. ssh-keygen: generating new RSA host key... done. ssh-keygen: generating new RSA1 host key... done. openssl: generating new isakmpd RSA key...
Mais après ce délai, tout fonctionne:
starting network daemons: sendmail inetd sshd. starting local daemons:. standard daemons: cron. Sun Aug 28 02:43:14 CEST 2005 OpenBSD/sparc (ss20.maleloria.org) (console) login: root Password: OpenBSD 3.7 (GENERIC) #312: Mon Mar 21 00:14:33 MST 2005 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have mail. Terminal type? [sun] Don't login as root, use su Read the afterboot(8) man page for administration advice. ss20# uname -a OpenBSD ss20.maleloria.org 3.7 GENERIC#312 sparc ss20#
HoohohOHOHOhOhoHOHoHOhoOho. Non seulement elle chante, mais en plus, maintenant, on peut lui parler !@#
Le système reste cependant assez lent, voici quelques exemples:
# time pkg_add -v ftp://ftp.openbsd.org/pub/OpenBSD/3.7/packages/sparc/vim-6.3.61-no_x11.tg z parsing vim-6.3.61-no_x11 Dependencies for vim-6.3.61-no_x11 resolve to: gettext-0.10.40p2, libiconv-1.9.2 (todo: lib iconv-1.9.2,gettext-0.10.40p2) vim-6.3.61-no_x11:parsing libiconv-1.9.2 vim-6.3.61-no_x11:libiconv-1.9.2: complete vim-6.3.61-no_x11:parsing gettext-0.10.40p2 Dependencies for gettext-0.10.40p2 resolve to: libiconv-1.9.2 vim-6.3.61-no_x11:gettext-0.10.40p2: complete vim-6.3.61-no_x11: complete 6m47.37s real 1m4.97s user 0m19.26s system
Tout de même. Et nan, c'est pas le réseau qui rame.
Si votre serveur NFS ne fonctionne pas correctement, c'est que vous ne l'avez pas configuré. Il faut suivre les indications de ce document: http://www.openbsd.org/faq/faq6.html#NFS
Pour aller plus vite: éditer /etc/rc.conf
(sur une machine de
prod, préferer /etc/rc.conf.local
) et mettre les chaînes suivantes
comme indiqué:
nfs_server=YES portmap=YES
On pourrait mettre aussi rarpd
et autre, mais on les lancera à la
main une seule fois. Éditer /etc/exports
comme indiqué
précédemment. Rebootez la machine. Vous devez avoir les démons
suivants qui tournent: mountd
, portmap
, nfsd
(plusieurs).
Assurez vous-en:
% ps auxwww|grep -i nfs 92 ?? IL 3:30AM 0:00.01 nfsd: server (nfsd) 120 ?? Is 3:30AM 0:00.01 nfsd: master (nfsd) 92 ?? IL 3:30AM 0:00.76 nfsd: server (nfsd) 92 ?? IL 3:30AM 0:00.00 nfsd: server (nfsd) 92 ?? IL 3:30AM 0:00.01 nfsd: server (nfsd)
Pour vous assurer que vous pouvez bien monter vos partages NFS, tapez
showmount -e votre_machine_nfs
. Elle doit indiquer les partages
offerts, par exemple:
% /sbin/showmount -e 192.168.43.21 Export list for 192.168.43.21: /usr/local/home/ss20 (everyone
La machine OpenBSD 3.7 hôte à partir de laquelle l'installation d'OpenBSD sur la sparc a été effectuée était en fait une machine virtuelle VMWare. C'était tout ce qu'il y avait sous la main. Mal. Pardon.
On a choisi d'installer une machine virtuelle ad-hoc pour,
précisément, installer tous les services (comme rarpd
) sans
problème, tester sans avoir de risquer de mettre en danger la
configuration d'une vraie machine, vraiment utilisée.
Or, dans les opérations décrites ci-après, il s'avère que VMWare ne permet pas le passage en mode promisc de la carte réseau, pour capturer le nom de la sun32 lors du boot.
Pour réaliser cela, éteindre les machines virtuelles, arrêter le système VMWare, puis taper:
chmod a+rw /dev/vmwet0
Puis relancer VMWare et la machine virtuelle. On peut alors passer le système hébergé en mode promisc.
Voir en particulier le document: http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=287
sur ce sujet. VMware. Désolé.
http://www.netbsd.org/Documentation/network/netboot/local.install.html
http://www.netbsd.org/Documentation/network/netboot/
http://www.sunhelp.org/pipermail/geeks/2002-April/018089.html
Note: oui, IP et MAC ont été changées et le droit à la vie privée alors #@!