• Please review our updated Terms and Rules here

Sun Fire V120 and Netra 120 Power Supply

A

audiocrush

Member
Joined
Jul 21, 2023
Messages
30
Hi there :)

I was wondering if anyone on the forum knows if the power supply of the Sun Fire V120 and the Sun Netra 120 are interchangeable.
The manual mentions that both systems are exactly the same with the only difference being the Fire V120 is an AC PSU and the Netra using a DC PSU...

Since I have the opportunity to get a Netra 120 for next to nothing, I was wondering if I could put a PSU out of a Sun Fire V120 in it because I can also get that for next to nothing
Or at least that would be significantly cheaper than any other way to get hold of a sparc cpu system over here in germany (these prices really are insane)

So if anyone could tell me or even better if anyone ever performed a PSU swap that would be awesome :)

Cheers

Audiocrush
 
I also found out while reading the manual for the Sun Fire V120 and Sun Netra 120, that apparently there is a jumper JP8 on the mainboard.
It says that one jumper position is meant for the mainboard being used in a Sun Fire V120 and the other position is used for Netra 120.
Does anyone know if I would have to switch that jumper if I were to put a Sun Fire V120 PSU in the Netra 120?

I kind of think that would make sense since the only difference between the two systems appears to be the name and the PSU...
 
The Sun Fire series was designed for regular data center deployments while the Netra in addition to DC PSU, was supposed to be somehow designed or the case reinforced in such a way as to be compliant to the NEBS standard. If you have both it would be interesting for you to look and see if the Netra case is in any way sturdier or reinforced at the corners, stiffer, etc.
 
Hi Mr Improvement :D

unfortunately I have only ordered a Netra 120 and a PSU that is meant for a Sun Fire V120. The Netra I got for 40€ while a Sun Fire would cost me easily 5 times as much... So I can't compare the two.
But to be honest, I'd expect both to be exactly the same.
The manual for those systems on page 1-2 states in the second paragraph, that both systems are exactly the same, except for the power supply.
I wonder if the LOM has any awareness about what kind of system it actually runs in, or if the jumper is meant for that.
 
Ok quick update, I just got the PSU that is meant for a Sun Fire V120

I changed the jumper on the Netra 120 Motherboard JP8 as mentioned in the manual to the Sun Fire Position, swapped the DC PSU to the AC PSU and it works absolutely flawless.
At first I was a bit scared since connector 2 of the AC PSU is missing 2 pins, but everything works fine. LOM can talk to the PSU, gets all the voltage readings etc.

Hope this helps some people :)
 
audiocrush said:
Ok quick update, I just got the PSU that is meant for a Sun Fire V120

I changed the jumper on the Netra 120 Motherboard JP8 as mentioned in the manual to the Sun Fire Position, swapped the DC PSU to the AC PSU and it works absolutely flawless.
At first I was a bit scared since connector 2 of the AC PSU is missing 2 pins, but everything works fine. LOM can talk to the PSU, gets all the voltage readings etc.

Hope this helps some people :)
Click to expand...
It is nice to know it is that easy! What will you do with the V120?
 
Yes I didn't expect that.
Even openboot thinks now it is a Sun Fire V120 :D

Well I'm trying to install Solaris 10 using netboot from a Solaris 10 x86 VM on it, but so far with not much success.
Going the DHCP way overwhelmed me a bit with all those DHCP option definitions, because I have no clue which ones are necessary and which ones are not.
I tried with a dedicated debian machine running just isc-dhcp with supposedly the necessary 6 Options which are named by the ./add_boot_client script but it only sends tftp requests, gets some answer but apparently gets stuck in a loop pulling the first few bytes? I don't really know how to interpret the pcap unfortunately.

And going the RARP way with bootparamd also didn't really work this far either. It asks for the right file from tftp with the hex converted IP-Address as its name, gets an answer but then it keeps asking for the file again and also gets stuck in a loop.

All the involved machines are on the same subnet. Maybe I'll take a look at the openboot documentation tonight.

For a short moment I even tried to set up the dhcp server on the solaris 10 x86 machine but that was very convoluted and I also have no clue how the vendor strings are supposed to be. The Oracle documentation only mentions SUNW.ix86pc SUNW.someSunblademachine and SUNW.somesunservermodel but I can't find any info on where to find the vendor strings for my V120.
But besides that, it didn't even lease any IPs to my test-clients... My debian machine on the same host on the same subnet did just fine...

Maybe I have to find a bit more patience and keep reading :D
 
