New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#1724 - 18.06.0 release not working on ZyXEL NBG6616 (ar71xx) #6950
Comments
malaakso: Here's the bootlog:
Looks like [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0cd5e85e7ad621223b0787e66d8ad20fb2694135|this commit]] is at fault (removing NBG6616 support by accident from generic config). |
Giuseppe: Yes, agreed. |
psyborg: [ 0.000000] TL-WR703N TP-LINK TL-WR703N v1 dont this list miss TL-MR11U, TL-MR12U, TL-MR13U if already not TL-MR22U? |
goyoghurt: Have any one tried to compile 18.06 by yourself and see if it works? By manually enable NBG6616 target. |
Giuseppe: I never tried to compile, just reading the logs I think NBG6616 is just not enabled, but surely may take ages to confirm it by myself, can somebody make this test, so to require a minor release of openwrt 18.06? |
goyoghurt: I have got it working by recompiling the latest snapshot (With NBG6616 as target profile) and adding the line "CONFIG_ATH79_MACH_NBG6616=y" to the file openwrt/target/linux/ar71xx/generic/config-default Everything seems to work except i had to attach ac wifi interface to the Switch VLAN manually. |
Giuseppe: What is the procedure to have a new release of the firmware? |
MauritsVB: I too fell victim to this bug when using sysupgrade to upgrade from 17.01.5 to 18.06.1 using the web interface (with keep settings). It got stuck in a boot loop so something went seriously wrong. The first [[https://forum.archive.openwrt.org/viewtopic.php?id=54020&p=3|report I can find of something going wrong]] is from March 2018 where someone reports that updating with the LEDE snapshot of //Sun Mar 18 06:29:09 2018, sha256sum becb106db9b14390585901cc5ac084a36f5b9a5cc5d9abc9701b489e497f9854// results in a boot loop. After the release of 18.06 someone reports in [[https://openwrt.org/toh/zyxel/nbg6616|the Device Page]] that 18.06 results in a boot loop. I have now changed the warning on the device page to alert people not to install 18.06 or 18.06.1 and I have set 17.01.5 as the most recent compatible version. The device crashes before it can enter the TFTP stage so the only way to recover is using a TTL serial cable. If you need to know how I managed to fix it, please come to [[https://forum.openwrt.org/t/zyxel-nbg6616-boot-loop-after-sysupgrade-from-17-01-5-to-18-06-1/19469|this topic in the forum]]. My boot log is the same as posted earlier, with the crucial line "MIPS: no machine found for id 'NBG6616', supported machines:" so it looks indeed like the commit mentioned earlier could be the root cause. |
MauritsVB: @guiseppe The first thing that should happen is that someone checks which other devices were erroneously removed in that commit and creates a patch to restore those devices. That patch then needs to be offered as a Pull Request (and referencing this bug ID). If it gets accepted, any build after it will contain the fix. I took the liberty of emailing the guy behind the original commit to see if he could be of any help. |
MauritsVB: I have had another look and I am not sure anymore that the commit that was mentioned earlier is actually the root cause. That commit removes the NBG6716 but not the NBG6616. If I look at [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=history;f=target/linux/ar71xx/generic/config-default;hb=0cd5e85e7ad621223b0787e66d8ad20fb2694135|the history of that file]] it has never contained a direct reference to the NBG6616 I might be missing something here (some of this is new territory for me) but if this file previously did not reference the NBG6616 how could it have worked under LEDE 17? Has the device always been referred to in a more generic sense instead of naming it explicitly? Has the build system changed dramatically since LEDE 17 so it now requires a specific reference when it didn't do in the past? Also, since the problem is now confirmed (even if the cause is unclear) how can we get this bug to go from 'unconfirmed' to 'new'? Who controls that? |
MauritsVB: Thanks to Matthias Schiffers' [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a4f4ddba61e61d3f15d19c4e57733a9e44ec8d09|commit a4f4ddb]] and after a couple of hours testing I can confirm that the issue is resolved. I have upgraded from 17.05.1 to [[https://downloads.openwrt.org/snapshots/targets/ar71xx/generic/|snapshot]] using a 'Sysupgrade' via the web interface and I have reflashed with a snapshot 'Factory' image using the recovery method from a TFTP server. In both tests the upgrade procedure went without any issues, and the device boots and runs like it should, using the most recent OpenWRT 18 snapshot. Unless the fix is backed out (not very likely) the next OpenWRT service release 18.06.2 will contain the fix. |
MauritsVB: This is now confirmed fixed in 18.06.2. |
Giuseppe:
After flashing the firmware the device is not booting as it should.
The text was updated successfully, but these errors were encountered: