Modify

Opened 5 years ago

Last modified 15 months ago

#8960 assigned defect

sysupgrade with copying old config files fails on wrt160nl

Reported by: WTGPhoben Owned by: juhosg
Priority: response-needed Milestone: Chaos Calmer 15.05
Component: base system Version: Backfire 10.03.1 RC4
Keywords: Cc:

Description

Running sysupgrade on linksys wrt160nl and copying old config files (either the automatic way or with -f and a tarball), breaks the CRC and router will not boot after reflashing.

According to the forum thread where this first came out (https://forum.openwrt.org/viewtopic.php?id=27189), sysupgrade broke starting with a change to /package/mtd/src in r22881

The issue can be worked around by adding the following to /lib/upgrade/common.sh (and rebooting?) before running sysupgrade

Index: package/base-files/files/lib/upgrade/common.sh
===================================================================
--- package/base-files/files/lib/upgrade/common.sh    (revision 23944)
+++ package/base-files/files/lib/upgrade/common.sh    (working copy)
@@ -174,6 +174,10 @@
             jffs2_copy_config
         fi
     }
+
+    echo "fixing TRX"
+    mtd fixtrx -o 32 firmware
+
     v "Upgrade completed"
     [ -n "$DELAY" ] && sleep "$DELAY"
     ask_bool 1 "Reboot" && {

This works for now, there's probably a better fix to be had in mtd...

Attachments (2)

terminal_capture.txt (3.7 KB) - added by anonymous 3 years ago.
Capture of serial console doing failed sysupgrade
01-ar71xx-wrt160nl-qd-sysupgrade-patch.patch (3.0 KB) - added by chunkeey@… 3 years ago.
Test Patch based on WD Range Extender which has similar issues

Download all attachments as: .zip

Change History (37)

comment:1 Changed 5 years ago by nexus@…

I'm not sure about r22881 which I wrote in forum. Reverting changes of this solved problems on wrt160nl with 1.1.5 u-boot. It does not work on wrt160nl with u-boot 1.1.6.

This patch worked for me on both u-boot versions

comment:2 Changed 5 years ago by jow

  • Priority changed from high to response-needed

Is this still the case with RC5 ?

comment:3 Changed 5 years ago by nbd

  • Resolution set to no_response
  • Status changed from new to closed

comment:4 Changed 5 years ago by anonymous

  • Resolution no_response deleted
  • Status changed from closed to reopened

This still happens on r28310. All forms of upgrade (sysupgrade with or without keeping changes and even uboot tftp) have the same outcome: The router boots fine the first time but the second time hangs on uboot because of the TRX CRC32 check failing. The workaround is to update without keeping changes or directly via tftp and then manually run on the first boot:

mtd fixtrx -o 32 firmware

before rebooting

comment:5 Changed 4 years ago by nbd

please try a more recent version and see if the issue is still there.

comment:6 Changed 4 years ago by nbd

  • Resolution set to no_response
  • Status changed from reopened to closed

comment:7 Changed 4 years ago by jbj1@…

  • Resolution no_response deleted
  • Status changed from closed to reopened

Tried out 'sysupgrade XXX.bin' with 10.03.2-rc1_r30740 and also ATTITUDE ADJUSTMENT (bleeding edge, r30919) from snapshots. upgrade still fails, uboot fails:

U-Boot 1.1.6 (May 12 2009 - 07:52:28)

AP81 (ar7100) U-boot
sri
32 MB
WRT160NL u-boot version: 1.0.0
Top of RAM usable for U-Boot at: 82000000
Reserving 279k for U-Boot at: 81fb8000
Reserving 192k for malloc() at: 81f88000
Reserving 44 Bytes for Board Info at: 81f87fd4
Reserving 36 Bytes for Global Data at: 81f87fb0
Reserving 128k for boot params() at: 81f67fb0
Stack Pointer at: 81f67f98
Now running in RAM - U-Boot at: 81fb8000
id read 0x100000ff
flash size 8MB, sector count = 128
Flash: 8 MB
* Warning - bad CRC, using default environment

comment:8 Changed 4 years ago by nbd

please try r32866

comment:9 follow-up: Changed 4 years ago by jbj1@…

Ok, I'm ready to try it out but have a question: how do I determine what svn revision goes into a snapshot build? (I'm not presently set up to do a build myself so I'd prefer to wait until there's one I can download).

comment:10 in reply to: ↑ 9 Changed 4 years ago by jogo

