<fda>
slh: removing the file from /overlay/upper/ + reboot works, it does not appear again in /overlay/upper/ - but "sysupgrade -l (--list-backup)" does still list it. so the unchanged file is in the settings-backup
<fda>
now restoring such a backups seems to create it in /overlay/upper
robimarko has quit [Remote host closed the connection]
<Znevna>
kek
robimarko has joined #openwrt-devel
<jow>
rmilecki: yeah, would be good to figure out the cause
<jow>
rmilecki: can you try to produce a core dump?
<mrkiko>
robimarko: yesterday I was looking at the DTS currently in master or the GL-AP1300 which is currently disabled, and for which a PR with DSA conversion is pending, as you know. Looking at master, where can I find in the DTS where MAC addresses are read from? I also tried looking at the dts before your commit 27b441cbaf426edffa6b90b06bb356528203b33a
<rmilecki>
jow: that happened for me during the first boot
<rmilecki>
jow: and network didn't work
<jow>
rmilecki: not reproducible anymore now?
<rmilecki>
ifconfig, swconfig, brctl looked ok
<rmilecki>
network worked after /etc/init.d/network restart
<jow>
the above would've only affected firewall
<rmilecki>
after reboot network works out of the box and I don't see that SIBSEGV
<jow>
does the segfault reappear after firstboot?
<rmilecki>
jow: do you know what command could be executed during first boot that possibly cause that
<rmilecki>
jow: i'm testing firstboot & reboot now
<jow>
my hunch is that the firewall is started very early by hotplug while something is not yet initialized/present
<robimarko>
mrkiko: They dont have to be set via DTS, it could be from the userspace or maybe it was just set by bootloader via aliases
<mrkiko>
robimarko: I know, but I couldn't find the info I was looking for even in the user-space base-files part. I don't know about bootloader. But I guess if it was set via the bootloader, the dsa conversion would not have needed to do it the way it does
<rmilecki>
jow: that souns possible, since it's an old device, slow CPU, things take a lot of time to boot
<rmilecki>
jow: uh, i didn't reproduce it on firstboot + reboot
<rmilecki>
jow: i'll try few more times later, have to run now
<mrkiko>
jow: could it be a kind somewhat OOM condition?
<robimarko>
mrkiko: Its hard for me to guess, but what is the issue?
<fda->
jow: im testing the change on my devices but i think someone with much openwrt experience should check it too. also if additional files should be excluded
f00b4r0 has quit [Quit: Leaving]
f00b4r0 has joined #openwrt-devel
danitool has joined #openwrt-devel
<mrkiko>
robimarko: simply I wanted to learn something - and so understand where the mac addresses infos are set, also to understand how the info was extracted during DSA conversion so I might have some ideas of what to search should one day I try to do something like that
<mrkiko>
robimarko: right now, wan and lan for gl-ap1300 have the same mac after DSA conversion with pr #10909
<robimarko>
mrkiko: So, I assume that its currently set via the default ethernet0 alias
<robimarko>
It should probably be switched to NVMEM or at least alias for the second port needs to be set
<mrkiko>
robimarko: I can't see that alias defined
<robimarko>
mrkiko: Its not
rua has quit [Quit: Leaving.]
<mrkiko>
ok
<mrkiko>
but you gave ma a pointer, so ... thanks
<robimarko>
Ideally, it should be switched to NVMEM if possible
<robimarko>
To make it completely independent from bootloaders
<mrkiko>
robimarko: as far as I can tell, this has been done in DSA conversion by nick[m]12
<mrkiko>
robimarko: but I was curious, for knowledge sake, to understand from where nick[m]12 was able to extract that information from
<robimarko>
mrkiko: You dump the ART
<robimarko>
And compare the MACs at the start to the stock
<robimarko>
Usually its 0x0, 0x6 and so on
<mrkiko>
robimarko: so doign DSA conversion without a device and ART dump is complicated
<robimarko>
Kind of
xutaxkamay has quit [Ping timeout: 480 seconds]
xutaxkamay has joined #openwrt-devel
rua has joined #openwrt-devel
<stintel>
neggles: apparently there's 4 :P
<nbd>
dhewg: ping
<dhewg>
pong
<xutaxkamay>
pong
<xutaxkamay>
:-)
<nbd>
dhewg: what's the exact issue that you're seeing?
<nbd>
(regarding the mt76 bump)
<nbd>
and on which device
<dhewg>
I'm not 100% sure it's the bump yet, I just suspect it so far. But the scanning doesn't work sometimes on my MT7921AU
<dhewg>
well, with iwinfo, iw scans just fine
<dhewg>
but iwinfo without any of the patches from the last months fails too, so it's not related to those
<dhewg>
I'm pretty sure iwinfo scanning worked recently
<dhewg>
when attempting it, it takes a while, but you'll just get "No scan results"
<dhewg>
but sometimes it works, and on the next run right after that it doesn't again
<nbd>
odd
<dhewg>
yeah, but as I said, it may be iwinfo doing stupid things
<dhewg>
with the tmp interface and whatnot
<nbd>
if you find that it is the bump, please do a git bisect on the mt76 tree
guidosarducci_ has joined #openwrt-devel
valku has joined #openwrt-devel
<dhewg>
I may try an evening, by now it's in business use
guidosarducci has quit [Ping timeout: 480 seconds]
tom- has joined #openwrt-devel
MAbeeTT has joined #openwrt-devel
gladiac is now known as Guest4009
gladiac has joined #openwrt-devel
MAbeeTT5 has quit [Ping timeout: 480 seconds]
Guest4009 has quit [Ping timeout: 480 seconds]
xback has joined #openwrt-devel
<xback>
o/
minimal has joined #openwrt-devel
<mrkiko>
rmilecki: ping
<rmilecki>
mrkiko: pong
<mrkiko>
rmilecki: I am going to try to hackup up a tg789vac I guess, not sure about hw revision yet. The bootloader doesn't allow for interruption at all as far as I can tell. But I have access to flash with a SPI programmer. Is there any way to run u-boot on that?
<mrkiko>
rmilecki: when I say "on that" I mean - on a target like that
<rmilecki>
mrkiko: that is bcm63xx which i don't really have any experience with
<rmilecki>
mrkiko: Broadcom has bcmbca "family" which covers BCM4908 and bcm63xx
<rmilecki>
mrkiko: so I think my U-Boot repository may work for you
<rmilecki>
mrkiko: but I can't provide any real further help for this device, sorry
<mrkiko>
rmilecki: no problem - I hope with flash access I have at least some chances of trying things out
<rmilecki>
mrkiko: what bootloader does it come with? cfe/
<mrkiko>
rmilecki: I can't really tell right now - I'll receive the device within some days with a flash programmer connected
<rmilecki>
mrkiko: ping me and paste boot log for me please :)
<mrkiko>
rmilecki: looking at the bootlogs on the wiki I am under the impression it has multiple bootloaders, one of them to be an u-boot
<rmilecki>
mrkiko: this repo I made for bcm4908 but it actually contains bcmbca code, so it should cover bcm63xx too: https://git.openwrt.org/?p=project/bcm63xx/u-boot.git;a=shortlog;h=refs/heads/generic
<karlp>
stintel: when you say you use the sysupgrade image for the olinuxino-a64, what image do you mean exactrly? there's no sysupgrade image made for that board? and no factory image either?
<karlp>
there's sdcard iamges, but you can't use those for sysupgrade?
<rmilecki>
bcm63158 is there and I think bcm63168 may be similar to bcm63158
<rmilecki>
mrkiko: oh, we have some BCM63168 devices already: ls -l target/linux/bcm63xx/dts/*63168*
<stintel>
karlp: I use the sdcard image for sysupgrade
<stintel>
"it works"
<karlp>
I... never would have even _tried_ doing that...
<mrkiko>
rmilecki: that's good to know. That said, seeing some question u-bot asks in the ocnfig, I'm scared :D
<stintel>
karlp: funny thing is the sdcard image works for factory and sysupgrade, on sdcard or eMMC :P
<stintel>
so it should probably be renamed to combined-combined :D
<karlp>
well "factory" to me implies "using whatever was on the hardware when it shipped" whcih is pretty openeded on some of these boards.
<mrkiko>
karlp: if you can switch over to a more efficient format, for sure it 's a great thing
<karlp>
I know I cna _install_ the sdcard img to emmc or sdcard, you just get the plain sd card layout, but I had zero idea that sysupgrade could use the sdcard img files _as is_
<mrkiko>
rmilecki: will in the end I need to generate a RAM image and chainload via a different bootloader, or can you boot directly from u-boot itself?
<rmilecki>
mrkiko: no idea about bcm63xx devices
<rmilecki>
mrkiko: BCM4908 has full U-Boot which are 3 stages
srslypascal has joined #openwrt-devel
<rmilecki>
U-Boot SPL, U-Boot TPL, U-Boot
<mrkiko>
rmilecki: ok, thanks
<tmn505>
karlp: well, the "secret sauce" is always in /lib/upgrade/platform.sh, so checking that should give a hint
<karlp>
yes.... open source....
<karlp>
that' sequence of sysupgrade the shell script, creating archivesand using archives and passing through ubus and a stage2 is..... yes. open source, obviously I just git gud......
<tmn505>
I pointed to platform specific procedures, You shouldn't bother about everything else, unless there's very speciffic issue
srslypascal is now known as Guest4017
srslypascal has joined #openwrt-devel
<nick[m]12>
mrkiko: hey, you mentioned me. could you again say why? sry, I am currently ill and just laying around in my bed and try to get healthy again
srslypascal has quit [Remote host closed the connection]
<mrkiko>
nick[m]12: no problem ... sorry for disturbing - and it was nothing bad. Just was trying to understand how you extracted the information about where to extract MAC addresses in the dsa conversion of the gl-ap1300
<nick[m]12>
mrkiko: I just looked at other devices and assumed there is a correlation. that's why I asked if the mac is correct
<nick[m]12>
otherwise you have to look at the art partition yourself
<mrkiko>
nick[m]12: thanks; yeah, as I said - it is for sake of learning
<nick[m]12>
mrkiko: your welcome. :)
<mrkiko>
nick[m]12: get healty soon!!
<nick[m]12>
thanks!
Guest4017 has quit [Ping timeout: 480 seconds]
<nick[m]12>
hauke: If you need any help doing the 23.xx release, just tell me. I am looking forward to a new stable. :) E.g. I can write an announcement text or whatever, or fill the release goal page...