Category: Troubleshooting

  • The storage BP2 SAS A0 cable is not connected, or is improperly connected.

    The storage BP2 SAS A0 cable is not connected, or is improperly connected.

    The R740xd has specific numbers it uses to refer to different backplanes on your server. The R740xd can technically support 3 different backplanes. Of course you have the primary backplane. This is the backplane used to install drives through the front of the server. The other 2 backplanes refer to the mid and rear flex bays if you have those installed.

    So quite simply:

    • BP0 – Rear backplane for flex bay
    • BP1 – Primary backplane for the front drive slots
    • BP2 – Backplane for the mid bay

    So if you’re getting backplane errors on BP2 this means the server is detecting a problem with your mid bay. (See the end of this post if you don’t actually have a mid bay installed!)

    This could happen for a number of reasons. If you just installed the mid bay it’s likely you have the wrong cable installed or have it plugged into the wrong port on the backplane. The easiest first troubleshooting step is ensuring the cable is plugged in properly. The proper cable will have 2 SAS connectors on one end that plug into the mid bay and then a single SAS connector on the other that routes along the side of the chassis and plugs into the A1 port on the primary backplane. Perhaps you have it plugged into the A2 port (12 bay model) or the B1 port (24 bay model.)

    You also might have the incorrect cable. The R740xd has 2 primary models. The 12 bay LFF version and the 24 bay SFF version. Both of these servers use different cables to interface with the backplane. The mid bay is physically the same hardware but both servers will use a different cable due to differences in the primary backplane design. You might have a cable designed for the 24 Bay installed in a 12 bay server, or vice versa.

    Take a look at the cable and then look at the port you’re plugging it into on the backplane. The port numbers should match. For example, on an R740xd 12 bay the ports for the mid bay and rear flex bay are labeled A1 and A2.

    A cable labeled A1 should only go into a port also labeled A1

    The cable will also be labeled the same. A cable labeled anything else is not going to work. Cables for the 12 and 24 bay systems might fit in each others ports but you’ll notice they go in at awkward angles. In the case of the 24 bay chassis, using a cable designed for the 12 bay will block the B1 port due to the angle of the connector. It may also throw errors. You must source the correct cable.

    However, If you’ve determined that you’re using the correct cable it’s time to look deeper. I recently built a server and had this error at boot time. I was positive I had the correct SAS cable connected to the mid bay. Most of the time I simply replace the entire mid bay but this time I looked a little deeper and noticed the cable was physically damaged. Sometimes there is obvious damage to the cable from being stuffed against and forced down into the cable channeling system.

    Replacing the cable resolved the issue. Other times the backplane itself was faulty, In that case the backplane and arguably the entire mid bay should be replaced. My logic is if you’re going to order parts to fix the problem you should order every possible part necessary to avoid wasting time and reordering should one of the parts alone fail to fix the problem.

    I’ve also had some success updating the CPLD firmware on the system. This was a classic fix we discovered at work. Sometimes we’d have a problem with one of the backplanes and swapping out the entire hardware for new stuff didn’t fix the issue. In these cases we found updating the firmware for the complex programmable logic device was the solution. This chip is involved with detecting whether or not cables are plugged in and what SAS lanes are active, so to speak. It has worked enough times that I’d say it’s worth a shot to try.

    So just to reiterate:

    • Ensure you have the right cable
    • Ensure the cable is plugged into the correct port on the backplane (A1)
    • Ensure the cable is not damaged

    Assuming all of the above conditions are satisfied yet the issue is still not resolved, try updating the CPLD firmware. Failing that it’s probably time to order a new mid bay cable, another backplane for the midbay, or the entire backplane configuration with the correct cable from a trusted source.

    As a final note, I’ve also seen this error pop up in servers that have no flex bay installed at all. In some cases updating the CPLD firmware resolved the issue, in other cases we considered the server failed at least for a serious production environment.

  • MIKROTIK hAP ax S Wifi running extremely slow on Thinkpad T480 [SOLVED]

    MIKROTIK hAP ax S Wifi running extremely slow on Thinkpad T480 [SOLVED]

    I have a Mikrotik hAP x S router configured with mostly default settings. I noticed wifi was running extremely slow on the default network. I first tested the network while plugged straight into the router and saw more or less what I expected – a 500Mbps download speed from my carrier.

    Testing the wifi connection was a different story. I was only achieving a maximum download speed of 3Mbps.

    I ran the following at my Debian terminal:

    06:43 PM-adam@adampc:~$ iw dev wlp3s0 link
    Connected to d0:ea:11:13:af:b7 (on wlp3s0)
           SSID: MikroTik-13AFB7
           freq: 2462
           RX: 16009177 bytes (20247 packets)
           TX: 32704312 bytes (30902 packets)
           signal: -41 dBm
           rx bitrate: 6.0 MBit/s
           tx bitrate: 300.0 MBit/s MCS 15 40MHz short GI

           bss flags:      short-preamble short-slot-time
           dtim period:    1
           beacon int:     100

    This revealed a healthy TX rate but an absolutely abhorrent RX rate.

    After a lot of troubleshooting I discovered both the 2.4 and 5Ghz bands were sharing the same SSID.

    The immediate solution is to simply put the 2 bands on different SSIDs.

    wifi–>interface–>wifi1 allows you to change the SSID for the 2.4Ghz network.

    Why this fixes the problem:

    When both the 2.4 GHz and 5 GHz radios share the same SSID, your laptop (and most Wi-Fi clients on Linux in particular) has to decide which band to attach to using its own internal logic. That decision is not always optimal.

    In my case, the ThinkPad T480 consistently chose the 2.4 GHz network, even though a faster 5 GHz network was available. This is a common behavior because:

    • The 2.4 GHz signal often appears “stronger” or more stable at first scan
    • Linux Wi-Fi clients tend to be “sticky” and do not aggressively roam to better bands
    • The access point’s band steering (if present) is not strong enough to override the client decision

    Once connected to 2.4 GHz, performance was severely limited due to:

    • Heavy local congestion from neighboring networks
    • Narrow channel bandwidth
    • Legacy Wi-Fi rate fallback behavior

    This resulted in the Wi-Fi link negotiating a 6 Mbps receive rate, even though signal strength was excellent. That single factor explains the observed ~2–3 Mbps real-world throughput.


    The key insight

    The issue was not raw signal strength or ISP bandwidth. It was that:

    The device was correctly connected, but on the wrong frequency band.

    Because 2.4 GHz is shared, crowded, and prone to legacy rate fallback, even a “good signal” connection can perform extremely poorly.


    Why separating SSIDs works

    By splitting the network into:

    • MikroTik-2G
    • MikroTik-5G

    you remove ambiguity. The client is now forced to make an explicit choice rather than an automatic one.

    This has several effects:

    • The 5 GHz network becomes directly selectable and predictable
    • The client stops defaulting to 2.4 GHz “by accident”
    • Roaming behavior becomes deterministic instead of heuristic
    • The high-speed band is consistently used for throughput-heavy traffic

    Final outcome

    After separating the SSIDs and connecting directly to the 5 GHz network, performance immediately returned to expected levels, with significantly higher link rates and throughput aligned with the ISP connection.

    The fix confirmed that the issue was not hardware, drivers, or ISP limitations — but simply band selection behavior combined with shared SSIDs and suboptimal Wi-Fi steering.

  • Invalid file signature errors on HP G10 servers

    Invalid file signature errors on HP G10 servers

    When attempting to update individual components like the BIOS, you may receive the following error:

    The file signature is invalid. Make sure you are using a valid, signed flash file and try again.

    In my case the iLO 5 firmware was at version 1.46. You can’t easily jump from such an old version to the latest version. Old versions of iLO cannot verify the signatures of the newer BIOS/firmware packages. The solution is to simply stair step the iLO firmware to the latest release and then all the other packages should easily install.

    You also cannot jump from iLO version 1.46 all the way, to let’s say, version 3.18 at the time of this writing.

    I found the following upgrade path works.

    1.46 —> 2.14 —-> 2.35 —–>3.18

    You might also try the following but it fails for me sometimes depending on the server:

    1.46 —>2.35—->3.18 etc.

    Certain version of iLO introduced capabilities to handle larger file sizes. Perhaps some servers have smaller BIOS packages hence the success of this upgrade path for some and the failure for others.

    Once the iLO is fully updated it processes the BIOS upload correctly: