<totkeks>
I just had a weird bug with openwrt which in the end seemed like an apk issue. I was testing out stubby and had some issues starting it. So, I tried reinstalling the package with `apk del stubby` and `apk add stubby`. This worked, but my uci was throwing "invalid argument" all the time when using `uci commit`. After some research I figured out there was a `stubby.apk-new` file in /etc/config, which confused uci.
dviola has joined #openwrt-devel
<dviola>
hi
<dviola>
if I were to port a driver from ar71xx to ath79 (for learning purposes), would I need to flash the firmware multiples times on my router to test this?
<dviola>
I wonder if there is another way
<dviola>
I have an older router that I want to test latest openwrt on, but is not supported anymore, and the device has low RAM/flash
<dviola>
on #openwrt I was told yesterday it would not be viable
<dviola>
I'm still curious whether there's anything else other than the limited storage that makes this inviable
<ynezz>
so its not a driver, its arch, thus if your bootloader supports loading of initramfs images, you can boot them over network (tftp boot or such)
<dviola>
oh
<ynezz>
on archer-c7-v5: tftpboot 0x81000000 openwrt-ath79-generic-tplink_archer-c7-v5-initramfs-kernel.bin
<efahl>
totkeks: I just played with this and it appears that the .apk-new is dealt with differently than the old .opkg suffix
n3ph has joined #openwrt-devel
<efahl>
uci throws "invalid argument" with apk-new and "entry not found" for .opkg
<efahl>
It looks like the ".apk-new" is a well established convention through apk code, so we probably need new handling in uci
<totkeks>
efahl: ah okay, so having that duplicate file is intended as a kind of backup when reinstalling something that would overwrite a file? and then just uci fails to handle that properly. Thanks for testing
<efahl>
Right, the old 'opkg install stubby' would create '/etc/config/stubby.opkg' in the same circumstance, but I suspect the '-' in the new apk-version of the same file is causing uci grief
<efahl>
Looking through the apk stuff, it appears it does a hash on the files that would be overwritten and if they have changed, then it doesn't overwrite but creates 'file.apk-new' beside the file it would have overwritten.
n3ph has quit [Ping timeout: 480 seconds]
<dviola>
ynezz: that seems a bit confusing to me at the moment, I'm not familiar with ar71xx/ath79 nor with this device, but I'll look into it
<Piraty>
efahl: totkeks yes. <@ikke> Piraty: There's /etc/apk/protected_paths.d, but '/etc/*' is hardcoded
<Piraty>
in case you wonder which files will be replced and which will not ;)
<Piraty>
i really wonder if the move to apk was the right choice, given yoctoproject has a decently maintained opkg fork
<efahl>
yeah, I don't see anything wrong with apk's behavior, it's just doing what opkg always did.
<Piraty>
at least you could inspect ipk for the protected paths
<Piraty>
with apk it seems to be implicit, which sucks
<Piraty>
as far as i'm aware only chimera uses apk3 , not even alpine migrated
<dviola>
I would be ok with tinerking with the initramfs on the router but before doing that I'd probably need a way to recover in case things go wrong with flashing, etc
<dviola>
tinkering*
<efahl>
it's just that the apk "backup" version has that dash in it, which normally would be fine, but in /etc/config, it borks uci
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
<efahl>
totkeks: you should definitely create an issue for this, if "uci commit" fails every time there's a *.apk-new file in /etc/config, that's going to break a lot of stuff
<robimarko>
ynezz: it works for me, it might be a good idea to put the current postinst script as pre-install
<robimarko>
But thats optimisation
<robimarko>
I merged it, lets see if if breaks something
<totkeks>
i got another issue with stubby. it puts it data in /var/lib/stubby when starting. the root keys or something. unfortunately, that folder is gone after reboot due to /var being on /tmp. should the init script handle that to make sure the folder exists and has the right permissions?
totkeks has quit [Remote host closed the connection]
hurricos has joined #openwrt-devel
<mrkiko>
So, after some time I managed to boot openwrt via nfs root ... mediatek target. I still need to understand why it seems that even if I enable nfs root in make kernel_menuconfig, the final .config ends up with the option disabled...
<mrkiko>
but my question is - is there a way I can force overlay over tmpfs? the image tries to mount a jffs2 partition but I would like changes to be saved in RAM and not in flash
<mrkiko>
I am using initramfs image but this root nfs thing probably confuses the code a bit
<mrkiko>
*a bit*
tohojo has quit [Remote host closed the connection]
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
n3ph_ has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
<dviola>
is adding a new device for e.g. ath79 mostly a matter of adding the dts/dtsi and related files?
<dviola>
I still need to become familiar with it, but I wonder whether it would be possible, and whether I would be able to make a smaller image (I don't need luci)
<Habbie>
skipping luci definitely helps
<dviola>
well, I could definitely configure things from the CLI
<dviola>
my device has 4MB flash
<dviola>
but I'm not familiar with the dts/dtsi files, etc
<robimarko>
4MB is close to impossible without disabling everything you could think of
<robimarko>
Does it at least have 64 or more MB of RAM?
<mrkiko>
my second point (initramfs detection) was wrong - my fault. The code works perfectly and detects initramfs. The first one remains
<mrkiko>
even tough it's well possible I'm mistaken
gromero_ has quit [Ping timeout: 480 seconds]
<dviola>
robimarko: it does seem to have 32 MB of RAM, but I mostly need it for running hostapd, nothing fancy
<robimarko>
I doubt even that is achievable, especially if you try sysupgrading
<dviola>
right now an older build of openwrt is using like 15% of the total RAM and it has luci on it
<dviola>
robimarko: ah, I could get a new device but I was thinking whether it would be achievable
<robimarko>
There is no way whatever the version that you are using 15% or 32MB of RAM only
<slh>
both 4 MB flash and 32 MB RAM have gotten effectively impossible. you'd have to make really hard decisions (and we aren't talking lcui or opkg/ apk here) to get below ~5.x MB - and as soon as you load your wireless drivers, the router will simply OOM (and no point even thinking about sysupgrades, as you don't have the RAM available for another 4 MB for your new image)
<dviola>
robimarko: that's what luci says
<slh>
then you're reading it wrong
<robimarko>
What is cat /proc/meminfo saying?
<dviola>
Total Available 3828 kB / 27820 kB (13%)
<dviola>
robimarko: ugh, I haven't enabled SSH yet
<robimarko>
That makes more sense, 13% is free not only 13% is being used
<dviola>
Free 2616 kB / 27820 kB (9%)
<robimarko>
No way you are going to get anything running without OOM
<robimarko>
Thats even if you can somehow squeeze it into 4MB of storage first
<dviola>
oh, I didn't realize I was reading that wrong
<dviola>
damn
<slh>
15% of 32 MB would be 4.8 MB RAM, it has never been possible to boot OpenWrt with that little, not even two decades ago
<dviola>
the previous stock firmware was making the router freeze a lot, had to reboot it two times a day by removing the power cord... openwrt for some reason made it work again
lucenera has quit [Read error: Connection reset by peer]
lucenera9 is now known as lucenera
<dviola>
so yeah, I don't think it would be worst than what I've already had, it could only be better in my opinion
<dviola>
but yeah I'll just get a new device, sounds like time better spent
<slh>
aside from the point that it simply won't fit, nor manage to boot up and activate the wlan
<slh>
if you had at least 64 MB RAM, I'd suggest to replace the flash chip with a larger one (16 MB) and do a custom build, no chance to get your custom modified hardware submitted to OpenWrt, but it would be realistic to get it working for you
<slh>
that is already very borderline in terms of (not-) being sensible, as soldering iron, equipment, serial console and spi-nor flasher would set you back ~25-40 bucks, even for the most crappy stuff
<slh>
but it would 'work'
<slh>
replacing/ extending the RAM is not sensible
<slh>
and often there are pretty decent devices on the various used markets starting around 5-10 EUR, including brandnew ones starting around 25-20 EUR
<slh>
heck, the ax3000t was as low as 27 EUR this year, new, delivered, incl. customs and taxes (not easy to flash and the latest h/w revision isn't quite supported yet, but that's quite different hardware)
<dviola>
heh, yeah that sounds like a fun project to do, except that I don't really trust myself with a soldering iron, too much work
<dviola>
I've been thinking about going archer c7, still need to see what is available on the market here
<slh>
check your local markets first
<dviola>
yep, thanks
<slh>
tl-wdr3600, tl-wdr4300 or archer c7 are still solid devices (the former two only have 8 MB flash, which is getting pretty (too-)tight as well), but I wouldn't buy them anymore - there usually is better for similar prices (but availability and pricing varies massively between countries)
<dviola>
here in brazil it's easy for devices to cost twice or three times more, due to import taxes, etc
<slh>
is buying from aliexpress reasonable in .br?
totkeks has joined #openwrt-devel
<dviola>
I think so, I know people who bought from there, I personally never did, but I will check that out :D
<dviola>
which device would you recommend?
<slh>
e.g. I would expect the ax3000t to be on sale for black friday again, so ~30 EUR (incl. shipping and 19% VAT for me over here) should be possible, read the recent forum posts about it first, as there are difficulties with the latest h/w revisions, but filogic 820 with 2*1.3 GHz ARMv8 and 128 MB flash/ 256 MB RAM is something quite different, for a pretty low price
<slh>
other than that, it depends on what you can get locally for a good price
<slh>
used ipq40xx or ipq806x can be under 20 EUR, as can mt7621a+mt7915DBDC
<dviola>
I'll look into that one, thanks
<slh>
the ax3000t currently (the new h/w revisions, the older ones work just fine) needs some additional work, but it's looking promising (but please, read the details before buying this one)
<dviola>
I will
jakllsch has quit [Quit: BRB]
jakllsch has joined #openwrt-devel
Mangix has quit [Read error: Connection reset by peer]