On Fri, Dec 6, 2019 at 12:41 PM wes <p...@the-wes.com> wrote: > On Fri, Dec 6, 2019 at 11:11 AM Louis Kowolowski <lou...@cryptomonkeys.org > > > wrote: > > > If you’re getting “file too large”, its probably the client complaining, > > not the server. > > > One would reasonably think that, but no. This was output in the server log. > Literally "file to large" (grammar error included). > > When I’ve had that in the past, its because legacy firmware made > > assumptions about file size and there was some intermediate firmware that > > fixed it, allowing you to move forward. > > > Note that we're not even uploading a firmware file at this stage; we are > merely booting a temporary OS which will then be used to update the > router's actual firmware. This is the way the edgerouter people want us to > do it. >
You are on the right track. What is going on here is that the ERX device uses NAND flash. NAND flash tends to be much larger than the alternative NOR flash but is also prone to bad blocks, and you need a layer of abstraction to deal with the bad blocks and wear leveling so other layers don't need to deal with it, and that layer in this instance is something called UBI (unsorted block image). Note that confusingly, UBIFS is something different than UBI, but is usually used on top of the UBI block layer. NOR flash generally doesn't have this bad block problem, and the flash process for NOR flash is much simpler. With NAND flash, particularly in this recovery scenario, more tools are required than typically are present in the bootloader. For example, you might need to remove, resize and/or recreate the partition-like volumes that are allocated from the UBI block layer. Booting an initramfs image over the network (from an off-device TFTP server) provides the needed tools without modifying the underlying flash. When I was investigating this problem for Rich, I found that the expedient recovery process involved booting an OpenWrt initramfs image, and (with the tools that come with that) manipulate the contents of the flash to correct whatever is wrong. OpenWrt and the Ubiquiti stock firmware organize things differently. On this device, OpenWrt would create a UBI volume for a read-only squashfs file system, and another UBI volume with whatever space is left over for a writable filesystem, which is overlaid (with overlayfs) on top of the squashfs to give the appearance of a fully writable filesystem with the ability to recover to a known good state. In the case of Ubiquiti's stock firmware, they create a large UBIFS filesystem and put read-only images and integrity hashes as regular files on that. The system can check that they are okay and load them. In addition, they put configuration information in directory trees directly on the UBIFS as well. This provides some scaffolding for having two versions of their firmware on the system at the same time (new vs old). What I remember (memory that has become wobbly in the week or so since I was looking at this) is that probably the easiest way to recover Rich's bricked device is to do the initramfs boot of OpenWrt and then just delete the configuration trees in Ubiquiti's UBIFS, and then reboot. The Ubiquiti firmware is smart enough to reconstruct the configuration info it needs from nothing, but it's confused by the configuration that's there now. Anyway, that was my educated guess. Because of Rich's difficulty in getting a simple ethernet configuration to work, I didn't want to try to talk him through this fairly complex and fiddly process over email. Note, the ERX device loads initramfs images as a client from a remote TFTP server. To initramfs boot, you put the image on the server and use a serial console to tell the ERX to fetch the initramfs to RAM. You use the serial console to interrupt the normal boot process and select the initramfs boot, and then tell the ERX what its ip address is, what the server ip address is, and what the filename is relative to the TFTP server space. > > > > You may also be able to use a different protocol to copy the file. Many > > modern devices will allow http(s)/scp/ftp/tftp. > > > > > I did not find any mention of the edgerouter boot ROM supporting this. If > you can find evidence of it, please share. > > -wes > _______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