Replying to jbj1@…:

Ok, I'm ready to try it out but have a question: how do I determine what svn revision goes into a snapshot build? (I'm not presently set up to do a build myself so I'd prefer to wait until there's one I can download).

The base-files package includes the revision as the version, so just look at the file name in packages/.

comment:11 follow-up: Changed 4 years ago by jbj1@…

No dice :-( grabbed r32895 from snapshots and tried it. I first installed that -factory image from tftp. Then I logged, changed some config, updated /etc/sysupgrade.conf and ran sysupgrade from the serial console. Here's what I saw:

root@OpenWrt:/tmp# sysupgrade -v openwrt-ar71xx-generic-wrt160nl-squashfs-sysupg
rade.bin
Saving config files...
etc/sysupgrade.conf
etc/sysctl.conf
etc/shells
etc/shadow
etc/rc.local
etc/profile
etc/passwd
etc/inittab
etc/hosts
etc/group
etc/firewall.user
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/dropbear_dss_host_key
etc/dropbear/authorized_keys
etc/config/wireless
etc/config/uhttpd
etc/config/ucitrack
etc/config/ubootenv
etc/config/system
etc/config/network
etc/config/luci
etc/config/firewall
etc/config/dropbear
etc/config/dhcp
Sending TERM to remaining processes ... ntpd uhttpd dnsmasq syslogd klogd hotpl
Sending KILL to remaining processes ... uhttpd
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header

Upgrade completed
Rebooting system...
[ 2620.290000] Restarting system.

U-Boot 1.1.6 (May 12 2009 - 07:52:28)

DRAM: ar7100_ddr_initial_config(237) enter!
ar7100_ddr_initial_config(269) exit!

U-Boot 1.1.6 (May 12 2009 - 07:52:28)

AP81 (ar7100) U-boot
sri
32 MB
WRT160NL u-boot version: 1.0.0
Top of RAM usable for U-Boot at: 82000000
Reserving 279k for U-Boot at: 81fb8000
Reserving 192k for malloc() at: 81f88000
Reserving 44 Bytes for Board Info at: 81f87fd4
Reserving 36 Bytes for Global Data at: 81f87fb0
Reserving 128k for boot params() at: 81f67fb0
Stack Pointer at: 81f67f98
Now running in RAM - U-Boot at: 81fb8000
id read 0x100000ff
flash size 8MB, sector count = 128
Flash: 8 MB
* Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: ag7100_enet_initialize...
ag7100 get ethaddr for device eth0
Fetching MAC Address from 0x81feb1e0

--------* Get the RTL8306SD Manufactory ID=379c *-------
Reg6: speed=0 nway=1 duplex=0
Reg5: speed=0 nway=0 duplex=0
Reg1: a1=7fd9 a2=30e0 a3=15ac a4=30e0 a5=0
Reg1: a1=7fd9 a2=30e0 a3=15ac a4=30e0
Reg1: a1=7fd9 a2=30e0 a3=15ac a4=30e0
Reg1: a1=7fd9 a2=30e0 a3=15ac a4=30e0
Reg1: a1=7fd9 a2=30e0 a3=15ac a4=30e0

eth0: 68:7f:74:9f:64:b4
eth0 up
eth0
### main_loop entered: bootdelay=1

Hit any key to stop autoboot: 0
## Booting WRT160NL ...
Application code length 0x002e0000
Bad CRC: trx.crc32 0x0016f4e3 calculate 0x42821861

check link duplex:Full/speed:100

dup 1 speed 100
Tftpd start listening on port[69]!
Load address: 0x80060000
checksum bad
checksum bad
checksum bad

comment:12 Changed 4 years ago by nebulous@…

Starting from 10.03 RC6 I can confirm that the following placed my 160nl in an unusable state. (I have a ca42 but haven't hooked it up yet to verify the console output) Attempting to upgrade to trunk buildbot image from 2012-08-12

cd /tmp
wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-wrt160nl-squashfs-sysupgrade.bin
sysupgrade -v openwrt-ar71xx-generic-wrt160nl-squashfs-sysupgrade.bin

in my case the sysupgrade process reached approximately(from memory) this point

Writing from <stdin> to firmware ...

before signing off without coming back.

Hopefully this post isn't tangential to this bug, but it appeared to match.

comment:13 in reply to: ↑ 11 Changed 4 years ago by nlh

Replying to jbj1@…:
I believe the source of the problem is that the TRX header is offset by 32 bytes for this device, which is not accounted for by "trx_fixup" in package/mtd/src/trx.c. An offset can be specified on the mtd command line and could be passed into "trx_fixup"; or maybe it would be better to search for the TRX header (perhaps at known offsets) to compute the offset instead.

comment:14 Changed 4 years ago by anonymous

Problem still exists in trunk.
Workaround with editing /lib/upgrade/common.sh solves problem.
Is there any possibility for fix in official sources?

comment:15 follow-up: Changed 4 years ago by anonymous

Hello, jbj1 at ultraemail dot net here. As Anonymous above noted, I verified with 12.09-rc1 just now that 1) sysupgrade -c still fails due to the same TRX header problem and 2) that there's a workaround. Specifically, I just did a sysupgrade -c -d 60 /tmp/...bin and then in the pause I just hit ctrl-c and then manually ran:

