It sounds like there is an unmet kernel or kernel-module requirement, but that should not happen.
I need to know exactly how you are trying to install those packages. Are you following a how-to document or someone's forum post? Are you using the command line or the luci web interface?
I enter the address "https://192.168.1.1/cgi-bin/luci/admin/system/opkg" through the luci web interface, look for the package or program in "Filter:" and then by pressing install .. me It displays a list of packages or additional programs needed, giving me an item "INCOMPATIBLE VERSION". I don't know what happens if you install the package or program, avoiding that mention of incompatible
Details for package luci-app-minidlna
Version: git-20.115.52331-39a8290-1
Size: ~ 3.2 KB installed
Dependencies:
luci-compat INSTALLED
luci-base INSTALLED
lua INSTALLED
liblua5.1.5 INSTALLED
luci-lib-nixio INSTALLED
luci-lib-ip INSTALLED
libnl-tiny INSTALLED
rpcd INSTALLED
libubus20191227 INSTALLED
libubox20191228 INSTALLED
libuci20130104 INSTALLED
libblobmsg-json INSTALLED
libjson-c2 INSTALLED
libubus-lua INSTALLED
luci-lib-jsonc INSTALLED
liblucihttp-lua INSTALLED
liblucihttp0 INSTALLED
rpcd-mod-file INSTALLED
rpcd-mod-luci INSTALLED
cgi-io INSTALLED
minidlna (126.9 KB) NOT INSTALLED
libpthread INSTALLED
libgcc1 INSTALLED
libexif (62.8 KB) NOT INSTALLED
libjpeg (92.3 KB) NOT INSTALLED
libsqlite3-0 (453.5 KB) NOT INSTALLED
zlib INSTALLED
libffmpeg-audio-dec (707.5 KB) NOT INSTALLED | libffmpeg-full (5.1 MB) NOT INSTALLED | libffmpeg-mini (634.8 KB) NOT INSTALLED
libbz2-1.0 (24.3 KB) NOT INSTALLED
alsa-lib (306.7 KB) NOT INSTALLED
kmod-sound-core (137.9 KB) NOT INSTALLED
INCOMPATIBLE VERSION kernel
kmod-input-core (18.1 KB) NOT INSTALLED
librt INSTALLED
libopus (175.0 KB) NOT INSTALLED
lame-lib (119.3 KB) NOT INSTALLED
libid3tag (24.8 KB) NOT INSTALLED
libflac (71.4 KB) NOT INSTALLED
libvorbis (179.4 KB) NOT INSTALLED
libogg (8.5 KB) NOT INSTALLED
libuuid1 INSTALLED
Description
LuCI Support for miniDLNA
The installed version of package kernel is not compatible, require 4.14.171-1-0894164c… while 4.14.171-1-3579383f… is installed.
There is a Green Text button at the top of that page which will say "Update Lists...". Make sure to press that first, then try again.
If it still fails, I want you to copy/paste the text it gives you after you press the Update Lists button and post it here.
Hello! after installing the package anyway as you mentioned, minidlna is working anyway! . I also have the torrent client and a samba server installed. everything is working delivering better values than with the original firmware, even the wifi power is extremely higher in 5ghz AC network, it reaches points in my home that previously had no coverage, I hope the router does not suffer damage.
I only have one problem! The connected hard disk never turns off and I don't know why, nobody is requesting it, neither torrent nor minidlna nor samba. Formerly with original firmware it would shut down after a period of time only. It is configured in the firmware of my Seagate 2Tb expansion hard disk that after 15 minutes it turns off, but Openwrt reads it every few seconds unnecessarily because I see its light blink. Do you have any suggestion ? thanks for the hard work to run Openwrt
I can't help you with that one. I suggest you make a new post in the main help forum about it. You might be able to use a tool like "lsof" to find out what is using the disk.
Good luck
Mister Jmomo! I was able to investigate what is happening from your command. I found a solution. I leave the link maybe someone needs it.
https://forum.openwrt.org/t/i-need-help-getting-my-hard-drive-to-shutdown-by-itself/62405
Trendnet is selling TEW-827DRU v2.0R recertified.
https://www.trendnet.com/store/products/product-detail?prod=105_RB-TEW-827DRU
This appears to be a Mediatek based version that would be significantly castrated.
https://wikidevi.wi-cat.ru/TRENDnet_TEW-827DRU_v2.0R
Hi jmomo,
I've finally gotten the actual TEW-827DRU recovery console log when unsuccessfully attempting the method "uboot http Recovery Loader". It looks like the LEDE script failed to recognize the NAND FLASH in my TEW-827DRU (and those of some of the other users as I had previously mentioned.)
LEDE TEW-827DRU script START.
Flashing the UBI image...
Removing MTD device #0 (nand0) with use count 1
Failed to set ipq_nand: Quitting.
resetting ...
Resetting with watch dog!
U-Boot 2012.07 [Standard IPQ806X.LN,r40331] (Nov 17 2015 - 19:33:37)
smem ram ptable found: ver: 0 len: 5
DRAM: 491 MiB
NAND: SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
FULL RECOVERY CONSOLE LOG
U-Boot 2012.07 [Standard IPQ806X.LN,r40331] (Nov 17 2015 - 19:33:37)
smem ram ptable found: ver: 0 len: 5
DRAM: 491 MiB
NAND: SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
MMC:
PCI0 Link Intialized
PCI1 Link Intialized
In: serial
Out: serial
Err: serial
cdp: get part failed for 0:HLOS
Net: MAC1 addr:0:3:7f:ba:db:1
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init done
MAC2 addr:0:3:7f:ba:db:2
eth0, eth1
Hit any key to stop autoboot: 2 1 0
Mac1 unit failed
Mac2 unit failed
fail WHY
MMC Device 0 not found
MMC Device 0 not found
Mac1 unit failed
Mac2 unit failed
fail WHY
Mac1 unit failed
Mac2 unit failed
fail WHY
Creating 1 MTD partitions on "nand0":
0x0000058a0000-0x0000098a0000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 64 MiB
UBI: number of good PEBs: 512
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 3
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 512
UBI: number of PEBs reserved for bad PEB handling: 5
UBI: max/mean erase counter: 2/0
Read 0 bytes from volume kernel to 44000000
No size specified -> Using max size (2412544)
Image Name: ARM OpenWrt Linux-4.14.171
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2347798 Bytes = 2.2 MiB
Load Address: 42208000
Entry Point: 42208000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Mac1 unit failed
backup_mode_handle Using eth1 device
localMac is:
4cchttp init
hostmac = default_mac_from_artblock: 00:03:7F:BA:DB:02 from 0xBF7FFFA0
00:03:7f:ba:db:02
hostaddr = 0xa8c00100
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
offset is 0, offset = 1 is GET , = 0 is POST
Open index.html
httpd_appcall 414 : Send file later len:859:
ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.offset is 1, offset = 1 is GET , = 0 is POST
ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.mime_content_body 360: Current_Length: 5837824 content_len: 5902785
mime_content_body 360: Current_Length: 5838848 content_len: 5902785
mime_content_body 360: Current_Length: 5839872 content_len: 5902785
mime_content_body 360: Current_Length: 5840896 content_len: 5902785
mime_content_body 360: Current_Length: 5841920 content_len: 5902785
mime_content_body 360: Current_Length: 5842944 content_len: 5902785
mime_content_body 360: Current_Length: 5843968 content_len: 5902785
mime_content_body 360: Current_Length: 5844992 content_len: 5902785
mime_content_body 360: Current_Length: 5846016 content_len: 5902785
mime_content_body 360: Current_Length: 5847040 content_len: 5902785
mime_content_body 360: Current_Length: 5848064 content_len: 5902785
mime_content_body 360: Current_Length: 5849088 content_len: 5902785
mime_content_body 360: Current_Length: 5850112 content_len: 5902785
mime_content_body 360: Current_Length: 5851136 content_len: 5902785
mime_content_body 360: Current_Length: 5852160 content_len: 5902785
mime_content_body 360: Current_Length: 5853184 content_len: 5902785
mime_content_body 360: Current_Length: 5854208 content_len: 5902785
mime_content_body 360: Current_Length: 5855232 content_len: 5902785
mime_content_body 360: Current_Length: 5856256 content_len: 5902785
mime_content_body 360: Current_Length: 5857280 content_len: 5902785
mime_content_body 360: Current_Length: 5858304 content_len: 5902785
mime_content_body 360: Current_Length: 5859328 content_len: 5902785
mime_content_body 360: Current_Length: 5860352 content_len: 5902785
mime_content_body 360: Current_Length: 5861376 content_len: 5902785
mime_content_body 360: Current_Length: 5862400 content_len: 5902785
mime_content_body 360: Current_Length: 5863424 content_len: 5902785
mime_content_body 360: Current_Length: 5864448 content_len: 5902785
mime_content_body 360: Current_Length: 5865472 content_len: 5902785
mime_content_body 360: Current_Length: 5866496 content_len: 5902785
mime_content_body 360: Current_Length: 5867520 content_len: 5902785
mime_content_body 360: Current_Length: 5868544 content_len: 5902785
mime_content_body 360: Current_Length: 5869568 content_len: 5902785
mime_content_body 360: Current_Length: 5870592 content_len: 5902785
mime_content_body 360: Current_Length: 5871616 content_len: 5902785
mime_content_body 360: Current_Length: 5872640 content_len: 5902785
mime_content_body 360: Current_Length: 5873664 content_len: 5902785
mime_content_body 360: Current_Length: 5874688 content_len: 5902785
mime_content_body 360: Current_Length: 5875712 content_len: 5902785
mime_content_body 360: Current_Length: 5876736 content_len: 5902785
mime_content_body 360: Current_Length: 5877760 content_len: 5902785
mime_content_body 360: Current_Length: 5878784 content_len: 5902785
mime_content_body 360: Current_Length: 5879808 content_len: 5902785
mime_content_body 360: Current_Length: 5880832 content_len: 5902785
mime_content_body 360: Current_Length: 5881856 content_len: 5902785
mime_content_body 360: Current_Length: 5882880 content_len: 5902785
mime_content_body 360: Current_Length: 5883904 content_len: 5902785
mime_content_body 360: Current_Length: 5884928 content_len: 5902785
mime_content_body 360: Current_Length: 5885952 content_len: 5902785
mime_content_body 360: Current_Length: 5886976 content_len: 5902785
mime_content_body 360: Current_Length: 5888000 content_len: 5902785
mime_content_body 360: Current_Length: 5889024 content_len: 5902785
mime_content_body 360: Current_Length: 5890048 content_len: 5902785
mime_content_body 360: Current_Length: 5891072 content_len: 5902785
mime_content_body 360: Current_Length: 5892096 content_len: 5902785
mime_content_body 360: Current_Length: 5893120 content_len: 5902785
mime_content_body 360: Current_Length: 5894144 content_len: 5902785
mime_content_body 360: Current_Length: 5895168 content_len: 5902785
mime_content_body 360: Current_Length: 5896192 content_len: 5902785
mime_content_body 360: Current_Length: 5897216 content_len: 5902785
mime_content_body 360: Current_Length: 5898240 content_len: 5902785
mime_content_body 360: Current_Length: 5899264 content_len: 5902785
mime_content_body 360: Current_Length: 5900288 content_len: 5902785
mime_content_body 360: Current_Length: 5901312 content_len: 5902785
mime_content_body 360: Current_Length: 5902336 content_len: 5902785
mime_content_body 360: Current_Length: 5902785 content_len: 5902785
mime_content_body 371 congraturation! size: 5902528, go to count down
http_appcall() : send count down page
httpd_appcall 414 : Send file later len:1135:
Hit any key to stop autoboot: 2 1 0
## Executing script at 42000000
crc32+
------------------------------------------------------------
LEDE TEW-827DRU script START.
Flashing the UBI image...
Removing MTD device #0 (nand0) with use count 1
Failed to set ipq_nand: Quitting.
resetting ...
Resetting with watch dog!
U-Boot 2012.07 [Standard IPQ806X.LN,r40331] (Nov 17 2015 - 19:33:37)
smem ram ptable found: ver: 0 len: 5
DRAM: 491 MiB
NAND: SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
MMC:
PCI0 Link Intialized
PCI1 Link Intialized
In: serial
Out: serial
Err: serial
cdp: get part failed for 0:HLOS
Net: MAC1 addr:0:3:7f:ba:db:1
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init done
MAC2 addr:0:3:7f:ba:db:2
eth0, eth1
Hit any key to stop autoboot: 2 1 0
MMC Device 0 not found
MMC Device 0 not found
Creating 1 MTD partitions on "nand0":
0x0000058a0000-0x0000098a0000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 64 MiB
UBI: number of good PEBs: 512
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 3
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 512
UBI: number of PEBs reserved for bad PEB handling: 5
UBI: max/mean erase counter: 2/0
Read 0 bytes from volume kernel to 44000000
No size specified -> Using max size (2412544)
Image Name: ARM OpenWrt Linux-4.14.171
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2347798 Bytes = 2.2 MiB
Load Address: 42208000
Entry Point: 42208000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
device nand0 <nand0>, # parts = 1
#: name size offset mask_flags
0: fs 0x04000000 0x058a0000 0
active partition: nand0,0 - (fs) 0x04000000 @ 0x058a0000
defaults:
mtdids : none
mtdparts: none
Using machid 0x1260 from environment
Starting kernel ...
FYI,
Using the method "Console uboot tftp", I was able to successfully flash my TEW-827DRU with your 19.07.2 firmware.
However, the method "uboot http Recovery Loader" failed 100% on my TEW-827DRU with the aforementioned NAND flash error.
Best regards.
Hope you will see the message notification...
Here's the important part from your log:
LEDE TEW-827DRU script START.
Flashing the UBI image...
Removing MTD device #0 (nand0) with use count 1
Failed to set ipq_nand: Quitting.
resetting ...
It's failing on the ipq_nand command. This command is built into uboot and it prepares the SLC NAND flash for writing, which means assembling the UBI.
The strange thing is that the tftp method also runs the same script which calls ipq_nand.
I'll think about this for awhile. I might ask you to dump some of your partitions and upload them to me for analysis.
Hi jmomo,
I did some other tests and found that the "uboot http Recovery Loader" method also failed with the same "ipq_nand" error when using Trendnet OEM firmware images, so there was nothing wrong with your OpenWrt images. Nevertheless, the "Console uboot tftp" method always works for both your OpenWrt images and Trendnet OEM images.
The problem may be either the crappy Trendnet uboot http Recovery Loader (and its recovery GUI's fake upgrade success message) or some timing issue when invoking the command. The script may need to add some additional delay and/or attempt the command several times in a loop.
If you don't think neither of these workarounds may work, please add a note to your OEM http upgrade tool section about this possible failure on some TEW-827DRU routers, and indicate that users will need to use the "Console uboot tftp" method in such cases.
Best regards.
Thanks for confirming that the OEM firmware install also fails. I was looking at the OEM image FIT script yesterday and suspected it would also fail because it has a similar ipq_nand command string which exits on error.
I think this might be something that can be worked around, or at least I can figure out why it's happening.
The ipq_nand command in uboot prepares the NAND by mounting the UBI. This command only needs to get run once, and if it is run twice, it throws an error.
Normally the recovery loader should not be running ipq_nand, but it's obvious that sometimes it is.
I looked in my old dev logs and found at least one instance where this happened to me too, so I might be able to reproduce it.
For me, it only happened to me once or twice out of a hundred or more recovery loader boots, but for you it's happening every time. That strongly implies an environmental issue.
It might be caused by the reset button not being held down at the right time, for long enough, too late, or something similar.
We have the source code for the recovery loader, so I'll go take a look at it later. It's probably a race or something stupid.
It may be a few days before I get back to this. I'm a little busy this week.
Interestingly, I had no problem reproducing this issue. In fact, I can't get it to stop! WTF.
I tested the recovery loader as recently as a month ago when someone else had asked about a similar problem and I tested re-installing the OEM firmware and then re-installing OpenWRT.
I wonder what has changed.... quite the mystery.
Oh-man! Sars-nCoV-2 bug has even spread to TEW-827DRU routers 
But I'm sure our jmomo will get a vaccine for it sooner or later!
I was looking at the source code for uboot and figured it out.
If you connect a computer's network interface directly to the router it will work fine.
If you only put a switch between the router and your computer it will fail.
So, for the time being, the solution is simple: To use the Recovery Loader you must directly connect your computer to the router. You should not use a switch in between.
If you look at the Trendnet source code under qsdk_gpl/qca/src/u-boot/common/main.c, backup_mode_handle() triggers the recovery loader. It goes through a bunch of functions to initialize the network interfaces and for some reason that's failing and then the UBI gets assembled for some reason I don't yet understand. I need to look into it more. It's probably doing MDIX wrong or something stupid. They might have even done this on purpose, or it's just a bug. I don't know yet.
I may be able to work around it anyway. All I really have to do is disassemble the UBI first.
It might be a week or two before I can work on this again, but for now at least we know what is triggering the issue.
Hi jmomo,
i actually tried all the following methods. The Recovery Loader failed (with the same ipq_nand error) for all of them.
Best regards.
It's a timing issue and depends on how fast your network interface hardware comes up. That's why it's working for some setups and not working for others.
My cheap testing switch comes up slow. My Pluggable USB network adapter comes up fast. OS won't matter since the speed that the MII/physical layer-1 comes up is mostly dependent upon hardware.
The way Trendnet implemented the Recovery Loader seems really dumb. The main() loop keeps running and they don't break when the reset button is detected.
When the reset button is detected from the main() loop, the backup_mode_handle() func triggers. It then tries to bring up one of the two network interfaces. If it fails you get that "fail WHY" message. If it succeeds the Recovery Loader httpd program gets run and you get the "backup_mode_handle Using ethX device" message.
The problem is that some network interfaces on a computer or switch come up slower than the loop runs and it fails a number of times before seeing a network interface come up. During that time the boot process just keeps going. In your log we can see the UBI gets assembled and the kernel gets read into memory. The same thing happens with my testing switch.
Having the UBI assembled causes the ipq_nand command to fail, and that's why our installer script isn't working when the connected network interface comes up slowly.
I may be able to work around this in the installer script. I'll have to do some testing.
However, some network interfaces could potentially be slow enough that the Recovery Loader never triggers at all, even with the button pressed down. This might explain why I've had a few reports of people not being able to get to the Recovery Loader.
The solution for now is to try a different network adapter or switch and hope it comes up faster.
Unfortunately there is no way to tell if the Recovery Loader is going to fail without having serial console access.
I will update my installation instructions with some new warnings and guidance.
I will also try to find a workaround. It turns out there's no method for disassembling a UBI in this uboot, so this may not be so simple.
Thanks a lot jmomo. From your clear explanations, I believe you have finally nailed down the culprit.
Superficially speaking, just from the look of how Trendnet Recovery GUI shows fake success, I can already tell how horrible their actual Recovery Loader code would be. Proper programming dictates the ability to handle error conditions as much as possible, not simply the ability to run when one particular condition is met. Such problems are also seen in lame code for products from even the biggest commercial companies (not just from a puny one like Trendnet.)
All the laptops (business-class Dell Latitude and Lenovo Thinkpad) I used have built-in Ethernet port, not the thin Ultrabook laptops with only USB-C ports and ugly dangling accessories like USB-Ethernet adapter etc.
Thank you very much for all your time and dedication in resolving issues.
Best regards.
I published a new build which has a workaround for the Recovery Loader bug we have been discussing in this thread:
vochong, thank you for your help in discovering this issue.
The workaround is kinda ugly but it does the job.