From memory, it is convoluted the first time. I am not sure if Solaris 10 needs a "bootp" daemon or if it can all be handled via DHCP. What I dimly remember is that the server hostname needs to be set up for it to work properly. So if you are handing it 192.168.10.10 as an IP, you need to be sure that "v120box.local" or whatever you choose, is the FQDN for that IP.
 
Well actually I made a bit of progress yesterday.
I changed the listening address from tftpd-hpa from ":69" to "0.0.0.0:69" and with that it startet responding properly to the broadcast tftp requests by the v120.
After that I could see in my pcap that it started asking for 255.255.255.255:111, so I'm certain the tftp part works now.
Unfortunately though my nfs-kernel-server on my debian machine doesn't seem to feel responsible for that request and simply ignores it.
I checked /proc/fs/nfs/versions and it shows +3 and +4 so that should be fine I guess.
Now it is the question of does that modern version of nfs server not support answering broadcast requests and I should maybe resort to the nfs server that comes with inetd (if that even still works on debian 12)
or is it just a configuration error on my part...
I mean I can mount the nfs share just fine manually...

thanks for the hint about the bootp daemon. Once I got rarp booting to work I'll revisit the dhcp route. I think there is a lot to learn that might still be relevant today since dhcp is still the thing :D
 
Screenshot 2024-03-20 at 23.00.10.png
Above is my tcpdump on the bootserver

and below is the output I'm getting on the console on my now V120...

It is slightly confusing... In the beginning of my tcpdump I caught what appears to be a tftp file transfer (that corresponds to the point in time the console counts up to 3a000) after that it continues with those udp packets below which are identified as "sunrpc" which basically means port 111 or nfs
But the console should show next that it was told a boot server ip, but it doesn't and insteads sends weird broadcast requests which I do not understand why


IMG_1252.jpg

what seems weird to me is the fact that on all other peoples console outputs about this topic on the internet, I've seen that after 3a000 it doesnt say "Using RARP/BOOTPARAMS... Internet Address" but instead it just says "Server IP address... and then Client IP Adress... and then goes on booting the kernel.

Basically I'm trying to replicate the process shown here:
 
Last edited:
OK! I think now I got it.

There is a newer firmware version apparently for my PROM...
The readme of the patch even begins the list of fixed bugs with one of my problems:

Update.to.flapjack2.4.0.17@OS
copyright

Problem Description:
4896390 DHCP problem during jumpstart install
(from 111991-06)

4882345 Turn memory clocks off for the unpopulated DIMM slots.
(from 111991-05)

4498663 Can't send "break" to OBP on LOM when extra character typed before "#." & "break
4722762 Error at Boot time: invalid vector Intr: number 0x7de, pil 0x0
(from 111991-04)

4646464 T1 200 does not support SCM pcmcia card reader.
(from 111991-03)

4631282 Jumpstart install on Netra T1 do RARP/ARP timeout


and the list goes on!
It appears that prior to the latest obtainable firmware version, netbooting is completely broken on all Netra T1, Netra 120 as well as Fire V120!

now I have to figure out how to get an OS on the damn thing to apply the patch :D
 
Well its been a while :D
In the meantime I updated to the latest firmware but it didn't help at all...

After a bit of investigating I found out that there was a lot of rpc traffic happening from the V120 to my debian boot server... but only in this one direction. It seems to ask 255.255.255.255 for BOOTPARAMS (100026). and rehn does tonnes of retransmissions because it doesn't get any answer...

meanwhile I checked rpcbind on my boot server, it has the correct number (100026) and is running, as well as rpcbind and rpcbind.socket.

So I did an strace which I do not understand AT ALL :D
Maybe someone on the forum understands. It looks to me though somewhere between rpcbind and bootparamd is the source of all my problems...
 

Attachments

  • strace-rpcbind.txt
    34.1 KB · Views: 1
I would check some settings, you may have to dig, sadly. I would say that you should check the following:

1. there are no firewall rules on any part of the network interfaces you are using. Note that NAT rules are not shown unless you specifically ask to see them (there are different network tools however depending on Linux version, so you have to read the docs)

2. See if you can set NFSv2, remember that you don't need a read/write, only a readable share, so security is not a concern.
 
the fun part is, that if I run rpcinfo -p BOOT-SERVER-IP-Address
I get all the services correctly listed.
I can also mount the nfs shares on that machine. So I have to assume that it is working fine.
It is also a fresh debian 12.5 server install just for this purpose. I have checked if it came with any firewall services preinstalled, but there are none set up.

I'll try nfsv2 tomorrow, it's already 1:30am over here :D
 
You must log in or register to reply here.
Back
Top