mtd fixtrx -o 32 firmware

Then manually ran

reboot -f
sleep 5
echo b 2>/dev/null >/proc/sysrq-trigger

as appears in /lib/upgrade/common.sh

This works perfectly. When I run it I see:

root@OpenWrt:/# mtd fixtrx -o 32 firmware
Trying to fix trx header in firmware at 0x20...
New crc32: 0x50f116ea, rewriting block
Done.

So is there a way we could get a hook to do this automatically, at least on this platform?

comment:16 Changed 4 years ago by jow

  • Owner changed from developers to juhosg
  • Status changed from reopened to assigned

comment:17 Changed 3 years ago by jbj1@…

Just tested this with 12.09 release on the off chance this was fixed. It wasn't. Is this one a difficult one to fix? I'm not set up to build a while image, but if someone else is I'd be happy to test with the fix indicated above.

Changed 3 years ago by anonymous

Capture of serial console doing failed sysupgrade

Changed 3 years ago by chunkeey@…

Test Patch based on WD Range Extender which has similar issues

comment:18 Changed 3 years ago by chunkeey@…

Hello,

I don't have a WRT160NL. However the WD Range Extender has the same issue.
That's why I've attached a test patch (based on the WD patch).

It would be great if someone can test it and report back, so we can make a proper patch ;-).

comment:19 in reply to: ↑ 15 Changed 2 years ago by nebulous

Replying to anonymous:

Hello, jbj1 at ultraemail dot net here. As Anonymous above noted, I verified with 12.09-rc1 just now that 1) sysupgrade -c still fails due to the same TRX header problem and 2) that there's a workaround. Specifically, I just did a sysupgrade -c -d 60 /tmp/...bin and then in the pause I just hit ctrl-c and then manually ran:

mtd fixtrx -o 32 firmware

Then manually ran

reboot -f
sleep 5
echo b 2>/dev/null >/proc/sysrq-trigger

as appears in /lib/upgrade/common.sh

This works perfectly. When I run it I see:

root@OpenWrt:/# mtd fixtrx -o 32 firmware
Trying to fix trx header in firmware at 0x20...
New crc32: 0x50f116ea, rewriting block
Done.

I can confirm jbj1's above workaround worked for me as well.

comment:20 follow-up: Changed 2 years ago by chunkeey

Actually, this should was fixed some time ago by:
https://dev.openwrt.org/changeset/38964

All subsequent upgrades should be "painless" :-D.
That said the upgrade to the fixed openwrt can be
a bit of a pain since you'll have to brick your
router once more (or apply the fixtrx manually
one last time).

comment:21 in reply to: ↑ 20 ; follow-up: Changed 2 years ago by nebulous

Replying to chunkeey:

Actually, this should was fixed some time ago by:
https://dev.openwrt.org/changeset/38964

All subsequent upgrades should be "painless" :-D.

Could you clarify this a bit more for the Googlers?
I updated via tftp to trunk then tried sysupgrade to test, which resulted in a "TRX error" and rebricking.

comment:22 in reply to: ↑ 21 Changed 2 years ago by chunkeey

Replying to nebulous:

Replying to chunkeey:

Actually, this should was fixed some time ago by:
https://dev.openwrt.org/changeset/38964

All subsequent upgrades should be "painless" :-D.

Could you clarify this a bit more for the Googlers?
I updated via tftp to trunk then tried sysupgrade to test,
which resulted in a "TRX error" and rebricking.

No I can't clarify it (in any more detail). Because the same
procedure you described "should" actually work in trunk.

