**** BEGIN LOGGING AT Sun Nov 29 02:59:57 2020
Nov 29 03:14:53 <russell--> the gcc version checks are brittle when bisecting
Nov 29 03:42:31 <mangix> philipp64: https://github.com/openwrt/packages/issues/14044#issuecomment-735209055
Nov 29 04:01:15 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 97.4% packages reproducible in our current test framework.)
Nov 29 05:37:25 <russell--> hmm. okay, that's interesting. in a very sparse configuration, "used" drifts up from about 11MB to 17MB and stabilizes. on traffic through the wlan0+eth0 bridge, used snaps back to 11MB-ish. that looks normal and non-problematic.
Nov 29 06:41:57 <mangix> I wonder how many people actually run ldd on their devices...
Nov 29 06:42:36 <mangix> libbldid-tiny and libvaludate .so are broken
Nov 29 08:39:27 <mangix> interesting... https://www.phoronix.com/scan.php?page=news_item&px=Linux-MUSE-MTD-Development
Nov 29 11:07:19 <damex> i notice that mikrotik rb750gr3 and rb760igs with last snapshot does not boot afte sysupgrade.  got two of them for testing. they're on 6.47.8 routeros/routerboot and it boots fine to ram but fails doing so from nand it is indefinitely bootlooping
Nov 29 11:11:24 <damex> tried with 6.46. 3 factory bootloader (backup bootloader that you can not change) and it is the same.  seems like something changed and broke device support.
Nov 29 11:28:16 <f00b4r0> damex: do you have serial?
Nov 29 11:28:26 <f00b4r0> damex: did you try sysupgrading from booted initramfs?
Nov 29 11:45:04 <damex> f00b4r0: sadly no serial here.  yes, i tried sysupgrading from booted initramfs.  booting initramfs works fine. sysupgrade triggering reboot and then device bootloops
Nov 29 11:46:31 <f00b4r0> without serial it's gonna be hard to investigate. The most recent change to these device is the switch to zboot, in 254f514
Nov 29 11:46:57 <f00b4r0> ha
Nov 29 11:46:58 <f00b4r0> wait a sec
Nov 29 11:47:00 <f00b4r0> https://github.com/openwrt/openwrt/pull/3108#issuecomment-735380738
Nov 29 11:47:06 <f00b4r0> hmm no
Nov 29 11:47:11 <f00b4r0> different platform
Nov 29 11:47:21 <f00b4r0> actually, maybe the same problem.
Nov 29 11:47:34 <f00b4r0> when you boot from initramfs, can you run "mtd erase firmware" before sysupgrading?
Nov 29 11:49:26 <damex> f00b4r0: sure, i can try that.  so i will do the same. boot openwrt to ram using reset button (bootp using dnsmasq) -> scp new firmware -> run mtd erase firmware and run sysupgrade after. that's all?
Nov 29 11:49:37 <f00b4r0> yup
Nov 29 11:50:15 <f00b4r0> if that doesn't work, the next potential culprit is 254f514, although I'm unclear how this would affect sysupgrade
Nov 29 12:01:49 <damex> f00b4r0: yeah, that's it.  i did 'mtd erase firmware' and then run sysupgrade. now when router reboots - it can come back up booted from nand
Nov 29 12:02:01 <f00b4r0> ok
Nov 29 12:02:12 <f00b4r0> so the problem lies with the removal of platform_pre_upgrade()
Nov 29 12:02:17 <f00b4r0> and I don't know how to address that
Nov 29 12:03:04 <damex> add step to sysupgrade process?
Nov 29 12:03:17 <f00b4r0> are you @damex on GH?
Nov 29 12:03:23 <damex> f00b4r0: yeah
Nov 29 12:03:27 <f00b4r0> I'm going to quote you on the reply
Nov 29 12:03:32 <f00b4r0> s/quote/mention/
Nov 29 12:23:59 <tmn505> damex: if soldering is no issue You can enable UART in similar fashion as described here: https://forum.openwrt.org/t/mikrotik-cap-ac-support/57828/5. I did that on rb911l.
Nov 29 12:31:11 <damex> tmn505: thanks, i hope that this devices could stay closed up and won't need header to be soldered there (since we already found out what is the current issue) :)
Nov 29 12:46:22 <russell--> anybody want to hazard a guess why i'd see memory usage rocket upwards when an ethernet, wlan0 and batman-adv bat0 interface are together in a bridge to the point of OOM'ing on a 32MB ubnt bullet m?
Nov 29 12:51:50 <Hauke> russell--: did you run netif in valgrind?
Nov 29 12:52:18 <russell--> no, but thanks for reminding me
Nov 29 13:03:44 <mangix> exit
Nov 29 13:08:05 <russell--> "Your program will run much slower (eg. 20 to 30 times) than normal, and use a lot more memory." the last part might be a problem on this device
Nov 29 13:08:45 * russell-- considers trying to duplicate the problem on different hardware with more memory
Nov 29 13:10:03 <dorf> just in need of a widely available by default linux font now (with multi-weight support) and I think we can put the fonts issue to bed.
Nov 29 13:10:27 <dorf> I though DejaVu Sans was it, but sadly it doesn't come with a semibold weight. :|
Nov 29 13:12:10 <ldir-> here's a fun one - I've just managed to build & flash an image without procd onto a system.  Needless to say it doesn't get to a usable state.  I'm left in shell with a default config.
Nov 29 13:12:25 <ldir-> any ideas on recovery?
Nov 29 13:13:41 <PaulFertser> ldir-: shell on serial? And you want to flash from it rather than use the bootloader?
Nov 29 13:14:28 <ldir-> shell on serial - I did a sysupgrade with an image that I doesn't include procd (don't ask)
Nov 29 13:14:52 <ldir-> no procd = eventually runs a shell as the init process.
Nov 29 13:15:00 <PaulFertser> ldir-: I mean probably the easier option would be to use bootloader facilities to load an initramfs image or to flash directly.
Nov 29 13:16:18 <PaulFertser> ldir-: or you can mount tmpfs manually, create ssh keys there, run dropbear manually, scp the sysupgraded file and then "mtd write firmware" (if that's a device with regular NOR flash). But that sounds more complicated than recovering via the bootloader.
Nov 29 13:18:32 <ldir-> how to 'mount tmpfs manuall'
Nov 29 13:18:43 <ldir-> this is an apu2 btw
Nov 29 13:19:01 <ldir-> and I've really f***** it!
Nov 29 13:22:20 <PaulFertser> ldir-: well, something like "mount -t tmpfs none /tmp"
Nov 29 13:24:52 <ldir-> ok, I now have a writable tmp filesystem
Nov 29 13:25:40 <ldir-> is there any way I can extract the backup saved as part of the sysupgrade script ?
Nov 29 13:34:05 <PaulFertser> ldir-: yes, you can try "mount -t jffs2 /dev/mtd<whatever rootfs_data is in /proc/mtd> /tmp/jffs2"
Nov 29 13:34:11 <PaulFertser> And you should get a tar file there.
Nov 29 13:41:16 <blogic> ldir-: yes
Nov 29 13:41:44 <blogic> sysupgrade -b <file>
Nov 29 13:49:36 <ldir-> blogic: that will create a tar archive of the current system - I want to extract the tar archive that intheory is waiting as part of an incomplete sysupgrade process
Nov 29 13:49:37 <ldir-> PaulFertser: unfortunately I've nothing in /dev
Nov 29 14:17:12 <PaulFertser> ldir-: you can use mknod to manually create the devnode.
Nov 29 14:18:05 <PaulFertser> ldir-: for mtd5 it's "mknod mtd5 c 90 10"
Nov 29 14:42:31 <russell--> ldir: what kind of storage?
Nov 29 14:42:50 <russell--> apu2 could be sd card or msata
Nov 29 14:43:26 <russell--> also, you can usually boot off of usb
Nov 29 14:44:56 <russell--> extract storage media, read/write on real computer, plug storage back in.
Nov 29 14:47:26 <russell--> ldir-: ^^
Nov 29 15:02:56 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 97.4% packages reproducible in our current test framework.)
Nov 29 15:57:30 <ldir-> Sorry for delay - had to go to work.  the apu problem will have to wait for my return in the morning.
Nov 29 15:59:24 <ldir-> russell--: the boot vol is msata - I think booting off usb is the way forward
Nov 29 16:04:08 <stintel> ldir-: is this an ext4 image on your apu2 ?
Nov 29 16:42:02 <ldir-> stintel: yes
Nov 29 16:43:58 <stintel> ldir: sysupgrade is broken there as the hack to merge /etc/passwd and friends doesn't work, so if you go from a version running ubusd as root to a version running ubusd as ubus, the user is missing and you're fucked
Nov 29 16:48:28 <ldir-> Ah ok, that's not ideal!
Nov 29 16:51:43 <stintel> ldir-: what bother me most is that who introduced it knows it, and dismissed it as "ext4 is development, use squashfs if you want working sysupgrade"
Nov 29 16:52:16 <ldir-> Ouch - it really should be fs agnostic.
Nov 29 16:52:52 <ldir-> And I don't think I am using ext4 - but I need latest build to finish to look
Nov 29 16:53:25 <ldir-> no, sorry it *is* squashfs. x86/64/openwrt-x86-64-generic-squashfs-combined.img.gz
Nov 29 16:54:01 <ldir-> I just managed to build and 'flash' an image without 'procd' - which is a very silly thing to acheive.
Nov 29 16:55:16 <ldir-> I was playing with jail & seccomp
Nov 29 17:14:27 <jow> stintel: I think that statement should be corrected
Nov 29 17:14:45 <jow> somehow dangole seemed to frame ext4 as some kind of development/debug build
Nov 29 17:15:05 <jow> while it is perfectly fine to run plain ext4
Nov 29 17:15:19 <jow> and we should keep the door open for normal, non-overlayfs deployments
Nov 29 17:18:32 <stintel> this was my comment on github
Nov 29 17:18:55 <jow> ack
Nov 29 17:25:19 <Borromini> i think a lot of people are running ext4 builds on x86/64 hardware e.g.
Nov 29 17:26:59 <philipp64> mangix: thanks, trying it now.
Nov 29 18:27:25 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Nov 29 19:32:07 <dorf> is this a known issue with SQM, and is there any sense ensuring support is compiled into the kernel? https://stackoverflow.com/questions/4803069/rtnetlink-answers-no-such-file-or-directory
Nov 29 19:38:16 <ldir-> thinking about my problem - If I boot off a usb image and then use dd to write a 'squasfs-rootfs' image to /dev/sda1 that should preserve my partitioning and other filesystems - I think?
Nov 29 21:43:07 <Tapper> dorf That link is over 9 years old!
**** ENDING LOGGING AT Mon Nov 30 03:00:00 2020