Netgear R7500v2 (ipq806x) 18.06.1 experience and issues

For Developers
1

Build seems solid from what I can tell. Managed to migrate (from lede-17.01.4) mostly painlessly. Did run into two issues:

  1. Running the 18.06.1 sysupgrade in 17.01.4 led to a brick. A strange type of brick where the router was already waiting for a TFTP recovery without my intervention. Flashing the factory.img at this point worked fine. This was with and without "keep settings" checked. It was not even booting.

  2. mdadm does not work with raid1 correctly. To be fair, it didn't work at all in 17.01.4, but it does with a workaround on 18.06.1. But the default /etc/init.d/mdadm has it use the /etc/config/mdadm and all that jazz, but when it runs mdadm --assemble --scan, it segfaults. This can be reproduced on the command line. My workaround was to hard code my drive paths into the init.d and skip the scan process. It then works as expected. LVM is still broken (with raid1).

Otherwise, I have not ran into any issues yet. 5ghz seems stable so far, but its only been about 5 hours uptime. I remember falling back to 17.04.4 stable because snapshot had 5ghz instability.

2

This was to be expected (and covers all Netgear ipq806x devices):

Your mdadm/ lvm2 issues are probably a general issue and not device specific.

3

The devicepage for R7500 is rather basic and could need some helpful input in regards to installation procedure and caveats.

https://openwrt.org/toh/netgear/netgear_r7500

4

I saw the page, if the part about needing serial to TFTP is true for v1, I would suggest a separate page for v2, because its not as hard on v2.

The 7500 page says:
Don't attempt to flash unless you have a UART serial device. You will brick it and cry.

That is a bit intimidating, but not true on v2. The only part of v2 that will 'brick and make you cry' is if you access serial and run 'flash eraseall', since it also erases the bootloader.

For v2, one has to hold the factory reset button while turning on the device. The solid power led (orange at this point) will begin to flash (still orange) for about 3-4 seconds. If you hit the router via TFTP with a file during this point, it will accept it, flash, and reboot. Otherwise the light will turn white and try to boot the existing install. Also, I believe you have to keep the reset button held at least until the TFTP is accepted, so it is a little tricky especially if your PC and router are in separate rooms :slight_smile:

That said, the v2 does also have serial access and can be triggered the same way, but it is not required.

I am curious about the re-partitioning though. Is it revertible? Has going back to 17.x or stock after said MTD re-partitioning been tested? I mean, I personally wouldn't mind if I am 'stuck' with OpenWRT 18.x or later, but others may want to know :slight_smile:

5

I can only extrapolate from the feedback for the r7800 and hope that the firmware behaves similarly enough.

Yes, it's revertible - but you do need (push-button) tftp recovery whenever the partitioning changes (OEM and 17.01.x use 2 MB, 18.06.x and master use 4 MB), so:

  • OEM --> 18.06.x (or master)
  • 17.01.x --> 18.06.x (or master)
  • 18.06.x (or master) --> 17.01.x
  • 18.06.x (or master) --> OEM

See the r7800 exploration thread for details, there's also the potential to extend rootfs/ overlay from ~19 MB to ~96 MB like it has been done (also in a reversible manner, by the way of using push-button tftp recovery) for the r7800, but that really needs someone with that hardware to follow the same investigation and testing that has been done for the r7800.

6

Unfortunately I do not have a working LvTTL serial kit at the moment or I would test for you.

One thing to note, and this has been an issue even in all of the 17.x builds, regarding the MTD, is that dmesg will have this:

[19209.009796] print_req_error: 2 callbacks suppressed
[19209.009805] print_req_error: I/O error, dev mtdblock0, sector 0
[19209.014647] print_req_error: I/O error, dev mtdblock0, sector 8
[19209.019955] print_req_error: I/O error, dev mtdblock0, sector 16
[19209.026208] print_req_error: I/O error, dev mtdblock0, sector 24
[19209.032270] print_req_error: I/O error, dev mtdblock0, sector 0
[19209.037537] Buffer I/O error on dev mtdblock0, logical block 0, async page read
[19209.048891] print_req_error: I/O error, dev mtdblock0, sector 0
[19209.050474] Buffer I/O error on dev mtdblock0, logical block 0, async page read
[19209.057359] print_req_error: I/O error, dev mtdblock1, sector 0
[19209.064629] print_req_error: I/O error, dev mtdblock1, sector 8
[19209.070513] print_req_error: I/O error, dev mtdblock1, sector 16
[19209.076079] print_req_error: I/O error, dev mtdblock1, sector 24
[19209.082445] Buffer I/O error on dev mtdblock1, logical block 0, async page read
[19209.091112] Buffer I/O error on dev mtdblock1, logical block 0, async page read

It never causes any problems, but yeah, its in dmesg. I only bring this up in case it has any effect on the ubi expansion, but I will read through the r7800 thread and see what has been discussed and discovered.

Edit 3:
The description for TFTP reset button access given for the R7800 is probably more accurate than mine, thus it seems the R7500v2 and R7800 also have that in common.

7

I've used mdadm fine on my WRT3200ACM (in a slightly roundabout way) but that was on master so it's probably a release branch issue.
https://forum.synology.com/enu/viewtopic.php?f=160&t=141217

8

The TFTP recovery flash mode is pretty common for many Netgear routers. So, likely you do not need any serial adapter, but you just need to trigger the TFTP mode during early boot.

Those dmesg mtd log lines are rather normal, also in R7800. I have never bothered to look into the origins of those, as everything seems to work.

10

Is it possiable use ssh commend to flash it from 17.01.x -to 18.06.x,excpet tftp or serial
if so I can flash it for my friend by remote desktop
thanks

11

No, 19.07.x (and later) contains https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=c3af761e4740820a29e993414d3d2f49c7eff6e7 and https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=57b1e951b52010e42c64ee617e0b5b9d547d3a0d relative to 17.01.x, the former moves the start position of the ubi volume, the later its total size (and the end position). Doing these changes requires flashing via tftp, as this is the only procedure that allows repartitioning of the NAND flash.

Edit: the good news, push-button tftp recovery on these devices is almost fool proof, either it flashes the new factory firmware - or it doesn't (the tftp window is short, it's easy to miss it and might require several attempts - an unmanaged switch between router and the computer running the tftp client can help) with no harm done.

12

ok,I got it
thanks for your answer

13

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