What I can tell you is: it worked for my device "western-digital
range extender". But I can't tell you what's going on with yours?
Maybe some debug info (e.g.: cat /proc/cpuinfo, cmdline, ...) could
help to identify the culprit.

comment:23 Changed 2 years ago by stefan@…

I do not understand how changeset 38964 would fix the problem with sysupgrade not being able to save config files over firmware installation by changing the image generation process.

However, I have added the mtd fixtrx command to the platform-specific selection for upgrades and now it works for me. Maybe it would be better to fix it in mtd directly, but I had no success in trying to do so and I was in urgent need to solve this issue, which still exists in 12.09 AA. This is the patch to target/linux/ar71xx/base-files/lib/upgrade/platform.sh:

--- target/linux/ar71xx/base-files/lib/upgrade/platform.sh	2014-03-21 11:32:00.000000000 +0100
+++ platform.sh	2014-03-27 02:48:33.000000000 +0100
@@ -276,6 +276,12 @@
 	om2p-lc)
 		platform_do_upgrade_openmesh "$ARGV"
 		;;
+	wrt160nl)  
+		default_do_upgrade "$ARGV"
+
+		v "Fix TRX checksum"      
+		mtd fixtrx -o 32 firmware  
+		;;                            
 	*)
 		default_do_upgrade "$ARGV"
 		;;

Now it reboots successfully even after config changes:

Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...     
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header
    
Fix TRX checksum
Trying to fix trx header in firmware at 0x20...
New crc32: 0x1dfbeed7, rewriting block
Done.
Upgrade completed
Rebooting system...
[  159.340000] Restarting system.

U-Boot 1.1.6 (Apr 14 2010 - 14:02:36)

DRAM:  ar7100_ddr_initial_config(237) enter!
ar7100_ddr_initial_config(269) exit!

U-Boot 1.1.6 (Apr 14 2010 - 14:02:36)

[...]

Hit any key to stop autoboot:  0 
## Booting WRT160NL ...
Application code length 0x0000ffe0
CRC OK
## Booting image at bf04003c ...
   Image Name:   MIPS OpenWrt Linux-3.3.8

BTW: it is not clear to me what the mtd fixtrx command in the file uci-defaults/wrt160nl is all about: it fixes the checksum on first boot, but since the CRC check is in U-Boot it doesn't help at all to fix the CRC after the first boot (which will not happen if the CRC is wrong).

comment:24 Changed 2 years ago by anonymous

I just tried r40017 on my wrt160nl and it actually worked!!! Weird because I did see these messages:

Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header

Upgrade completed
Rebooting system...

Nevertheless, it did actually work. Just to be explicit, what I did was first sysupgrade to this snapshot with "-n" to not save config. Then logged in, again copied over the same r40017 and this time ran with just -v. Following that I was able to log in. So perhaps we can finally put this bug to rest?

comment:25 Changed 2 years ago by chunkeey

@anonymous: hopefully :D

