I'm using the master branch, and have built the software a few times and installed it. It's currently running OpenWRT.
I noticed that recent attempts to install a new sysupgrade are not booting, it is still using the old version (I am using the kernel version, 4.19.66 for the old version, and the new version is 4.19.69, as a flag to indicated which build it's running).
Is there any way to see why the new image is not booting, short of setting up a serial terminal? Also, I think the image name changed around this time, is it possible that this is causing a problem (like the boot block does not like something about the new name)? The commit in questions is:
Date: Wed Aug 21 14:59:24 2019 -1000
Not saying this is an issue, just noting that this is a ipq4018 specific change.
Another one is
Date: Fri Aug 23 19:38:29 2019 +0200
The image names should be identical, but the download paths might have changed with the generic subtarget being introduced for ipq40xx as well.
Also, please remove those e-mail addresses, you don't want those people getting spam. Very unpolite to leave them in your copy/paste. They don't contribute anything.
Good point, e-mail addresses removed.
I think the image names are slightly different, but that should not matter. I also tried to build a 19.04 snapshot and the same thing is happening.
I can see via 'Advanced Reboot' in LUCI, that the kernel version is getting updated for one of the partitions as I expect, but that partition is never booted, I keep going back to the same partition that I started with. I was able to do sysupgrades until the 24th and then lost that ability, apparently (the kernel messages have a date of the 24th, which I assume is the build time of the kernel, until it gets a date from the internet).
I will give my own spare EA6350 v3 a shot this weekend (it's running 19.07 builds though, not master). Could you try a 19.07 snapshot to see of that works?
Apparently sysupgrade has seen some changes which effectively mute any useful output that one would have seen on older versions, but I have no link to that discussion unfortunately.
Yeah, I can install the snapshot, but it doesn't boot to it. It appears to spit out the right stuff before rebooting. I seem to be stuck with a particular version of 'master' with no way to get off of it. Is there some way to manually change the partition? Right now I think it's stuck with the alternate partition, and uploads are going to the primary each time.
That is a side effect of detached sysupgrades, which pivot_root into a initramfs like environment before starting the sysupgrade - a side effect sadly is that all running ssh sessions are torn down by this. The full output of the sysupgrade only remains visible via serial console.
The "advanced reboot" LuCI package will let you control the next-boot partition. You can also do it manually with
fw_setenv boot_part 1
You can mount and examine the other partition as described in Script: Mount "Alternate" NAND Firmware (Linksys +?)
Have you ever had OpenWrt installed on the "other" partition? There might be some subtle issues with how the OEM firmware has set up the UBI volumes.
There doesn't appear to be a 'fw_setenv' installed, which would definitely screw things up...
Yes, that it would!
If missing, that would explain a lot, since
case "$cur_boot_part" in
fw_setenv -s - <<-EOF
fw_setenv -s - <<-EOF
The executables and supporting data are available in
I was able to install the 'uboot-envtools' package and get it working again. Not sure how it got deselected in the first place...
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.