Cerca il comando in OBP

C'è una cosa che molti non sanno, e che non ricordo nemmeno più dove l'ho appresa qualche anno fa.

OBP, diamo per scontato che sappiamo di cosa stiamo parlando, ha un "modo", chiamiamolo così, per aiutare nella ricerca di un comando Forth, istruzione o di qualsiasi cosa si voglia eseguire.

Mettiamo che vogliamo dire a OBP di fare un probe di tutti i devices scsi che sono connessi al sistema, ma non ricordiamo precisamente il comando: c'è forse probe nel nome che non ricordiamo, e quasi sicuramente anche scsi, ma chissà in che ordine:

# sifting probe

ritorna come risultato tutti i comandi che contengono i caratteri probe nell'ordine immesso. Tra i vari risultati troviamo ciò che ci serve, ovvero probe-scsi-all. Anche un sifting scsi ci avrebbe aiutato certamente.
Insomma, io trovo sifting, un pò il tipo di aiuto nel trovare il comando giusto scavando nella memoria che da un ambiente bash grazie all'autocompletamento col e a una variabile $PATH ben settata.

Maledetto initiator ID aka "Scsi initiator ID is now 6"!!

Rifacendo un cluster con un vecchio JBOD scsi come shared storage, sono incorso in un conflitto di target ID nella catena scsi tra lo storage sharato e i due nodi.

In questo tipo di configurazione, uno dei due nodi va configurato ad hoc, agendo su alcuni parametri in OBP, in modo da evitare appunto conflitti.

Questo passaggio l'ho fatto già diverse volte, non tantissime, visto che per lo più capita di lavorare su devices fiber-channel, ma abbastanza da essere routine.

Si tratta di agire sulla variabile scsi-initiator-id di un nodo, portando il valore dal default (7) a 6, e poi inserire uno script in nvramrc, abilitandone l'uso mettendo a true use-nvramrc?. Questo in spiccioli aggira il conflitto tra gli HBA dei due nodi dandogli ID diversi, e poi al caricamento di Solaris, risetta in modo trasparente l'ID. Fatto.

Booto. Parte. Uno sfacelo. Decine di errori con molto poco senso, che tutto dicono, tranne quello che è ovvio (vabbè, l'ho esagerata, il loro senso lo hanno).

C'è da dire, che avevo già installato Solaris10 via flar sui nodi, e anche Sun Cluster che era in installmode, in attesa che designassi una DID come quorum.

Dopo un pò di riavvii stressanti e di set-defaults di OBP e rifacimento dei settaggi di cui sopra, mi illumino. Booto un solo nodo, lo booto -xvsr e osservo:
manca la dichiarazione "Scsi initiator ID is now 6". Viene bypassato, il trucco non viene implementato.

Disabilito il parsing di nvramrc settando a false "use-nvramrc?".
Ribooto ... nulla.
STOP-A brutale! Spengo lo storage. Do un reset-all. Ribooto.
Lo vedo: "Scsi initiator ID is now 6" !!
Poweroff ... accendo il JBOD ... accendo il nodo ... boot -v
Pare andare. Accendo l'altro nodo ... TUTTO OK!!!
Riabilito use-nvramrc? . Riavvio i nodi, tutto va.

Morale della favola:
le modifiche vanno implementate a storage spento (magari prima di installare Solaris, ma non è mandatorio come ho letto in alcuni documenti sull'argomento).
Dopo le modifiche è bene dare un reset-all. Provare che la configurazione venga usata. Spegnere e riavviare a storage acceso. Avviare l'altro nodo per avere conferma.

Base10/16 e jumpstarting solaris da linux troubles

Jumpstart da rete, da ambiente misto, server Linux che installa un sistema Solaris 10 su SPARC. Sto rifacendo il clusterino di casa. Come sempre rinfresco i passi da eseguire scorrendo la guida che ho scritto qualche anno fa. Sta qui .

Tutto bene. Finchè non c'è da linkare inetboot con ln -s nominandolo coll'esadecimale del IP della macchina bersaglio.

Qui mi impanico come al solito ... non riesco mai a ricordare come si fà.
Ma alla fine ci arrivo.
Ecco:

Prendi IP, convertilo in forma binaria e da lì a esadecimale!! Ora so dove cercare quando dovrò rifarlo e mi sarò dimenticato; se non entra non entra disse Siffredi in qualche suo film (almeno presumo, mi pare una battuta abbastanza scontata).

Stavolta ho dovuto anche improvvisare passando a obp il kernel da caricare; pareva non essere in grado di trovarlo. Quindi /platform/sun4v/kernel/unix
Probabilmente un effetto collaterale di nfsv4? Indagherò.

Indagato:
apt-get install nfs-user-server

rimuove l'implementazione kernel-nfs e installa quella userspace. Ci avevo preso, era un problema legato a incompatibilità tra nfs4 Solaris e Linux a quanto pare. Basta riavviare il processo dall'inizio e questo va avanti trovandosi il kernel da caricare.

Altra cosa. Se si usa il Network Manager su Linux, è bene disattivarlo o configurarlo perchè l'interfaccia che serve i dati abbia indirizzamento statico per evitare scherzi tipo che tiri giù l'interfaccia.

Altro simpatico problema:

svc.configd: smf(5) database integrity check of:

/etc/svc/repository.db

failed. The database might be damaged or a media error might have
prevented it from being verified.  Additional information useful to
your service provider is in:

/etc/svc/volatile/db_errors

The system will not be able to boot until you have restored a working
database.  svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes.  The command:

/lib/svc/bin/restore_repository

Bla,Bla Bla ... il problema riguarda le opzioni di esportazione dei filesystems in /etc/exports.
La soluzione è esportare così:

/sol/Boot *(insecure,sync,ro,no_root_squash)
/vcdrom *(insecure,sync,ro,no_root_squash)

Ora dovrebbe andare.

Una descrizione di molti altri fastidiosi problemi incontrati in questo tipo d'installazione e relativa soluzione si trova qui

Do you remember OBP? E le env settate secoli fa?

Quando tiri di nuovo fuori la vecchia Ultra10, sicuramente oltre a una versione vecchiotta di Solaris, le variabili d'ambiente di OBP saranno settate ad minchiam, o comunque diversamente da come ti servono.
In questo momento monitor e tastiera al boot sono useless, probabilmente input e output devices sono settate a ttya o ttyb; urge un reset.

E allora, spegni, con tastiera e monitor collegati riaccendi. Tieni premuto STOP+N

Come per magia il mitico banner appare... e tutto è fresco che sa quasi di fabbrica!