Is it possible to get output from the serial console during the flash process? That may provide information that you can't see from SSH. After all, the upgrade only happens after the shell sessions are closed out.
Well, I wanted to avoid cracking these ones open but I guess I have no other way... Let me check.
I should note that after flashing your image, I am getting a possible lead into what's going on. If I try to flash another image afterward, I'm getting the following:
Watchdog handover: fd=3
- watchdog -
Watchdog does not have CARDRESET support
Wed Mar 6 22:54:02 UTC 2024 upgrade: Sending TERM to remaining processes ...
Wed Mar 6 22:54:02 UTC 2024 upgrade: Sending signal TERM to netifd (1740)
Wed Mar 6 22:54:06 UTC 2024 upgrade: Sending KILL to remaining processes ...
Wed Mar 6 22:54:06 UTC 2024 upgrade: Sending signal KILL to netifd (1740)
[ 6803.932853] stage2 (4073): drop_caches: 3
Wed Mar 6 22:54:14 UTC 2024 upgrade: Switching to ramdisk...
[ 6805.415882] UBIFS (ubi0:7): background thread "ubifs_bgt0_7" stops
[ 6805.428926] UBIFS (ubi0:7): un-mount UBI device 0
Wed Mar 6 22:54:16 UTC 2024 upgrade: Performing system upgrade...
/lib/upgrade/do_stage2: line 14: fitblk: not found
ubiblock: error!: cannot remove block device
error 16 (Resource busy)
cannot remove ubiblock0_5
sysupgrade failed
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 6806.121046] reboot: Restarting system
Please ignore the timestamps; The bench machine doesn't have an internet connection, so it can't get the right date and time.
fitblk
package should always be included in images for this device. Do not remove it.
Probably you copy&paste the list of packages into the firmware selector resulting in fitblk
being removed -- then subsequent sysupgrade won't work. The easy fix is to opkg install fitblk
.
Edit: fitblk
is a tool needed for the new fitblk driver which replaces the uImage.FIT partition parser which was rejected upstream. block subsystem maintainer Christoph Hellwig has rejected the partition parser approach and suggested to write a small stackable block device driver instead -- and that's fitblk. The new tool is needed as, other than the partition parser approach, the new driver is more strict and prevents writes (ie. sysupgrade
) to the underlying block device as long as /dev/fit0
(and /dev/fitrw
on block partitions used on devices booting from eMMC) is present. The fitblk
tool allows to tell the kernel that /dev/fit*
should be released and removed in order to allow for a subsequent sysupgrade
.
Thank you. I think we found @fonix232's problem, then. If the necessary package is missing, it can't perform a sysupgrade and so we'll get precisely what he's experiencing.
Thanks Daniel - and of course @grauerfuchs, you've both been indispensable debugging this little f***er...
Not sure how fitblk
was removed, as I rarely use the Firmware Selector directly, and usually rely on luci-app-attendedsysupgrade. The only copy-paste I do is the list of luci-*
stuff I include, but that goes on the end of the list, nowhere near fitblk...
Anyway, I'm doing a brand new image via the firmware selector just to make sure attendedsysupgrade wasn't the culprit here. My usual config:
Which is basically just replacing mbedtls with openssl, making sure full WPAD is included, then copy-pasting the luci-list at the end.
At least there's a benefit to this whole thing, my RT3200 now has a neat little UART butt plug set:
Ignore the super duper limited edition M5 tape, ran out of kapton and this was the first to get in my hands that wasn't conductive.
Out of curiosity, I checked with myself while on the old kernel, I don't have such a package - fitblk.Is it necessary to add it?
attendedsysupgrade is notorious for not telling you when you need to add a new package to maintain compatibility. If you were going from 23.05.x when you built the new image for snapshot and then ran the updater in between to make sure the router will take it without b0rking, that would do it. This is one of the main reasons why many of the gurus suggest not using attendedsysupgrade to go between major releases.
As for the console access, I've basically done the same for the bench box. I'd already hacked the case open for other changes, so I added a 3-pin 3.5mm jack to the back with a direct connection to the serial. The space beneath the power switch is barely enough to fit the jack if you're handy with a razor knife and a drill.
Ah, that's certainly what happened. I did do exactly that - tried AS, didn't work, tried flashing that FW manually, saw the warning, checked the thread here, did the 1.1.0 upgrade, then flashed the FW from step one. Funny thing is that AS did work once after all this (I remember because I ran into the same compat_version
issue as others due to a restored backup), and that flash somehow ended up losing fitblk
.
Nonetheless I'm happy to report that both RT3200s in my home are now on 25402!
You're fine unless you intend to upgrade to the snapshot or the next major version when it comes out. The 23.05.x series didn't contain the package by default, and it only really becomes an issue when you move to the new layout that is currently in snapshot.
When it comes time to make that big upgrade, you'll probably want to start with the base package list and then add (or alter) your preferences from there. That's where the real value of the firmware selector/customizer lies.
i did something similar with my bricked one (was running 23.05.0 for a few months. i did have an issue when i first set it up where it wouldn't boot, but that resolved itself after a few power cycles, then recently had a thunderstorm that caused what i assume was a power surge that rebooted it and caused a BL2, i assume part of it failing to boot correctly is due to the fact i had it set to ondemand instead of performance, i'm also gonna mention i had attendedsysupgrade installed so maybe there was a pending half-update and when it rebooted it tried to install it, that's something i didn't even think about until writing this tbh)
(didn't feel like soldering or taping anything so i just took a JST connector from the inside of an old bluetooth speaker i had laying around, was surprised that it fit without bending any pins)
still waiting on a legit serial adapter to ship, but i temporarily hooked it up to UART4 on my RPi (can't run mtk_uartboot on arm yet, i might get around to compiling it but i'll prob just wait for the actual usb adapter to come in so i can use windows)
(used the connectors from a rpi fan/case to hold the wires in place essentially, managed to get a reading, BL2)
my second/new one is running perfectly w/ the updated 1.1.1 installer + snapshot, up for 18hrs so far in performance mode, and to be on the safer side of things i didn't install attendedsysupgrade (though it's probably safe now that i'm on the new layout i assume), also probably gonna stay on this snapshot until a stable 24.0 release
I have something similar. Think it's because it installed the snapshot without first installing the recovery-installer.itb file. Good luck!
resetting ...
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02ED [000F]
Jump to BL
NOTICE: BL2: v2.9.0(release):OpenWrt v2023-10-13-0ea67d76-1 (mt7622-snand-ubi-1ddr)
NOTICE: BL2: Built : 21:00:58, Mar 6 2024
NOTICE: WDT: [40000000] Software reset (reboot)
NOTICE: CPU: MT7622
NOTICE: SPI-NAND: FM35Q1GA (128MB)
NOTICE: UBI: scanning [0x80000 - 0x8000000] ...
NOTICE: UBI: scanning is finished
NOTICE: UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE: UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
NOTICE: UBI: Volume fip (Id #0) size is 1019644 bytes
ERROR: BL2: Failed to load image id 5 (-2)
Thank goodness I caught this, it was not installed for me.
In my case it was because I generated an Attended Sysupgrade image while still in SNAPSHOT 5.15, before upgrading the UBI layout and kernel to 6.1... so I had to manually add fitblk
package after.
Sorry if I'm interrupting the very important brick-recovery threads.
Question: Is it a bad idea to run opkg update
every week and upgrade all the packages? I don't know what this does to the flash memory. If it stresses the memory, should I just be judicious and only upgrade for major security fixes or when I need a new feature? What do you folks do?
Thanks
Anybody having wireless issues with Daniel's v1.1.1 ubi update? I was able to run the installer and sysupgrade with latest snapshot but wireless devices show as "Generic unknown" and can't scan. I tried to delete wireless config, wifi config, and reboot but still have the same problem.
While this specific device is unlikely to run out of space very fast it is still not a good idea.
You should use auc
or luci-app-attendedsysupgrade
instead which replace the whole image. And while it's true that NAND memory can only be written a few thousand times in the same place, I'm pretty sure that other things in this device will die first (such as electrolyte capacitors) before you exhaust the write-cycles of the flash, even if you update daily (which is more or less what I've been doing for years on that device).
It does operate differently than before. From the way it's running, I'm guessing that it isn't fully initializing the radio and/or loading the firmware and/or some module it needs (race condition?) on boot unless you have an enabled network attached to the radio.
Workaround: Create a wifi network on the radio and enable it. From that point on (or at least until you reboot it without any enabled wifi networks attached to the radio), it will show up and reply correctly as well as scan.
I just tried this (had to manually type the country code in) and the radios came up! Thanks for the tip. Interesting behavior....