But first, I have something to take care of (stefan's question):

"I do not understand how changeset 38964 would fix the problem with sysupgrade not being able to save config files over firmware installation by changing the image generation process."

The TRX Header

The idea of the trx header is to protect the firmware on the device against modifications (accidents, malicious attacks or cosmic rays, take your pick). To enable such checks, the trx headers consists of an HDR0-magic, an crc32 checksum and the length (of the code/area/data which is covered by the crc32) and a few more, less important bits.

The HDR0/trx header is checked by the bootloader (uboot) everytime the system (re-)boots. If the bootloader could verify the checksum it boots it. If the checksum doesn't match it starts the tftp server and waits for a new firmware to be uploaded via the net (at least that what my Western Digital Range Extender does).

Problem

As you might know openwrt images for your router consist of: a header (pattern, trx) the kernel-loader,kernel and the filesystem(s). However, let's take a closer look at the filesystem part. Because the configs, libs and programs are stored there (and they are updated - especially the configs on the first boot). So for every small change the checksum in the trx header would have to be updated too. (Otherwise, the crc32 checksum check would fail and the uboot would refuse to boot). Updating the crc32 everytime something has changed is certainly not an option (especially with flash because every write deteriorate the block).

factory image

Hence for factory-images the trx header is "fixed" on the first boot. mtd fixtrx does this by trimming the length in the trx header field down to just one block (4k-64k, depends on the flash type) and updating the checksum accordingly. Thanks to this, uboot will only check the pattern, trx headers and a small part of the kernel. The filesystem however is no longer in the crc32 protected area, so it can be modified without "bricking" the device.

sysupgrade image

In case of sysupgrade (which is run when openwrt is already on the router), juhosg had the great idea to modify the image creation so that the extra "mtd fixtrx" is no longer necessary. This is done pretty much in the same way: the filesystem is longer part of the crc32 protected area. Only the pattern, trx header and the kernel is. Hence, the new root filesystem and the extra tar (which contains the saved configs) are ignored by the pesky uboot crc32 check.

Note:

In case someone is wondering why for the factory image, the trx crc32 and length has to include the complete image (pattern, trx, kernel and root filesystem) and not just the pattern, trx header and kernel (like for sysupgrade): That's because the uboot tftp and the vendor's web flash utility (when flashing openwrt for the first time) are using the crc32 and length in the trx header. If the trx header length doesn't include the filesystem, the filesystem will not be flashed. (And of course: if the crc32 doesn't match the image isn't flashed at all.)

(Yeesh, think about all the time I could have done something productive. :-D.)

comment:26 Changed 2 years ago by anonymous

Hello chunkeey,

thank you very much for the explanation, but I already digged deep into this stuff of this now 3-year old issue, especially because anonymous and jbj1 found the source of the bug and nlh even suggested to fix it in package /mtd/src/trx.c, where it belongs to (what I tried also, but with no success - I do not know this mtd stuff too well).

Of course, changeset 38964 is an important patch to the build process - thank you for that, really helpful! -, but it is just not related to the sysupgrade drama documented in this ticket. However, if it is considered o.k. to work around in the image builder and in sysupgrade rather than fixing it at the mtd package, I am glad to have learned at least this from changeset 38964 :-) and I am happy to provide such an easy patch to platform.sh.

So thank you all, guys, and hopefully this ticket can be closed after incorporating the patch in either platform.sh (or mtd if someone of the dev team cares ;-) ).

comment:27 Changed 2 years ago by jow

  • Milestone changed from Backfire 10.03.2 to Chaos Calmer (trunk)

Milestone Backfire 10.03.2 deleted

comment:28 follow-up: Changed 15 months ago by sobkas@…

So will this bug will be ever fixed?

comment:29 in reply to: ↑ 28 Changed 15 months ago by chunkeey@…

Replying to sobkas@…:

So will this bug will be ever fixed?

Actually, this is fixed by:
https://dev.openwrt.org/changeset/38964

All subsequent sysupgrades should run smooth
without any issues. That said the upgrade to
the fixed openwrt can be a bit of a pain as
you'll have to brick your router once more
(or apply the fixtrx manually one last time).

comment:30 follow-up: Changed 15 months ago by anonymous

I'm sorry, but I don't understand this ("Problem"):

Updating the crc32 everytime something has changed is certainly not an option

I never had to update the crc32 everytime something had changed. However, I had to update it manually everytime I wanted to save the current config over a sysupgrade (and only then). Since on updates the flash is re-programmed anyway, how would this deteriorate the flash to also update the crc32 at this occasion?

Still, my own builds will brick my router when flashing OpenWRT on a router with the manufacturer's firmware, but not so when first flashing a standard OpenWRT image and then my own build. I'm using the AA branch rev. 45686, not trunk.

comment:31 in reply to: ↑ 30 ; follow-up: Changed 15 months ago by chunkeey@…

Replying to anonymous:

I'm sorry, but I don't understand this ("Problem"):

Thanks to WD, you can get the source for the modified
bootloader, build-system (image creation), ... for the
MyNet. This is important because it utilizes the same
trx protection as the wrt160nl. So, if you have a ("Problem")
you can see why in the source and don't need to ("Ask"),
("Wonder") or reopen the ticket.

the source is linked in the wiki: http://wiki.openwrt.org/toh/wd/rext

Updating the crc32 everytime something has changed is certainly not an option

I never had to update the crc32 everytime something had changed. However, I had to update it manually everytime I wanted to save the current config over a sysupgrade (and only then). Since on updates the flash is re-programmed anyway, how would this deteriorate the flash to also update the crc32 at this occasion?

See the patch about that:
In the current sysupgrade images, the CRC32 value of
the TRX header covers the whole rootfs data. Due to
this, the CRC value should be changed during sysupgrade
otherwise the bootloader refuses to load the image on
the next boot.

