Greetings! This is my first post here. I have been a casual linux use for about 20 years, so I am familiar with the command line. Although I am certainly no expert. But I am new to OpenWrt. I have a Zyxel NBG6817. I have read the wiki for that unit and done a lot of research in the forum and elsewhere on the web. I understand that it has a dual boot feature and that the luci-app-advanced-reboot has been successfully implemented in the current stable release, which I have. So I will be able to boot to the alternate partition from OpenWrt. I understand that I can do the opposite by using the 3 successive boot attempts trick. It would be nice, since this is a dual booting machine, if I could maintain both the OEM firmware and the OpenWrt firmware in their respective partitions. That is my goal. But I am unclear about the upgrade procedures for dual booting machines. The way I understand it is to use the appropriate sysupgrade.bin file to upgrade the device.
But since this machine always flashes to the alternate partition, if I want to upgrade the OEM firmware, should I go to the OpenWrt partition and flash the OEM firmware from there so that it will flash to the OEM partition? Is that even possible, or does the OEM firmware need to be flashed from a currently running OEM partition that already has a previous version of the OEM firmware on it?
And when I upgrade the OpenWrt firmware, should I boot into the OEM partition and upgrade OpenWrt from there? And if I did that, would I still use the sysupgrade.bin, or should I use the new stable factory.bin, as if I were flashing a completely new install.
I know that a newer version of OpenWrt has not been released yet, but I'm just trying to plan ahead. Thanks in advance for any help understanding this.
What is the purpose behind this request?
Normally, on a router, one wouldn't want to dualboot between different firmwares, as keeping the configurations (unless they're kept extremely simple) similar enough not to disrupt normal operations is very difficult, if you toggle between them.
Is your intention to retain the OEM firmware because you're concerned that you may want return to it (e.g. for RMA purposes) or do you really want to be able to toggle between OEM firmware and OpenWrt on a more regular basis?
In the first case, don't worry, push-button tftp recovery will always work, both with the OEM firmware and the OpenWrt factory images.
In the second case, you obviously need this desired functionality. Personally I'd recommend against this, but it's a valid option, of course.
Contrary to the webinterface based luci-app-advanced-reboot, https://github.com/pkgadd/nbg6817/blob/master/nbg6817-dualboot is compatible with both OpenWrt and the OEM firmware, which can be used on the cli on either of them. An advanced feature of this shell script is --fake-rootfs, which allows fooling OpenWrt's sysupgrade tool to install on the active partition set, instead of the alternative one.
Warning: --fake-rootfs is tested to work on OpenWrt, I have not looked into the behaviour of the OEM upgrader (and very much doubt that it follows the same principle) for this particular feature. As the OEM upgrader does follow the same principle of always installing to the other partition set, you'll be faced with this issue with every OEM upgrade as well (and there has just been an OEM upgrade in April).
@slh thank you for your quick reply. Please don't misunderstand. This was not a request for the developers to implement something new. Rather it was just a request as to whether the feature was available.
Not sure, but I don't think RMA would be possible anyway once I installed OpenWrt, as it would probably void the warranty.
It's not that I "need" the feature, just that it would be nice to have. I'm just a home user. I'm 70 years old and I just like tinkering. I'm also security minded. Seems like new CVE's are being regularly being found. I know both OpenWrt and Zyxel are pretty good with fixing vulnerabilities pretty quickly. I just thought it would be nice to be able to switch back and forth in case a new vulnerability was found on one, I could switch to the other until it gets patched.
Yes, my setup is very simple. Just a few computers and phones on the same lan.
Thanks for calling my attention to that script. I see from your post in Dec.'17 that you wrote it. But I don't understand how to use it. Are you saying to run that script FIRST on the intended target of the upgrade to change the boot flag, and THEN do the upgrade on that same partition? I understand that script would be dangerous to try with the OEM partition, and I would certainly not try it. This was not a cheap unit and I don't want to mess it up.
You didn't directly answer my questions about upgrading either partition FROM the alternate partition or which file to use. Does that mean that you simply overlooked the questions, or that it definitely cannot be done currently, or that you just have not looked into that possibility, or whether there is a slim chance that it will be looked into by anyone in the near future because there has been no other interest in it, or all of the above.
Sorry if the questions sound silly, but please understand I am just a beginner. I know nothing about blocks and partitions and such. And if what am asking about not planned because it would be too difficult or even impossible, that's fine. Thanks again.
If you call nbg6817-dualboot --fakerootfs before sysupgrade, you'll use the currently booted partition set as install target, instead of the default of always using the alternate set. This part does work on OpenWrt (I've written the sysupgrade dual-boot integration for this device, so nbg6817-dualboot complements that functionality). I have not tested --fake-rootfs on the OEM firmware, so this particular parameter might not do the job for upgrading the OEM firmware in place (it won't break anything though!), all other features work on both firmwares, --toggle-rootfs in particular.
The normal parameters shown with --help are always safe to use anywhere, the advanced features shown with --full-help are meant for debugging purposes and do include features that require some deeper understanding to use.
In terms if security coverage, OpenWrt will always beat the OEM firmware, which has barely seen any security updates to kernel-, hostapd-, ppp or other sensitive components. Without looking any deeper, you'll have at least a dozen of security issues on the OEM firmware to choose from.
@slh, Okay, thank you. I think I understand a little better now. Just a couple more questions. I don't completely understand the difference between bootloader-rootfs and cmdline-rootfs. If I somehow made a mistake and made the router unreachable and was forced to use the TFTP recovery method, which partition would the firmware be written to in that case? Would it be the partition specified by cmdline-rootfs or bootloader-rootfs? Or would it be the last partition that was successfully booted to? Or what? And lastly, in that script you provided, the nbg6817-dualboot, you have one option marked as DANGEROUS.
--reset-rootfs DANGEROUS: rewrite the dualflag mtd completely and set
the desired rootfs
/dev/mmcblk0p5 or /dev/mmcblk0p8
Could you briefly explain why it would be dangerous and under what circumstances would the use of that option be advised or necessitated? And if you could point me to some documentation on this subject that I have been unable to find, that would be great. Thanks again for your help!
The script has been developed as counterpart for implementing dual-boot support for OpenWrt itself, as such it offers multiple debugging options for said dual-boot support and itself. None of the advanced options are really meant to be user visible (only the category for --fake-rootfs and --unfake-rootfs might be debatable).
There are multiple ways to determine from the running firmware which partition set is currently used, which is needed for the sysupgrade tool to choose the correct target:
- querying the bootloader provided cmdline (which is ignored by OpenWrt)
- querying the actual kernel cmdline
- parsing the dual-flag mtd partition
OpenWrt's sysupgrade, as I've implemented it for the nbg6817, opts to look only at the second option -that's what --fake-rootfs modifies to fool sysupgrade into choosing the 'wrong' partition set (as in the currently running one)-, but I still needed/ wanted to access to all options during development.
The bootloader's tftp recovery always writes to the first partition set.
No (and unless you've intenionally used --fake-rootfs, both should always gather the same result).
No.
The primary partition (set)
"header" partition is located at "/dev/mmcblk0p3"
"kernel" partition is located at "/dev/mmcblk0p4"
"rootfs" partition is located at "/dev/mmcblk0p5"
Never.
It rewrites (re-initializes) the complete mtd partition holding the dual-flag marker, not just the flag itself. As such, it does something the OEM firmware would never do and enters unspecified ground, this should never be necessary and is potentially dangerous[0].
There is no documentation, no vendor specification to follow (nor any source for the critical upgrade paths used for these features). I've written up my findings (based on blackbox reverse engineering of the behaviour exposed by the OEM firmware), as I deemed them to be useful, to https://github.com/pkgadd/nbg6817/ and https://openwrt.org/toh/zyxel/nbg6817, more detailed information can be gathered from reading https://github.com/pkgadd/nbg6817/blob/master/nbg6817-dualboot itself. Anything beyond that would have to be reverse engineered as needed. If you have anything to add, please edit the OpenWrt wiki as necessary - I'd also take changes to nbg6817-dualboot or further documentation/ information to it.
IMHO the best strategy to use this device (or others providing a similar dual-boot functionality, e.g. the Linksys ones) is to ignore the presence of the dual-boot feature alltogether. Just use the defaults and let sysupgrade use 'the-other' partition set, This default behaviour always leaves you with the known-working 'old' firmware version and its full configuration (at least for OpenWrt, the OEM firmware shares the configuration between both partition sets, on rootfs_data, which is ignored by OpenWrt) in place, at your finger tips in case of problems.
- you've encountered a problem or want to test for a potential regression - snap, you're back to the known-working old firmware.
- you want to try a new firmware version or snapshot, you can safely do so and return to your old/ stable after testing.
- in case you need to return to the OEM firmware, tftp is always available[1].
--
[0] I needed this functionality during the early development stages, an enduser should never need this.
[1] and yes, the tftp recovery also supports OpenWrt's factory firmware images.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.