but why was it first added and then removed ?
The target platform for your D-Link device is ath79 and said platfom includes uboot-envtools as default for all the routers that use the same platform. But the maintainer (the actual developer that probably has that device at home to test) decided that it's best to exclude that package in the final build.
That's why appears 2 times, one including it and the other excluding it (with the hyphen before the package name).
I asked the same question because it happens to my Cudy X6 V2 (ramips/mt7621 platform).
Cheers!
1 Like
DIR-2660 A1 is also mt7621 just as your Cudy, I think you confused it with DAP-2660 A1 (you gotta love D-Links naming schema 
)
This has been brought up before in a thread a while back (can't find it now), but basically many of the devices in the mt7621 target needs access to the U-Boot environment while flashing (you can see the excerpt from here, it's all of the devices which invoke fw_printenv and fw_setenv (there's technically some more scripts that use it for other devices but that's the biggest one)) to set and read bootflags primarily.
I assume this is the reason that uboot-envtools was moved from device packages to default packages in 79bd017, and as you can see in the codebase neither D-Link DIR-2660 A1 or Cudy X6 V2 needs access to the U-Boot environment while flashing, which is why they now specify -uboot-envtools, presumably to save some flash space.
3 Likes
A thought. Why not have new stable releases and RCs show on the Firmware Selector page when the build for all devices is finished or when it is announced by Hauke? Having a firmware selector show a new RC build when the build bots are still building targets creates unnecessary anticipation and by extension frustration for people. This is especially true when previous RC releases are not available to select in the Firmware Selector once the bots start building on new RCs.
4 Likes
Unable to download x86/64 target with custom packages selected, because The Firmware Selector has learned Cockney English, "init". Is it trying to say "You can't have this firmware with custom package selection bruv, init?"?
Should be fixed, see Owut: OpenWrt Upgrade Tool - #383 by efahl
1 Like
I can confirm it is fixed for x86/64.
3 Likes
libubus20241020 rename to libubus and run the build again. And everything goes normally. This nonsense has been happening for a very long time and with different files that have the creation date in their names. We hope that this will finally be fixed after so much time.
1 Like
I'd love an option to disable dnsmasq, firewall and odhcpd by default (useful for dumb ap).
- Locate:
- Then locate:
- Add configuration to disable dnsmasq, firewall and odhcpd
1 Like
Does "service name disable" work in Uci enviroment?
I thought only uci set...uci del... would work.
I'm not sure why you now inquire about services after asking about UCI - I'm not sure if this is an additional question or requalified.
You would UCI set the config to enabled 0 (or disabled 1, depending on config), orDelete the default config (e.g. firewall, LAN dnsmasq, etc.)
Another option is to A) not install or B) remove the packages from the recipe in the Firmware Selector.
Edit:
Other users noted simply adding the script - that's easier. 
1 Like
@rhbh
Just put this in Luci-Local startup.
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# these services do not run on dumb APs
for i in firewall dnsmasq odhcpd; do
if /etc/init.d/"$i" enabled; then
/etc/init.d/"$i" disable
/etc/init.d/"$i" stop
fi
done
exit 0
3 Likes
Yes. The "uci-defaults script" not really uci-specific, it's a generic shell script where you can do whatever you like. The name comes from when it's executed during the boot sequence, i.e., during the uci configuration phase.
2 Likes