I used https://chef.libremesh.org/ to create some builds from snapshot. I was able to get USB working (I can see a USB stick mounted in LUCI and I can also access the files via SSH) and the display of memory buffers on the Status->Memory->Buffered view also works on the build I made. Compared to your 0.3 package, here are the packages I added:
Mount:
block-mount
blockd
kmod-block2mtd
File system support:
kmod-fs-autofs4
kmod-fs-exfat
kmod-fs-msdos
kmod-fs-ntfs
kmod-fs-vfat
The only issue I am seeing on the build I made is that when I flash an image, I get the error "Cannot open file '/etc/opkg/keys/86241a707a30cb7f' for reading Image check failed." So it appears there is something wrong with the keys and I have to force upgrade (sysupgrade -F). With your 0.3 build, the keys work correctly and I don't get the error as it reads the checksum correctly. Any ideas on what to do about that?
Why block2mtd? This is legacy stuff to emulate MTD device on top of block device, eg. for using JFFS2. There is no reason to use that on modern systems.
Are you using a USB Wifi device?! Because those are driver modules for MT76xx based USB Wifi dongles.
This is most likely due to ucert being installed but the public key needed to verify your local build is missing on the device. Copying your local key-build.pub to /etc/opkg/$PUBKEY_HASH should fix that.
Yes, you can have the *sysupgrade.fit image on an USB drive, but you will have to adapt U-Boot environment to load the system in that way. On the USB drive you will GPT partition table and store the *sysupgrade.git image directly on the partition (ie. NOT inside a filesystem, do not "format" the partition with FAT or anything but directly write to it, e.g. using dd).
Other than being USB intead of MMC, you can take a look at the U-Boot environment of the Bananapi BPi-R64 for an example of how loading kernel form block device.
Apart from loading the image from USB storage device partition, you will also need to set bootargs to root=/dev/sda2 (assuming that you put the FIT image in the first partition mapped to sda1). You also need to create an empty partition with GPT partition label rootfs_data to tell OpenWrt to make use of that).
Apart from that you can rest assured that when using the UBI variant I made some effort to make it hard to brick:
In case image can't be loaded OR either kernel or dtb or rootfs are faulty OR RESET button is held during power up, *recovery image is requested via TFTP from 192.168.1.254.
Holding down the RESET button during power-on also resets U-Boot environment as well as rootfs_data.
UBI manages the flash to wear out evenly, reserves blocks for relocation if needed, does scrubbing, ...
If you do a lot of testing, the best way is probably to change U-Boot environment to always request image via TFTP and then load initramfs/recovery image in that way for testing (that's how I'm doing it).
I guess I can be a test case because I just had a bad flash from GUI. The RT3200 LEDs are both orange. I am using Windows and below is how I have the Ethernet port set up. I can ping the router without any problem (TTL 128) but cannot seem to TFTP the image to the router successfully. Would appreciate your help on best way to recover the router using Windows.
The address you have configured looks correct. I haven't used Windows in more than a decade, but this looks like the right thing to use for this purpose:
@Rovasteen: how did you end up in this situation? Did you accidentally flash non-UBI or stock firmware (because that would obviously destroy UBI storage and reasult in the situation you describe)?
Not sure because I flashed a self-compiled image I had used before and it uploaded and CRC went fine. So not sure why the flash failed.
The initial reason why I was flashing another image and not using the 0.3 image is because when I try to upgrade the packages from LUCI in that image, I get an error that the file system is read only. Any insight on how to address that would be appreciated!
This worked brilliantly and your design on UBOOT's recovery mechanism is something that I have never seen before, and I think it is really cool!
Here is what I did to recover the router using a Windows PC:
Set Ethernet port on your PC to IP address 192.168.1.254
Install TFTP server from https://tftpd32.jounin.net/ and run the TFTP server
Change the directory on the TFTP server to the directory where your “initramfs-recovery.itb” file is located. The router will fetch the recovery image and reboot.
SSH to the router using Putty.
Open a CMD window in Windows and SCP a normal image to the router using a command structure such as “scp sysupgrade.itb root@192.168.1.1:/tmp” which places the file on the router’s “/tmp” directory
Although counter-intuitive, it makes sense that well-designed internal antennas can be equal if not better than poorly-designed external ones. Can you share the routers that you have which have such well-designed internal antenna, in your usage?
So if I were to buy an RT3200, will the E8450 build now in the snapshots/mediatek/mt7622 directory work on it? Is it "ready for prime time" with all features supported?
I added, LuCI, Luci-Adblock, Luci-sqm, iperf3 and htop. And removed USB-stuff completely.
You can use the imagebuilder if you want. wget https://downloads.openwrt.org/snapshots/targets/mediatek/mt7622/openwrt-imagebuilder-mediatek-mt7622.Linux-x86_64.tar.xz
make image PROFILE="linksys_e8450-ubi" PACKAGES="luci luci-app-sqm"
will give you an image with luci and luci-app-sqm. You can easily extend the command to add extra packages.
Do you know specific router models where the internal antennas are good? I am also hoping that @slh can share that information too, based on my request above. It would be nice to perhaps collect such information and share it in a wiki.
These are old models, but the Netgear R6250 and Netgear R6300 had very good internal antennas back in the day. The D-Link series that included the D-Link DIR-868L also had good internal antennas. What are you collecting the data for?
