**** BEGIN LOGGING AT Mon Mar 08 02:59:57 2021 Mar 08 08:23:33 is stdowa a bot? do other package maintainers also get e-mail as soon as there is a new upstream version available for packages they maintain? Mar 08 08:24:07 dont get me wrong, i appreciate the reminders ... just wondering because the mails seem generic Mar 08 08:24:53 A bot created and maintained by a living person :) Mar 08 08:25:09 yes ok i should say a script Mar 08 08:28:06 o well that was me hoping anyone actually cared :P Mar 08 08:32:26 I can't believe I had to do a TFTP recovery of the RM2100. Mar 08 08:35:56 grift: programmers care by creating caring programs :) Mar 08 08:53:20 rsalvaterra: how so? what happened? Mar 08 08:54:43 Borromini: Updated the image, no DHCP. Defined a static IP, tried to log in… connection reset by peer. Fail-safe boot, static IP, tried to log in again… connection reset by peer. Mar 08 08:55:58 (╯°□°)╯︵ ┻━┻ Mar 08 08:57:46 rsalvaterra: tried IPv6 link local? Mar 08 08:59:10 jow: No, but the router itself was accessible, responded to ping. But for some reason dropbear f****d right off. Mar 08 08:59:23 ah ok Mar 08 09:00:52 jow: This all started because current master stopped reading the mt76 EEPROM. Mar 08 09:01:58 I was testing master 5.10 and I noticed the problem (invalid MAC addresses and basically unusable Wi-Fi due to missing caldata). Mar 08 09:02:43 "Oh, 5.10 needs more baking on ramips, let's revert to 5.4", I thought. Mar 08 09:03:02 I was pretty much shocked to discover I started having the same problem with 5.4. Mar 08 09:06:47 I was going to try dangole's suggestion of matching the devices in the device tree by PCI ID, not driver name (https://paste.debian.net/1188361/), but couldn't really test it. Mar 08 09:07:13 (By the way, matching by driver name is crazy.) Mar 08 09:17:28 grift: stdowa is a person, he uses > Debian's devscripts' uscan utility, ~3000 watch files and a few ugly shell scripts Mar 08 09:18:07 he's in here as swalker Mar 08 09:20:27 ok, thanks. so I dont have to bother replying to those mails. good to know. Mar 08 09:26:40 jow: I rewrote the attendedsysupgrade app in javascript but it still misses multiple of the smart LuCI concepts. I'd appreciate your help on that a lot! https://github.com/openwrt/luci/pull/4145 Mar 08 09:40:46 rsalvaterra: i assume still the same behaviour after tftp'ing a factory image? Mar 08 09:41:54 Borromini: Haven't reinstalled OpenWrt yet, $dayjob takes most of the time. :) Mar 08 09:42:36 There is another awkwardness I'm seeing in the MT7621 subtarget, though… Mar 08 09:43:23 … why in heck do we have the HSDMA engine driver as a kernel module (kmod-hsdma-mtk), not even selected by default? Is there any problem with it? Mar 08 09:44:13 I mean, the thing has its device node specified in the topmost device tree (mt7621.dtsi), so basically everything with a MT7621 SoC contains it. Mar 08 09:44:57 And the kernel module is already limited to TARGET_ramips_mt7621. Why not just enabled it by default in the mt7621 kconfigs and be done with it? Mar 08 09:48:05 I only found out about the DMA engine because I was actually reading the datasheet. Mar 08 09:48:24 are you running with the wireguard pr from lipnitsk? Mar 08 09:48:39 he also tacked on a driver rename patch for hsdma-mtk i think Mar 08 09:49:21 Borromini: Yes, the WireGuard stuff hasn't caused me any problems at all. Mar 08 09:49:44 rsalvaterra: no, just asking because it has the rename. no problems with wg here either Mar 08 09:51:27 Yeah, but it was just a simple rename, shouldn't cause any issues: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/staging/mt7621-dma?h=linux-5.4.y&id=d69583a2c1b38396c9bdcdffa3f3667cff12b0b8 Mar 08 09:51:38 sorry, i'm on 21.02 myself so i kind of assumed you were as well, but that's a bit preposterous of course Mar 08 09:52:50 Borromini: I'm always on master… #yolo :P Mar 08 09:54:04 But this time I'm going to be more conservative upgrading the RM2100. That EEPROM problem is nasty. Mar 08 09:54:41 haha Mar 08 09:54:50 if it's your main device... yes Mar 08 10:08:13 although i have to admit, i have spare stuff now to test new builds on, and i find myself way too often flashing my production devices first still :P Mar 08 10:27:36 Borromini: I consider all my devices to be "main" (well, except for the TL-WDR3600, which is "configured for holidays" :P). Mar 08 10:28:17 eh? :P Mar 08 10:29:12 ah that reminds me to order https://www.gl-inet.com/products/gl-mt1300/ Mar 08 10:31:31 Borromini: It's configured for connecting through a 4G USB modem, when I'm on holidays, in the south. ;) Mar 08 10:33:05 cool Mar 08 10:33:11 (It can also use an Ethernet connection, since it has a lower metric. I could use mwan3, but it would be overkill.) Mar 08 10:33:16 rsalvaterra: Algarve? :) Mar 08 10:33:32 Borromini: Yep! ;) Mar 08 10:33:35 neat Mar 08 10:33:50 stintel: been eyeing that one as well. but i think i'll get an outdoor AP first. Mar 08 12:20:42 xback: ping Mar 08 13:51:33 Hauke: ping Mar 08 13:53:52 https://blog.doismellburning.co.uk/nobody-likes-naked-pings/ Mar 08 13:55:06 grift: Hm… noted. However, it seemed standard procedure, Everybody Does It™. :/ Mar 08 13:55:24 I'll elaborate, though… Mar 08 13:55:40 i dont, and dango also does not Mar 08 13:55:46 Hauke: I believe this deserves a mac80211 backport… https://patchwork.kernel.org/project/linux-wireless/patch/20210219052607.7323-1-pkshih@realtek.com/ Mar 08 13:56:12 01:46 < dangole> grift: just tried the selinux 3.2 update on my Linksys E8450, everything works like a charm so far Mar 08 13:56:28 thats is a useful ping Mar 08 13:58:47 so.. ladies naked, pings only w/ reason ;) Mar 08 14:00:04 olmari: There, there, now… It's Woman's Day, today. ;) Mar 08 15:12:15 ynezz: Can you teach me how to set up https://gitlab.com/ynezz/openwrt-device-runtime-testing ? I have a container registry, an MR16, a serial cable, a static OpenWrt host with shell access and know how to install gitlab-runner. Mar 08 15:12:20 how's that :^) Mar 08 15:13:24 In exchange, I promise to help you hack on it. I have been blocking the upgrade pipeline for Newport Mesh despite Diane's insistence she get new firmware until I have an automatic testing process in place Mar 08 15:13:37 and you wouldn't want to disappoint an old mesh granny, now would you? Mar 08 15:13:41 Alternatively I can write a check >_> Mar 08 15:14:18 Given that I haven't seen ynezz comment in Mar 08 15:14:33 ... a while, I should probably post on that gitlab page. Mar 08 15:22:27 the gitlab-runner is last step, you need to start with labgrid, automatic provisioning of the device over the serial console Mar 08 15:22:55 you need some kind of power source control as well, relay, wifi socket whatever Mar 08 15:23:31 add your device here https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/blob/master/.testbed/labgrid/default.yaml Mar 08 15:25:11 this is the hardest and most time consuming part Mar 08 15:26:21 follow https://labgrid.readthedocs.io/en/latest/getting_started.html#installation Mar 08 15:29:34 then you can just run simple labgrid wrapper `.gitlab/scripts/testbed-device.py --target $LABGRID_TARGET boot_into shell` where $LABGRID_TARGET is your MR16 target you've added in .testbed/labgrid/default.yaml, for example mr16-initramfs for booting from initramfs or mr16-nor for flashing/booting from NOR flash Mar 08 15:29:46 I'll do that at lunch, drop my work into examples/mr16/README.md, then try to add the instructions somewhere higher in-tree Mar 08 15:29:53 s/drop/document Mar 08 15:30:10 I can add you to that project and you can edit wiki directly if you want Mar 08 15:30:39 Not a huge fan of gitlab wiki ;( happy to migrate the stuff there later once they're in .md's though Mar 08 15:30:50 ok, fine with me Mar 08 15:31:04 then maybe start docs/first-steps.md or such Mar 08 15:31:50 it doesn't matter, the content matters :) Mar 08 16:34:28 dangole: can i get a `mount` and a `ls -alZ /tmp/etc` of that bananapi? something weird going on theres with dnsmasq initscript and /tmp/etc/dnsmasq* Mar 08 16:36:26 dangole: also can you tell me what that /dev/mmcblk0p130 is used for? Mar 08 16:37:45 scratch that last question Mar 08 16:40:13 mmcblk0p130 is the protective MBR covering the BPT partition table Mar 08 16:40:25 yes scratch that question Mar 08 16:41:00 i have a challenging time interpretting what dnsmasq init script does there Mar 08 16:42:09 some of the events reference /var/etc/dnsmasq.conf.cfg01411c and others reference /tmp/etc/dnsmasq.conf.cfg01411c Mar 08 16:42:56 i think it might be moving/renaming stuff accross tmpfs's? Mar 08 16:43:06 weird ... Mar 08 16:44:43 filesystem weirdness is because /dev/mmcblk0p6 isn't mounted when using SELinux because mount_root fails, even in permissive mode Mar 08 16:44:50 (ie. rootfs_overlay is missing) Mar 08 16:44:57 could it be that when dnsmasq init script creates that /var/etc/dnsmasq.conf.* file that /var is not a symlink to /tmp yet and that theres a tmpfs on /var? Mar 08 16:45:11 so why is it failing? Mar 08 16:45:30 if its just a broken symptom than i dont have to address it Mar 08 16:45:43 grift: my bad, i missed to include mkfs.f2fs in the image... Mar 08 16:45:48 i address the other issues Mar 08 16:45:54 heh Mar 08 16:46:08 phew well atleast that explains it Mar 08 16:46:22 was trying to interpret what happened there and didnt add up Mar 08 16:47:44 ok well the bananapi should now also work with the new commit (provided its configured properly) Mar 08 16:48:04 would be real helpful if you could re-test it with updated policy and proper config Mar 08 16:55:42 as for differentiating between the different "partitions" on same storage. not sure if thats worth the trouble as not much can access storage anyway and we have to be conservative with rules, rules are better spent on containing services/system components Mar 08 16:56:18 i noticed that the *full* policy grew over 200KiB so now efficiency comes into play Mar 08 16:59:20 i dont really think one partition is more important than another, for me its pretty simple anyone with access to raw storage can go around selinux. so if a domain has access to raw storage i consider it "trusted" Mar 08 16:59:54 selinux associates labels with security extended attributes and if you can access storage raw, then well no xattrs Mar 08 17:52:26 grift: https://termbin.com/vis2 Mar 08 17:52:43 grift: now with rootfs_data properly mounted, but still some minor issue with mkfs.f2fs Mar 08 18:01:34 dangole: thanks, will process, but its not the full picture (its in enforcing mode) Mar 08 18:05:46 for example hostpad and wpa_supplicant traverse /proc/sys but since its enforcing i dont know where its trying to go Mar 08 18:10:53 netifd (or some script that it runs) seemd to be trying to rm at least the /tmp/run/wpa_supplicant/wlan1 sock file but not sure if it also wants to delete the parent dir Mar 08 18:14:29 grift: once again in permissive mode, full-cycle with mkfs, config-restore and firstboot/jffs2reset: https://termbin.com/ncms Mar 08 18:15:26 also not sure what /etc/init.d/boot wants with "executing" /etc/init.d/{uhttpd,rpcd} i think its related to uci-defaults? Mar 08 18:16:56 right but that still hase mkfs.f2fs issues right because i still see those dnsmasq tmpfs issues Mar 08 18:17:23 ill pick the events that make sense Mar 08 18:17:40 but there seems to be still something wrong with your filesystems there Mar 08 18:22:26 never mind that rcboot restarts uhttpd out of place, that seems to be related to https://github.com/openwrt/luci/blob/master/applications/luci-app-attendedsysupgrade/root/etc/uci-defaults/40_luci-attendedsysupgrade Mar 08 18:22:36 and probably it shound't be doing that in first place Mar 08 18:23:05 jow: do you remember why you added loopback to the interfaces in https://git.openwrt.org/c8a8f8fd ? Mar 08 18:26:20 MIPS switches to RISC-V: https://www.prnewswire.com/news-releases/wave-computing-and-mips-emerge-from-chapter-11-bankruptcy-301237051.html Mar 08 18:26:44 dangole yes i also noticed this: Mar 08 18:27:49 avc: denied { getattr } for pid=2290 comm="sh" path="/etc/uhttpd.crt" dev="overlay" ino=74 scontext=u:r:rcuhttpd.subj tcontext=u:r:file.conffile tclass=file permissive=1 Mar 08 18:27:59 ie /etc/uhttpd.crt is somehow mislabeled Mar 08 18:28:25 that's being newly created here Mar 08 18:29:21 theres no event of it being created ... Mar 08 18:29:26 Hauke: cool Mar 08 18:30:25 estimated shipping date of the hifive unmatched has changed from 11/03 to somewhere june :( Mar 08 18:31:24 grift: and some more https://termbin.com/j237 Mar 08 18:32:00 dangole well about the uhttpd cert Mar 08 18:32:12 the uhttpd init script generates the cert Mar 08 18:32:35 can you rm the cert and let it regenerate it? Mar 08 18:32:48 ie service uhttpd restart && ls -alZ /etc/uhttpd.crt Mar 08 18:33:01 because it should be able to create it with a proper label Mar 08 18:33:08 and for some reason it didnt Mar 08 18:33:30 grift: i think all this havoc is because this luci-app start uhttpd in uci-defaults. it really shouldn't be doing that and i notified the author Mar 08 18:33:37 but the issue is that it seems this system isnt properly configured yet? i mean you said it yourself that theres outstanding issues Mar 08 18:33:47 grift: here again some small things with mount_root and initializing overlay: https://termbin.com/zzcd Mar 08 18:34:38 i addressed what made sense, that dnsmasq stuff in that latest paste doesnt make sense to me Mar 08 18:34:49 apart from that weirdness (of trying to restart uhttpd before the show has even started) everything else works and is configured. 1x AP, 1x STA, WAN, ... Mar 08 18:35:36 most important is just that all that mount_root, config-restore, mount rootfs_data, ... works Mar 08 18:36:03 what is happening here: Mar 08 18:36:05 avc: denied { read } for pid=3307 comm="scp" name="backup.tgz" dev="tmpfs" ino=114 scontext=u:r:dropbear.subj tcontext=u:r:tmp.fs tclass=file permissive=1 Mar 08 18:36:23 so youre scp'ing the backup.tgz from the router? Mar 08 18:36:32 that's me making copying a backup made using 'sysupgrade -b /tmp/backup.tgz' Mar 08 18:37:02 i do that so i can demonstrate the denied messages when doing 'firstboot' Mar 08 18:37:31 so thats legitimate access? ok well i guess that shouldnt be a problem Mar 08 18:38:39 acctually that is a problem ... Mar 08 18:39:02 if we'd take this really serious then we should have something like /tmp/xfer either mounted as separate tmpfs with limited size or using quota, then use that for sysupgrade and in SELinux allow only that for user transfers via scp Mar 08 18:39:07 ok ill let it sink in for a while theres a lot going on in there and some of it just doesnt make sense Mar 08 18:39:47 grift: i guess we'll see what is left after you did the obvious part and if it matters, we'll dig more Mar 08 18:40:09 right Mar 08 18:40:17 for example what is happening here: Mar 08 18:40:20 avc: denied { create } for pid=842 comm="sh" name="sysupgrade.tar" scontext=u:r:mountroot.subj tcontext=u:r:tmp.fs tclass=file permissive=1 Mar 08 18:40:37 so /tmp/sysupgrade.tar is created Mar 08 18:40:48 what did that? Mar 08 18:41:08 this is related to restoring configuration on block devices (ie. mmc) Mar 08 18:43:18 /tmp/sysupgrade.tar is created by 'gzip -cd /dev/mmcblkXpY' (being uninitialized rootfs_data partition carrying the backup in that way). i uncompress it from there instead of copying it because gzip knows the size :) Mar 08 18:44:15 dangole: Found and installed an old r14980 build on the RM2100. So far, so good, I've got the correct MAC addresses, so I assume it read the EEPROM correctly. Mar 08 18:44:20 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 98.0% packages reproducible in our current test framework.) Mar 08 18:45:01 grift: ie. on EFI platforms like x86 and on all the more hacky rasbpi and the like we got a FAT filesystem as 'boot' partition and can use that to rescue config accross sysupgrade. Mar 08 18:45:35 ok and its a fixed name sysupgrade.tar Mar 08 18:45:39 so we can rely on that name Mar 08 18:45:50 grift: on mt7622, where i recently cleaned that up so we don't need any stuff from the 80's (FAT) going on to boot OpenWrt, I made a new way more similar to how it's done on (raw-)flash based devices: simply put a tar.gz into the partition which will later be used for rootfs_data. Mar 08 18:46:00 grift: yes, you can rely on that name Mar 08 18:46:16 grift: it's hard-coded in fstools and base-files Mar 08 18:46:22 k this is what i added from the last pastes so far: https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=2901433f790a30a589326e3f0cb8c7f3ee707886 Mar 08 18:46:46 ill address the sysupgrade.tar from mounroot as well Mar 08 18:47:24 quite a bit of stuff going on ... Mar 08 18:48:02 grift: yes, i was annoyed by all that legacy crap from raspbian creeping into our tree... Mar 08 18:49:00 the thing is that we have to stay sharp here dont want to add policy to support bugs/misconfuration.. better safe than sorry Mar 08 18:49:16 esspecially with that uci-default stuff that went wrong Mar 08 18:49:27 grift: if we got a target with U-Boot 2020.10 built from source for every board there is really no need to introduce filesystems from 40 years ago. Mar 08 18:49:52 grift: so i used that opportunity and re-built the whole bootchain in many ways: Mar 08 18:50:29 grift: 1. embed the rootfs(squashfs) into the uImage.FIT, so bootloader can verify that before starting kernel (which would fail if squashfs is corrupted) Mar 08 18:51:07 dangole: Some devices don't have a public uboot available.. My shield is a RHino MISP64 board with uboot 2013, but no way to update it Mar 08 18:51:34 grift: 2. have a partition parser in Linux to then map the rootfs subimage of that FIT sitting either in Flash or GPT partition into a mountable block device (that's the mmcblk0p6 and mmcblk0p7) Mar 08 18:51:35 at least that I've found.. The OEM went out of business in 2015 and took the source with them Mar 08 18:52:04 and it is "stable"? Mar 08 18:52:15 ie youre done with that work? Mar 08 18:52:17 Grommish: sure, this is not an option on all platforms and the old way to have initrd built-in and squashfs writting arbitrarily into the flash is of course still possible and the default Mar 08 18:52:39 no point is working on policy if the work is not done/stable yet Mar 08 18:53:00 dangole: *nod* I'm sure you all will make it work, I just wanted you to be aware updating uboot isn't an option for everyone :) Mar 08 18:53:12 grift: i'm using that in production and blogic, aparcar and a few others are using all that on the Linksys E8450 (UBI). also the Bananapi R64 eMMC and SDMMC images work in that new way now, and people from the forums there have been using them for 2 weeks now Mar 08 18:53:42 dangole: The current 21.01 snapshot (5th March) is also fine (Linux 5.4.99). Mar 08 18:54:14 grift: ie. i'm not assuming things will change a lot there. some things may move from /lib/upgrade/platform.sh to /lib/upgrade/common.sh or /lib/function* if other platforms start using that way as well Mar 08 18:54:35 rsalvaterra: but current snapshot, even with 5.4 fails? Mar 08 18:56:04 dangole: Didn't go there yet, I'm starting a build from current master with kernel 5.4, but it's a good idea to install the current master snapshot, yes. Mar 08 18:56:08 ok so "mountroot" creates that /tmp/sysupgrade.tar, does it also do any restoring itself? Mar 08 18:56:32 because i suppose we dont see that scenario in the logs (restoring) Mar 08 18:57:01 grift: It shows up in the kmesg when it's restoring, or should Mar 08 18:57:17 grift: 79_move_config Mar 08 18:57:57 (at least, that's what octeon target uses to restore) Mar 08 18:58:29 grift: i'm of course hoping that rockchip, sunxi, bcm27xx, omap, ... will switch as well, also there we are generally building U-Boot from source or it's at least recent enough Mar 08 18:58:38 grift: https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/base-files/lib/preinit/79_move_config Mar 08 18:58:39 Grommish: this is exactly what I got rid of Mar 08 18:59:16 Grommish: take a look on how it's done in target/linux/mediatek/mt7622/base-files Mar 08 18:59:40 (and fstools, which does the restoring part) Mar 08 19:00:10 dangole: Blimey…! Today's master snapshot is fine too. Mar 08 19:00:14 dangole, going through all of this is probably going to require a bit of iteration. i added some rules that should make it a bit less noisy, and if you also ensure that the uhttpd uci-default stuff is fixed then a new run should make things a bit clearer where we stand currently Mar 08 19:01:08 Grommish: This, ie. restoring config from tar.gz in (to-be-formatted, future) rootfs_data without the need of using some platform-specific FAT partition or other hacks can of course be used independently of bootloader support Mar 08 19:02:53 dangole: I am out of my knowledge depths. I just know how it works now :) where the backup is stored on the FAT partition as the tgz and then moved once the block devices come online Mar 08 19:03:05 rsalvaterra: very nice to hear. could that have been related to your local build not being clean? Mar 08 19:03:46 dangole: I'm starting to think so. I started this morning pushing the big red button (make dirclean). Let's see how it goes… Mar 08 19:04:17 dangole: octeon platform.sh if you want to look - https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/base-files/lib/upgrade/platform.sh Mar 08 19:06:12 Grommish: do we build the bootloader from source and/or can we modify the environment to tell it to load FIT directly from partition instead of mounting FAT? Mar 08 19:06:42 https://www.prnewswire.com/news-releases/wave-computing-and-mips-emerge-from-chapter-11-bankruptcy-301237051.html Mar 08 19:06:54 dangole: Nope.. Cavium Marvell SoCs are notorious for no support, and in my case in particular, the issue is compounded by the OEM being long gone Mar 08 19:06:58 "MIPS is developing a new industry-leading standards-based 8th generation architecture, which will be based on the open source RISC-V processor standard." Mar 08 19:07:10 moment of silence for our old friend Mar 08 19:07:53 blogic: "Rise from your grave!" /Altered Beast Mar 08 19:08:19 rsalvaterra: which part of "moment of silence for our old friend" was not clear ? ;-P Mar 08 19:08:26 R.I.P. Mar 08 19:08:33 dangole: real shame Mar 08 19:08:44 Too soon, I guess… :P Mar 08 19:09:16 dangole: My initramfs/"kernel" is kept on the FAT partition and loaded via the octboot uboot call. Mar 08 19:09:19 Oh, well… it was the oldest RISC architecture, wasn't it? Mar 08 19:09:24 MIPS will be doing RISC-V? Mar 08 19:09:28 * zorun tries to imagine the confusion Mar 08 19:10:31 Brace yourselves for further MIPS toolchain bitrot… :/ Mar 08 19:11:23 blogic: FYI, I'm not seeing any LLDP frames on eth0, switch or lan1 on my RTL8380 switch Mar 08 19:11:48 dangole: again, I'm out of my depths and you might have no issues with the way it works, i just wanted to give you a heads up on it because it didn't play nicely when I brought th target up in the beginning Mar 08 19:12:10 blogic: well, only outgoing LLDP frames I mean Mar 08 19:17:13 Grommish: I guess if the bootloader relies in that FAT fs and we can't replace it easily, that's how it is then on that platform Mar 08 19:17:34 dangole: Gotcha Mar 08 19:18:19 Grommish: still better than some ipq4xxx boards where vendors hard-coded the configuration to be picked by the bootloader to 'config@foo' -- while the '@' is longer allowed for use in node names in more recent U-Boot... Mar 08 19:18:45 don't know if U-Boot did that deliberately to annoy QCA Mar 08 19:24:07 dangole: https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=aef0bd713d31d1886cef7a11b82c631889e285fd Mar 08 19:24:15 see if you can interpret that Mar 08 19:25:01 the gist is that i know "mountroot" creates the file but i dont know if its just state internal to "mountroot" or if eventually any other entities need access to it Mar 08 19:26:26 and anyone who will need access to /tmp/sysupgrade.tar will then also be able to access /tmp/.switch_jffs2 Mar 08 19:30:13 anyway i think i did as much as i could at this stage: outstanding issues: fix uhttpd uci-default bug and ensure that /etc/uhttpd.crt is labeled properly. 2. diagnose the dnsmasq /var/etc vs. /tmp/etc issues 3. there is a loose end where wpad wanted to traverse /proc/sys but no traces as to why it wanted that Mar 08 19:31:48 o and 4. in the first paste there was also a trace of some netifd script trying to delete /tmp/run/wpa_supplicant/wlan1 but it was incomplete due to setenforce 1 and needs to be reproduced Mar 08 19:36:00 dangole: Installing the image I built… Mar 08 19:36:48 … and it's broken. Mar 08 19:38:18 i should probably just remove that whole mountroot domain, that thing cannot be contained ... no point in trying Mar 08 19:41:31 we need to reproduce the event where that sysupgrade.tar gets "restored" so that we can confirm that it doesnt mess up the labeling Mar 08 19:49:53 grift: don't give up, because in the end there are 3 generic methods and those should be supported. never mind platform hacks. Mar 08 19:51:48 grift: it gets extracted here, just like the sysupgrade.tar.gz on other platforms: Mar 08 19:51:58 grift: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/preinit/80_mount_root Mar 08 19:54:02 ok then thats not in the mountroot domain , so that should be fine Mar 08 20:00:18 right. that's preinit. mount_root is only what is in fstools.git, ie. here: https://git.openwrt.org/?p=project/fstools.git;a=blob;f=mount_root.c Mar 08 20:02:00 yes so the file gets created in the mountroot.subj domain and then restored from sys.subj which has all the transition rules needed to ensure consistent labeling and has unconfined access Mar 08 20:02:35 should be fine Mar 08 20:26:08 MIPS doing RISC-V now makes sense to me, they probably do not have the resources to maintain their architekture (Linux support, toolchain, ...) any more and could just sell their eixsting cores with a RISC-V front end. Mar 08 20:26:49 it is probably easier for them to sell RISC-V cores now than MIPS cores Mar 08 20:28:23 Meh… RISC-V is more of the same. Mar 08 20:29:01 rsalvaterra: shush Mar 08 20:29:40 aparcar[m]1: I want a Mill. :P Mar 08 20:30:32 grift: looks all good regarding mount_root and all that now. just the remaining weird issues left: https://termbin.com/wpyw Mar 08 20:33:26 I'm sure you guys know about the Mill architecture, right? Mar 08 20:35:19 rsalvaterra: nope Mar 08 20:36:06 https://www.youtube.com/channel/UCKdGg6hZoUYnjyRUb08Kjbg Mar 08 20:36:17 rsalvaterra: I've seen some videos Mar 08 20:37:06 It's still vapourware, but conceptually fascinating. Mar 08 20:39:37 * Borromini never heard of it Mar 08 20:40:50 Borromini: Watch the videos (especially the one about the belt). Beware, they're *long*. ;) Mar 08 20:41:06 dangole ok one issue solved (wpad) Mar 08 20:42:01 dangole: where is that code that makes /etc/init.d/boot execute /etc/init.d/{uhttpd,rpcd} and get attribute of /etc/uhttpd.crt? Mar 08 20:42:39 so no actual hardware expected to show up yet though? Mar 08 20:42:41 i assume thats from a uci-defaults script? Mar 08 20:43:15 dangole: on the Buffalo WSR-2533DHP2 the paralell nand chip is not found any more after upgarding from 5.4 to 5.10 Mar 08 20:43:27 I am trying to get this into upstream OpeNWrt Mar 08 20:43:44 dangole: are you aware of a problem with parallel nand? Mar 08 20:44:14 Borromini: Not yet. They're working on a shoestring budget, ironing out the toolchain side, FPGA will be next. Mar 08 20:44:22 dnthis is mt7622 Mar 08 20:44:27 dangole: Mar 08 20:44:48 rsalvaterra: ok Mar 08 20:45:32 Hauke: do they sell these in europe? Mar 08 20:45:44 got mine from Japan Mar 08 20:53:08 yeah well thought that was Buffalo's market Mar 08 20:53:13 mt7622 and mt7615 it seems Mar 08 20:54:44 mt7622 and mt7615 is pretty nice, but mt7622 and mt7915 looks better Mar 08 20:57:45 ;) Mar 08 20:57:54 i'm a bit surprised to see that ARM + ac combo Mar 08 21:00:00 The Buffalo WSR-2533DHP2 was released 1.5 years ago, at that time mt7915 was not ready Mar 08 21:00:35 it is strange that no devices reached the EU Mar 08 21:00:41 oh. nevermind me then. didn't know mt7622 had been around that long already Mar 08 21:03:25 banana pi r64 was the first device, released about 2 years ago Mar 08 21:06:00 ok Mar 08 21:06:20 btw, you were talking about how you suspected some minstrel patches about causing wireless instability the other day? Mar 08 21:06:40 yes Mar 08 21:06:52 any bumps in particular you're suspecting? Mar 08 21:07:09 last one i see in the tree is 072bfe2113 Mar 08 21:08:43 Borromini: I just reverted all of the new patches ;-) Mar 08 21:09:55 ok :P Mar 08 21:13:25 Hauke: I wasn't aware we got any MT7622 boards with parallel NAND Mar 08 21:13:49 Hauke: I can update arm-trusted-firmware-mediatek to generate bl2 for those, and U-Boot, ... Mar 08 21:15:32 Hauke: for 5.10, maybe it's just kconfig missing if you start with the vendor loader. Felix has also implemented supoort fr MTK's broken BBT/BMT implementation, but I strongly believe we should just use UBI instead. Mar 08 21:15:39 I am using the vendor u-boot Mar 08 21:17:07 when I select kernel 5.4 it finds the nand chip with kernel 5.10 it does not find the chip Mar 08 21:17:19 the controlelr is initilized Mar 08 21:17:20 Hauke: the driver seems to be selected for 5.10, I guess you checked that DTS matches mediatek,mt7622-nfc Mar 08 21:17:30 dangole: does this patch description resemble some truth? https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=8d5c4634cd3aa17134a821bfbe189a50dc551570 Mar 08 21:18:00 The NAND_OP_WAITRDY_INSTR operation is called and runs into a timeout Mar 08 21:18:18 grift: no, this is wrong to begin with, as I said. you should not have this wrongness in the policy, just deny Mar 08 21:18:19 hmm buidling with external kernel tree does not work any more Mar 08 21:18:37 ok Mar 08 21:19:28 dangole: please check the SourceName/ABIVersion patch Mar 08 21:19:39 I wnat to have this asap to be able to use the upgrade server Mar 08 21:21:55 Hauke: odd. All I can tell you is that SPI-NAND works great... Mar 08 21:22:26 dangole: ok well only one issue left then and thats dnsmasq: can you give me a `ls -alZ /tmp/etc | nc termbin.com 9999`? Mar 08 21:22:35 Hauke: and it's just normal 2k+64 layout, I guess Mar 08 21:25:26 grift: https://termbin.com/iiq6 Mar 08 21:26:48 dangole: ok thanks Mar 08 21:27:05 dangole and a `ls -alZ /tmp | nc termbin.com 9999` please Mar 08 21:27:08 Hauke: I followed up on your comments around updating malta to 5.10. Could you review when you have a moment? Thanks: https://github.com/openwrt/openwrt/pull/3881. Mar 08 21:28:09 dangole can you determine what creates /tmp/etc ? (besides /etc/init.d/rcdnsmasq) Mar 08 21:28:41 something running before /etc/init.d/dnsmasq creates /tmp/etc with a bad label Mar 08 21:28:48 probably an init script Mar 08 21:29:03 grep -r etc /etc/init.d/ | grep mkdir Mar 08 21:30:00 grift: uhttpd: mkdir -p /var/etc/uhttpd Mar 08 21:30:11 thanks Mar 08 21:30:23 grift: again, those are just side effects of @aparcars wrong uci-defaults script starting uhttpd super early where it shuold not Mar 08 21:30:36 grift: ie. ignore this Mar 08 21:32:46 dangole so that then means i can ignore pretty much all of your paste .... Mar 08 21:33:06 grift: isn't that good news? Mar 08 21:33:39 i mean theres only one issue in there were wpa_supplicant and hostapd read/write ipv{4,6} net sysctls Mar 08 21:33:48 and i assume thats not a bug? Mar 08 21:35:16 k well then i guess i am done Mar 08 21:39:42 someone please run this command and tell me why some default packages appear twice: TOPDIR=$(pwd) make -C target/linux/mvebu/ val.DEFAULT_PACKAGES Mar 08 21:40:28 specifically kmod-gpio-button-hotplug Mar 08 21:41:15 dangole: this broke it: https://git.kernel.org/linus/5197360f9e09449ac7249a98fbde36a3608e059c Mar 08 21:45:30 what's the process for backporting a patch from stable? Mar 08 21:45:54 talking about the kernel, not openwrt Mar 08 21:49:59 mangix: normally you add stable to Cc on the patch or add a Fixes tag Mar 08 21:50:14 then it will be added to stable after it reached Linus tree Mar 08 21:50:55 mangix: Backporting *from* stable? Or *to* stable? Mar 08 21:51:08 mangix: otherwise see Documentation/process/stable-kernel-rules.rst Mar 08 21:51:10 I'm talking about this patch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210305&id=4daff3e5b42422cd4af758cc7768223d2b7f6e14 Mar 08 21:51:29 I didn't add any fixes line to it Mar 08 21:52:11 mangix: https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst option 2 Mar 08 21:52:33 Hauke: ty Mar 08 21:53:07 is it in Linus tree already? Mar 08 21:53:49 Hauke: yes Mar 08 21:54:56 ok then it should be pretty easy Mar 08 22:00:40 jow: I made the fw3 device filtering changes to clean up DSCP/MARK rule handling: https://github.com/guidosarducci/firewall3/commits/master-fix-dscp-mark Mar 08 22:01:43 Hauke: at least it didn't take days of digging. you already figured why? (i was having dinner and just read the diff now) Mar 08 22:02:37 I am looking at it now Mar 08 22:02:45 I think the timeout is wrong Mar 08 22:02:48 I am checking Mar 08 22:03:09 I just wansted to revert some patches and it worked after the first try Mar 08 22:11:21 Hauke: lucky ;) Mar 08 22:12:19 Hauke: I wasn't that lucky with U-Boot 2021.04-rc3 breaking MMC on MT7622 (where U-Boot 2020.10 works). there are some obvious changes affecting exactly the relevant places (min speed adjustment and such), but reverting them didn't fix it... Mar 08 22:12:48 dangole: I was also suprised that it worked so fast Mar 08 22:13:47 dangole: found the problem, I will send a patch upstream Mar 08 22:14:04 the condition in readl_poll_timeout() was wrong, this is a break condition Mar 08 22:14:15 I did this mistake also some time ago in other code Mar 08 22:16:08 Hauke: does the romloader of the MT7622 support booting directly off parallel NAND? of is there an extra SPI chip for ATF bl2/preloader? Or just U-Boot SPL old-school? Mar 08 22:16:50 Hauke: I'm asking because arm-trusted-firmware-mediatek only supports emmc, sdmmc, snand and snor Mar 08 22:17:17 Hauke: so I'm wondering what to feed the bootrom on the pnand case and how it will load it Mar 08 22:19:08 dangole: I do not know Mar 08 22:19:12 here is the boot log: https://paste.debian.net/1188452/ Mar 08 22:20:21 if they supprot spi nand boot, I assume they also supprot p nand boot Mar 08 22:20:52 but I think spi nand is now cheaper than p nand Mar 08 22:21:32 Hauke: it's the same old bootchain as on the Linksys/Belkin device apparently Mar 08 22:21:56 Hauke: probably they just didn't make the effort to port that to TF-A (yet) Mar 08 22:22:23 Hauke: nice to see that it loads the new-school FIT image without problems though :) Mar 08 22:22:55 Hauke: ie. RAMDisk Image separate in the FIT, 'config@1' -> 'config-1' Mar 08 22:23:24 Hauke: probably it won't support loadables (eg. squashfs) or ext-FIT yet. Mar 08 22:24:10 Hauke: but good to see that my assumptions on what the old U-Boot from MTK SDK supports hold true for now Mar 08 22:24:47 there is a brcm trx header around the image Mar 08 22:24:58 also the initramfs Mar 08 22:26:18 ouh. that's hacky. but i see those Original load address = 0x4007ff28, After skip trx_header, load address = 0x4007ff44, ... Mar 08 22:27:21 yeah, and it's U-Boot SPL loading U-Boot loading ATF instead of the other way around, like they do now Mar 08 22:29:10 dangole: this device is 1.5 years old Mar 08 22:30:10 Hauke: even the Linksys/Belin which are made starting from August 2020 come with that bootchain. I guess newer versions of MTK already contain it the new way as they published on github and we do in OpenWrt as well now, and we will see that in future devices. Mar 08 22:31:06 normally board vendors start with something at some point in time and they they do not want to change, because it is working Mar 08 22:31:41 dangole: which github are you talking about? Mar 08 22:31:44 Hauke: so will be for MT7629 Mar 08 22:31:55 Hauke: github.com/mtk-openwrt Mar 08 22:33:21 Hauke: in OpenWrt we already got package/arm-trusted-firmware-mediatek from there and I'm preparing U-Boot update in my stating tree (as I said, MMC is still too slow to be functional right now, but for SPI-NAND it already works very nicely with U-Boot 2021.04-rc3) Mar 08 22:33:44 nice Mar 08 22:34:34 just that 'bromimage' tool is still binary only, someone outside of MTK and without NDA needs to make a clean re-write under some free license, I reckon... Mar 08 22:34:48 ie. that currently breaks build on non-Linux buildhosts :( Mar 08 22:35:13 does it work on arm64 linux? ;-) Mar 08 22:35:26 nope Mar 08 22:35:29 someone complains that the marvell U-Boot does not build on arm64 Linux Mar 08 22:35:45 x86_64, and x32 only Mar 08 22:36:03 there is also some rudimentary tooling in U-Boot's 'mkimage -T mtk_image' to replace 'bromimage' for other MTK SoCs but it's not sufficient for MT7622 apparently (I tried for days...) Mar 09 00:41:09 dangole: Good news, clean master with Linux 5.10.20 doesn't exhibit the mt76 EEPROM problem. I guess I'm on the right track now. Mar 09 00:42:05 I may have screwed up my kernel config somewhere… Mar 09 00:55:37 blogic: Actually, MIPS (the architecture) might not be dead yet… https://www.eenewsanalog.com/news/mips-moves-china-samoa Mar 09 01:00:46 rsalvaterra: don't taunt blogic like that.. He seemed so happy it was gone ;p Mar 09 01:45:58 rsalvaterra: so all that bisecting and other stuff was because of something not clean in your tree? Mar 09 01:46:14 rsalvaterra: i mean a clean build would have just worked? **** ENDING LOGGING AT Tue Mar 09 02:59:57 2021