Mangix has quit [Ping timeout: 480 seconds]
danitool has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
Mangix has joined #openwrt-devel
<dwfreed> Kufat: pastebin the contents of /home/kufat/gits/openwrt/build_dir/target-aarch64_cortex-a53_musl/root-mediatek/usr/lib/opkg/info/acme-common.postinst-pkg ?
<dwfreed> I can tell you part of it, though
<dwfreed> it is not performing actions on the correct path
fda has joined #openwrt-devel
<dwfreed> it needs to be taking into account ${IPKG_INSTROOT} (and since the postinst is written in the makefile, the $ needs to be doubled there)
<Kufat> hmm
<dwfreed> I'm not sure how you're ending up with /etc/init.d/acme called, though
<dwfreed> it has a uci-defaults file, so it should just skip the postinst if IPKG_INSTROOT is set
<Kufat> https://github.com/openwrt/packages/commit/c6960a2bdcd44e51e8652843cf26f8436fac2682 I looked for discussion on the forums, turns out it was being discussed on the offending ocmmit
<Kufat> *commit
<Kufat> so yeah, exactly right. thanks for putting me on the path to figuring out what was happening.
<fda> ubus/libubus.so.20220615 can not be compiled for mips-fritzbox7320 anymore: "lto1: internal compiler error: compiler does not support ZSTD LTO compression". You need a big log ?
<Kufat> ...how did that ever work successfully even before the recent commit?
<Kufat> (talking about the link I pasted, not the issue fda mentioned)
<slh> fda: if you've been building from an unclean checkout/ used it to build OpenWrt before, you may have to clean the toolchain
<fda> slh: it was a new directory 1 h ago
<slh> o.k., there goes my idea ;)
<fda> currently in another directory a build for rpi2 runs, lets see if it happens with that too...
<fda> i dont understand what to do: "Please submit a full bug report, with preprocessed source (by using -freport-bug)."
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
<dwfreed> in that instance I'm not sure that would be useful
<dwfreed> you'd need to have the build log of binutils, I think
<dwfreed> figure out how it ended up with broken zstd LTO
<slh> also run ./scripts/diffconfig.sh maybe you notice a weird config combination
fakuivan has quit [Ping timeout: 480 seconds]
dangole_ has quit [Ping timeout: 480 seconds]
hanetzer has quit [Read error: Connection reset by peer]
hanetzer has joined #openwrt-devel
fakuivan has joined #openwrt-devel
sasa has joined #openwrt-devel
sasa has left #openwrt-devel [#openwrt-devel]
<dhewg> fda: rm -rf .ccache
cbeznea has joined #openwrt-devel
SlimeyX has quit [Read error: Connection reset by peer]
SlimeyX has joined #openwrt-devel
Tapper has joined #openwrt-devel
csrf has joined #openwrt-devel
csrf has quit [Remote host closed the connection]
valku has quit [Remote host closed the connection]
<f00b4r0> djfe: that's ok. They should be autodetected
goliath has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<djfe> f00b4r0: the only thing I thought about was, if they maybe used something like sercomm and moved partitions to counter bad blocks. but I'm not sure whether that even makes sense on NOR flash
<djfe> and if there was maybe a partition that could act as a partition map.
<Znevna> morning
<djfe> anyways if damex encounters any issues again he might want to compare the partitions to a backup to figure out if they start at the same offsets and if some bytes are broken or whatever. Apart from that I have no clue 😅
<djfe> morning :)
<Znevna> what device was he having issues with?
<djfe> mikrotik hex-s
<djfe> he ran dmesg over ssh and the input froze
<damex> Znevna: mikrotik hex-s (nor) and bananapi r3 (emmc) - same issue with something going 'corrupt' after plugging out and plugging in sfp adapter
<damex> djfe: yeah, it froze also when i did cat /etc/config/network
<damex> less /etc/config/network woked though
<djfe> the device has nor flash but still somehow openwrt got corrupted (he says), reinstall fixed it in both cases
<djfe> interesting, but I don't have a mikrotik and don't have much knowledge so I can't really help
<djfe> hopfeully it doesn't happen again
<djfe> if it does happen again, then console output via serial could be interesting
<damex> it is happing (right now) on last snapshot installed on mikrotik hap ac2.
<djfe> was it always happening in snapshot (on kernel 5.15)?
<damex> djfe: banana pi r3 (emmc) is on last snapshot. mikrotik hex-s is on last 22.03 release
<damex> only reason i use snapshot on hap ac2 is dsa ;)
<damex> and banana pi r3 is not supported on any actual release
<damex> any should i do before i am reflashing hap ac2 back to stock -> openwrt ?
<djfe> backing up partitions is probably not possible either on the hap ac2, is it?
<djfe> it probably freezes when you run "dd" or later when you try to transfer via scp
<djfe> you could try hexdumping the first x bytes though
<djfe> about sfp: openwrt doesn't support that, yet. Or does it?
<djfe> hexdump -v -n 15 -e '/1 "%02x "' /dev/mtdX
<djfe> n -> 15 Bytes
<djfe> maybe run that for the kernel partition (dunno which mtd number that is)
<djfe> that's cool. and export?
* ukleinek points out that directly writing to /dev/mtdX is different to writing to an ordinary block device
<djfe> but the command is reading
<damex> djfe: 01 00 00 00 01 00 00 00 ff ff 6b 65 72 6e 65
<ukleinek> ah indeed
<djfe> would you still choose mtdblock?
<ukleinek> djfe: I'm unsure if reading can have strange effect, soo.
<ukleinek> s/soo/too/
<djfe> damex: write that down maybe/or save the full partitions and somehow compare if they look the same after a reinstall
<ukleinek> if you don't hit bad blocks (which is given as it's NOR IIUC) it should be fine.
<damex> ha, i just saved mtd partitions to /tmp and transfer freeze over ssh
<djfe> dang
<djfe> ukleinek: thx for pointing this stuff out.
<djfe> I still have a lot to learn here
<ukleinek> djfe: if the mtd isn't idle it might matter. The kernel might switch the NOR into another mode (e.g. to write something) and then reading from mtd might result in strange things
<damex> 589312 bytes (589 kB, 576 KiB) copied, 141.713 s, 4.2 kB/s
<damex> so some flash partition/offsets become super slow to read
<damex> beyond usable
<damex> is there something like fstrim ?
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<mrkiko> damex: probably not; whatk ind of flash is that?
goliath has quit [Quit: SIGSEGV]
<damex> mrkiko: W25Q128JVSM - nor 16mb
<mrkiko> damex: definitely no fstrim here, this is raw flash
<mrkiko> damex: if possible, you should not be writing to it very often
<damex> mrkiko: i don't specifically write to that flash. install openwrt, configure and sometime go over for adjustments. no extra services or anything this time
<damex> not even snmpd ;)
<damex> actually it didn't work for hap ac2 - i reinstalled openwrt and it still freeze ._.
<Znevna> my hEX has an uptime of 76 days
<Znevna> no issues
<Znevna> kernel 5.15.82
<f00b4r0> damex: define freeze? I don't see the relation between mtd and having ssh hang when issuing "dmesg"
<damex> f00b4r0: ot constantly lose i/o capability
<damex> freezong on fopen
<damex> 'freezing' on fopen
<Znevna> a bad chip isn't unheard of :P
<f00b4r0> although rare on SPI NOR
<f00b4r0> unless you *really* hammered it
<damex> f00b4r0: i didn't write much on it over last two years owning device
<damex> it was a dumb ap with the same config between upgrades
<damex> changed addressing few times but that's it
<f00b4r0> damex: have you tried booting initramfs and checking if you experience the same problem (this would rule out mtd)
<damex> f00b4r0: sure, it does not seem to be happening on initramfs
<f00b4r0> k. Last thing you could try is flashing say 22.03. If it happens there too then odds of your flash being toast are high
<f00b4r0> use standard image from downloads.openwrt.org
<f00b4r0> just to be sure you're using something "known working"
<damex> f00b4r0: sure, i just redid router 6.49.7 (last 6.x release) revert -> boot 23.03 initramfs -> seem to work sell and does not freeze
<f00b4r0> ok. Try flashing 22.03 and check if it works from the flashed image
<damex> well, some configuration is needed to make it works or not but sure
<f00b4r0> what do you mean "some configuration is needed"?
<damex> f00b4r0: i notice that it is repeatable on naked openwrt image but sometime it is not when i lets say change ip address and reboot host
<f00b4r0> ah. That does hint at flash problem.
<f00b4r0> what I'm curious is whether you can reproduce in 22.03. Otherwise it could be a kernel problem in current snapshot
<damex> jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 jffs2_build_filesystem(): erasing all blocks after the end marker...
<damex> is that actually do maintenance similar to what fstrim does?
<f00b4r0> no that's a one shot at first boot after flash
<damex> f00b4r0: repeated on 23.03
<damex> flashing naked image is fine. adjust ip address -> reboot -> ssh after reboot and run dmesg -> input freeze
<damex> if i try the same multiple times - sometime dmesg runs fine
<fda> i've now build additionla images for e8450, repeater1200 and raspbery
<fda> all failed to build dropbear :)
<fda> bad thing is that by defaul no logs where saved :(
<fda> for freetz i've done this: when building quiet, the logs go to a temp file. the build of every package flushes it. but when there is an error, this file is shown. maybe an idea for openwrt...
danitool has joined #openwrt-devel
<fda> https://pastebin.com/5vQpe4r6 - make-quiet: dropbear fails - additional make-verbose ubus fails
<damex> oh so it didn't reinstall routeros properly before... so mikrotik tool actually did fail ;/
<damex> i didn't check anything - just reinstall routeros and flash openwrt after
<fda> does the build system matter? its fedora.
<fda> so the "lto1: internal compiler error: compiler does not support ZSTD LTO compression" error is not only for avm7320 but for all devices
<PaulFertser> fda: probably you built toolchain with LTO not enabled in .config, and then enabled it?
<PaulFertser> Doesn't seem to depend on the host system.
<damex> actually reformat for hex-s didn't help :( problem is back
<fda> PaulFertser: i build 1x / month a new image for all my devices. this error did not exist 4 weeks ago for me, https://github.com/openwrt/openwrt/issues/10832 is 6 months old
<fda> so ill try the 2 commits from https://github.com/dhewg/openwrt/commits/toolchain but it could take some time to rebuild all again
robimarko has joined #openwrt-devel
dangole_ has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
<f00b4r0> damex: your flash is very likely toast.
minimal has joined #openwrt-devel
goliath has joined #openwrt-devel
xes_ has joined #openwrt-devel
goliath_ has joined #openwrt-devel
goliath_ has quit [Remote host closed the connection]
xes has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
PaulFertser has quit [Read error: Connection reset by peer]
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
<danitool> hi, can "compatible" strings modified at runtime?
<danitool> I ask because I wasn't able to find this one anywhere
<robimarko> That is normal, that is just PCI ID
<danitool> thanks, I'll search documentation about this use
dangole_ has quit [Ping timeout: 480 seconds]
isak has quit [Remote host closed the connection]
xutaxkamay has quit [Read error: Connection reset by peer]
xutaxkamay has joined #openwrt-devel
xutaxkamay_ has joined #openwrt-devel
xutaxkamay has quit [Read error: No route to host]
xutaxkamay_ is now known as xutaxkamay
xutaxkamay has quit []
xutaxkamay has joined #openwrt-devel
johnf has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
johnf has joined #openwrt-devel
minimal has quit [Quit: Leaving]
isak has joined #openwrt-devel
<f00b4r0> so it seems client of mine has been hit by https://forum.openwrt.org/t/timeout-waiting-for-pado-packets-until-reboot/101515/1 on 21.02. Looks like heisenbug that nobody managed to track down, *sigh*
<fda> pppoe is annoying... if the connection gets disconncted, it is not possible to stop it and all the pado messages flood the syslog ^^
<fda> btw, have you an avm modem? its a known bug that lan ports get disabled ("to save energy crap") and are not able to be awaken again
<fda> manual fix: remove the cable und plug it in again
<fda> if it helps, disable saving of 0,00000000000001 per year
f00b4r0 has quit [Remote host closed the connection]
f00b4r0 has joined #openwrt-devel
f00b4r0 has quit [Remote host closed the connection]
f00b4r0 has joined #openwrt-devel
djfe has quit [Ping timeout: 480 seconds]
djfe has joined #openwrt-devel
<fda> how could https://github.com/openwrt/openwrt/issues/10832 be reopened? with the 2 commits mentioned there i was able to build 4 devices which did not work without
djfe_ has joined #openwrt-devel
djfe has quit [Ping timeout: 480 seconds]
<Znevna> f00b4r0: it just looks like a dead wan port
<f00b4r0> Znevna: I doubt a dead wan port would occur immediately after boot and go away after the next one though
<Znevna> dead as in software dead
<f00b4r0> same remark :)
<Znevna> >.>
<Znevna> same device?
dangole_ has joined #openwrt-devel
<f00b4r0> no
minimal has joined #openwrt-devel
<Znevna> I never encountered something similar
<PaulFertser> I once had an ethernet port integrated in a desktop motherboard suddenly not working at all, no link etc. Rebooting didn't help. Power-cycling did. Never again. A latch-up event probably?
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest6492
floof58 has joined #openwrt-devel
Guest6492 has quit [Ping timeout: 480 seconds]
dansan has quit []
dansan has joined #openwrt-devel
<damex> mikrotik devices have capability to 'overclock' - is it applicable on bootloader or it is routeros thing? let's say i enable >716Mhz on mikrotik hap ac2 - would it persist on openwrt too?
<robimarko> You can overclock it via OpenWrt as well by adding an OPP
Mangix has quit [Ping timeout: 480 seconds]
<robimarko> Choosing anything in RouterBoot wont apply on OpenWrt as Linux only scales on the OPP table
Borromini has joined #openwrt-devel
rua1 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
bluew has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
djfe_ is now known as djfe
Ansuel has joined #openwrt-devel
<Ansuel> guys i need a hint for the ath bdf directory...
<Ansuel> was thinking ath-bdf ?
<karlp> what's bdf?
<stintel> one of the many qca idiocies :)
<Ansuel> board data file
<Ansuel> think i will create repo in /firmware/ath
<Ansuel> seems patching
<Ansuel> matching*
<Ansuel> (they are calibration bin that ath10k and ath11k loads to correctly int on the board)
hanetzer2 has quit [Quit: WeeChat 3.8]
hanetzer has joined #openwrt-devel
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
cbeznea has quit [Ping timeout: 480 seconds]
<owrt-2203-builds> Build [#239](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/6/builds/239) of `mpc85xx/p1020` completed successfully.
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
fda- has quit [Ping timeout: 480 seconds]
robimarko has quit [Quit: Leaving]
fda has joined #openwrt-devel
cmonroe has joined #openwrt-devel
Mathew has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest6506
srslypascal has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
Guest6506 has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]