Think about that. For the squashfs image, the rootfs
is read-only anyway so this never applied for this case.
But for the jffs2 image it did. And this is why openwrt
firstboot startup script had to change the trx header.
This is done by the fixtrx code in mtd. You can see that
the tool shrinks the length of the trx protected are to
just that of a erase block and not any parts of the
rootfs.

The original firmware (from linksys/cisco/wd) save
configuration/volatile data into the nvram partition.

Still, my own builds will brick my router when flashing OpenWRT on a router with the manufacturer's firmware, but not so when first flashing a standard OpenWRT image and then my own build. I'm using the AA branch rev. 45686, not trunk.

True, the patch is not in the AA Branch. https://dev.openwrt.org/log/branches/attitude_adjustment

But BB (Barrier Breaker) and all later releases should have it.

comment:32 in reply to: ↑ 31 Changed 15 months ago by anonymous

Replying to chunkeey@…:

Sorry, I was not aware that my comment re-opened the ticket. Under Modify Ticket there is pre-selected "leave as assigned", nothing more that I could set here, so this was not intentional.

True, the patch is not in the AA Branch. https://dev.openwrt.org/log/branches/attitude_adjustment

But BB (Barrier Breaker) and all later releases should have it.

Thanks, that is the important hint. For some reasons I'm stuck at the time with AA. I will try to add the patch manually there.

comment:33 follow-up: Changed 15 months ago by anonymous

I have just applied patch r38964 to the image builder Makefile of my source copy of AA 12.09.1 (r42647). Sadly, the patch does not work for me. This is what I have done:

Installed Linksys firmware version 1.0.03 using tftp (same version as delivered when router was bought). Flashed the factory image using the Linksys web interface. After reboot I get:

## Booting WRT160NL ...
Application code length 0x004e0000
Bad CRC: trx.crc32 0x80fc0812 calculate 0x279f517a
 check link duplex:Full/speed:100
dup 1 speed 100
Tftpd start listening on port[69]!
Load address: 0x80060000
checksum bad

Now I tried the two-stage process I used to work around the CRC bug::

Restored Linksys firmware. Flashed OpenWRT pre-build binary image (Attitude Adjustment 12.09-rc1 / LuCI 0.11 Branch (0.11+svn9491)) using the Linksys web interface. The pre-built image ( r34302) installs just fine. Now I re-flash under OpenWRT with my AA sysupgrade image. On reboot I get:

## Booting WRT160NL ...
Application code length 0x00137464
Bad CRC: trx.crc32 0x9393cd0d calculate 0x3c957e52
 check link duplex:Full/speed:100
dup 1 speed 100
Tftpd start listening on port[69]!
Load address: 0x80060000
checksum bad

Note that this trick doing two-stage flashing so far worked around the CRC bug, but the questions remains, why the pre-built image installs just fine and without any problem under the Linksys UI, while the compiled images do not.

I didn't care to test wether the router will be bricked when keeping the config over regular sysupgrades for the moment, since the patch from comment23 above works very well as a work-around in this scenario, if OpenWRT has been installed before somehow.

But it is still not possible to install self-compiled AA images in the Linksys web interface without bricking the router. I have tested this with a freshly checked-out AA snapshot with almost no changes except for additional packages selected through menuconfig, with and without patch r38964 applied to the image builder Makefile.

comment:34 in reply to: ↑ 33 Changed 15 months ago by chunkeey@…

Replying to anonymous:

Sorry, I was not aware that my comment re-opened the ticket. Under Modify Ticket there is pre-selected "leave as assigned", nothing more that I could set here, so this was not intentional.

Oh no you didn't. That was me confusing this with another ticket. That's clearly my bad. Sorry.

Note: This ticket is not part of the AA milestones, but it is assigned to Chaos Calmer milestone. So, I would advise you to update, otherwise you might be reporting fixed errors.

Replying to anonymous:

I have just applied patch r38964 to the image builder Makefile of my source copy of AA 12.09.1 (r42647). Sadly, the patch does not work for me.

Have a look at r38962... As you can see, if you stick with patching AA, you'll have to do all the backports yourself. This includes finding which patches are relevant, I will not track down them for you.

That's why: go with BB or better... directly trunk. I only care if the problem exists there, I will ignore any further requests for AA.

comment:35 Changed 15 months ago by anonymous

Sorry very much. I just wanted to be helpful. If this wasn't excuse me. I'm out of this discussion, bye.

Add Comment

Modify Ticket

Action
as assigned .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.