Broken opkg/gpkg --tmp-dir option

[Cthulhu]

Running version 1.14, I needed to install gcc to an USB stick, but kept running into an out of memory failure caused by downloading the package (which is too large for my RAM specs) into /tmp.
The --tmp-dir/-t option, which can solve this issue, is unfortunately broken and does nothing.

Assign the option's argument to key "tmp-dir": /blob/ae547ce5113ce1c6e260112bcdcab9f41e3e7ab8/package/gpkg/src/gpkg.c#L177
Reference the option's argument from key "tmp_dir" (always NULL as nothing assigns to this key): /blob/ae547ce5113ce1c6e260112bcdcab9f41e3e7ab8/package/gpkg/src/gpkg.c#L29
(can't post links, just prefix these paths with the project's GitHub repository)

Because of the difference in key names, tmp_root always points to "/tmp".

First I considered creating symlinks in /tmp, but found that the create_tmp_dir function appends a rand() suffix to the dir name.
A solution that worked for me was to patch gpkg's binary, changing the static storage duration constant from "tmp_dir" to "tmp-dir".

Note that default opkg.conf lacks /releases/22.03.5/targets/ath79/generic/packages which is required for libstdcpp6 (gcc package depends on libstdcpp6). /etc/opkg/distfeeds.conf has it, but this file is not actually used by gpkg.

[Lantis]

Thanks for the report, I’ll take care of it.
You did all the hard work! If you have the skills you definitely could have submitted a pull request for me to accept but I’m also happy to take clear bug reports (such as this) and work with them.

If you want to add the <target>/<subtarget>/packages repository you can do so as you would add any other additional repo.
The reason it is not added by default is that it is full of kmods which will be incompatible with the Gargoyle kernel (different kernel magic string). It just tends to add confusion for users who don’t know any better.
Gargoyle includes the “kernel specific” repository which is the equivalent.

[Cthulhu]

If you have the skills you definitely could have submitted a pull request for me to accept but I’m also happy to take clear bug reports (such as this) and work with them.

Currently, I do not have a proper environment to compile, deploy and test OpenWrt builds and I would rather not submit PRs without compiling and testing them first. Also, I do not have a GitHub account, in case this is the only medium in which PRs are merged.
Making a forum post describing the problem and its solution to people who can trivially compile, deploy and commit felt good enough.

If you want to add the <target>/<subtarget>/packages repository you can do so as you would add any other additional repo.
The reason it is not added by default is that it is full of kmods which will be incompatible with the Gargoyle kernel (different kernel magic string). It just tends to add confusion for users who don’t know any better.
Gargoyle includes the “kernel specific” repository which is the equivalent.

Right, that's what I did, but figured it's worth a mention that some popular packages won't install with the default feeds, at least for ath79.

[Lantis]

Just to close the loop for you.
https://github.com/ericpaulbishop/gargo ... ac3f3c225e

[Cthulhu]

Just to close the loop for you.
https://github.com/ericpaulbishop/gargo ... ac3f3c225e

Nice.

By the way, do you've any idea why this works on Gargoyle 1.14 but fails on OpenWrt 23.05 (both on ath79)? https://forum.openwrt.org/t/ethernet-le ... -v3/202378

On OpenWrt, the ioctl calls fail and set errno to EOPNOTSUPP, possibly from https://github.com/openwrt/openwrt/blob ... 1182-L1183

I've tried installing the following kmods: kmod-mdio, kmod-libphy, kmod-fixed-phy and kmod-mii.

I've also tried different setups for the eth0 interface, from a noop interface to a wan interface.

EDIT: Seems like it's not getting probed, the libphy package doesn't seem contain anything other than the module name to load.

EDIT: From linux/netdevice.h:

Code: Select all

 * int (*ndo_do_ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd);
 *	Old-style ioctl entry point. This is used internally by the
 *	appletalk and ieee802154 subsystems but is no longer called by
 *	the device ioctl handler.

The comment was changed to this one sometime around 5.15; I wonder if this is the reason it's failing.

EDIT: *Sigh* just my luck as always.
https://elixir.bootlin.com/linux/v5.15. ... xx.c#L1855
https://elixir.bootlin.com/linux/v5.10/ ... xx.c#L1844

[Lantis]

A little beyond my pay grade to be honest, but at least the OpenWrt devs seem to understand and be responding.
Do you know exactly which kernel version implemented this change?
I was going to bring Gargoyle up to 23.05.4, but with the wifi issue being reported I'm now waiting.
Hopefully we can pick up both fixes.

[Cthulhu]

Do you know exactly which kernel version implemented this change?

v5.15-rc1, which means every 23.05 stable release has broken/non-functional ag71xx ioctls. A completely unnecessary change where even the author admitted it was purely cosmetic, but hey, that's Linux for you.