Advice needed on upgrading R7800 to 18.06

I've got a Netgear Nighthawk X4S R7800 router currently running firmware version: LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-17.290.79498-d3f0685)

I'd like to upgrade to the latest version. I found this R7800 webpage:

And from reading it, I think what I want is this file:

The R7800 page doesn't include any upgrade instructions, so I assume the process must be so obvious I don't need instructions? :slight_smile: I'm guessing I'm supposed to go to the System -> Flash Operations page, upload the above file, check "Keep settings" and click "Flash Image"

Is that the correct procedure for upgrading this model or is there anything else I need to do?

Don't save settings, it'll most likely (soft)brick your router. You probably want to go for the master branch either using snapshots or these community builds.

Normally, your information would be correct and you'd take the sysupgrade image for upgrading.

In this particular case, you need to go the tftp route (see debricking info), as the NAND partitioning had to be changed between 17.01 (or OEM) and 18.06.x onwards - this can only be rectified using tftp (in both directions). The update from 18.06.x to 19.03.0 will be possible using sysupgrade (as the partitioning stays the same and hopefully won't change again).

1 Like

Wow, the TFTP stuff sounds complicated. Would it be easier to go back to the Netgear factory firmware and then install OpenWrt 18.06 from the netgear factory GUI or would that solve the problem? I originally installed the LEDE 17.x version I'm running now from the netgear factory firmware GUI so maybe it works with Opewrt 18.06 version too? Or will the Openwrt 19.03 update you mentioned solve this upgrade problem? I suppose I could just wait for it and upgrade from 17.x -> 19.x?

No, the tftp procedure is unavoidable for upgrading to >= 18.06.0 (so also including 19.03.0) - regardless if you come from OEM or 17.01.x. It would also be required for downgrading from 18.06.x (or 19.03.x) to 17.01.x or OEM.

Whenever the partitioning changes (and it did once, between (17.01.x or OEM) and 18.06.0), tftp is the only option.

It took a while and was a bit of pain but TFTP worked. I wrote down all my settings and reconfigured manually after the update. Everything seems to be working though. Thanks for the help! :slight_smile:

Wait a minute, this is news to me (which I fully admit, I haven't really been keeping up with OpenWrt developments until just recently). Is this something that is specific to the R7800? I'm asking out of curiosity because I own a Netgear R8000, and I have not needed to use tftp to upgrade the the firmware on it. In fact, I upgraded from LEDE 17.01.6 to OpenWrt 18.06.2 just last week, and I used the GUI method, which seems to have worked without any issues.

It is specific to NAND based (SPI-NOR can often be repartitioned on the fly, as has been demonstrated for the TP-Link Archer C2600 and TP-Link Archer VR2600v) ipq806x devices which shipped with a 2 MB kernel partition (kernel size is around 2.4 MB by now, in other words >>2 MB) in the OEM firmware (and which were kept at that for 17.01.x) - this affects:

  • Netgear Nighthawk X4 d7800
  • Netgear Nighthawk X4 r7500
  • Netgear Nighthawk X4 r7500v2
  • Netgear Nighthawk X4S r7800

The r8000 is not ipq806x based, but uses a Broadcom design based on BCM53xx/ BCM4709 and seems to derive its partition map using bcm947xx-cfe-partitions instead. While I have no idea how it's partitioning is actually set up behind the scenes or how much margin there is for future kernel growths, it's not affected by the changes discussed here (which were necessary for getting compatibility of the affected devices with 18.06.x and kernel >>4.9).

EDIT: the r8000's device page is extremely brief, questions about it (like this one) would be much easier to answer if it were populated with the usual information (dmesg in particular).


I see, that makes sense. I knew that R7800 and the R8000 used different chipsets, but since I hadn't heard anything about this up to now, I was surprised to hear of such an issue "suddenly" appearing. Obviously this is old news to lots of folks, I just haven't been keeping up with what's been going on.

Glad to hear that this is something that seems to be applicable only to certain specific hardware, and not something more widespread.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.