**** BEGIN LOGGING AT Mon Jan 17 02:59:57 2022 Jan 17 04:00:05 nope, still not even showing sdmmc interface in boot log, but it doe show emmc interface (with nothing connected) Jan 17 07:45:06 good morning Jan 17 09:45:12 Hello! I am having a issue with wic/peudo. When copyhardlinktree() uses find|tar|tar to copy the prepared root filesystem to the new rootfs directory, tar will attempt to set file ownership (set owner to root:root) for many files and directories. Jan 17 09:45:12 This fails as copyhardlinktree is not run using pseudo. Now I'm scratiching my head why it isn't and why this worked on an older dunfell but not on the most recent dunfell. Jan 17 14:30:33 Anyone had any luck with the option driver for 4g modems? Jan 17 14:30:44 it's not creating a wwan0 interface for me Jan 17 15:15:15 "Anyone had any luck with the..." <- I had but what are you using to connect ? Jan 17 15:15:29 ModemManager Jan 17 15:19:24 hmw[m]: https://p.mort.coffee/07B Jan 17 15:20:53 I don't think those cfg80211 dmesg lines are relevant Jan 17 15:24:43 i opted to also install networkmanager Jan 17 15:26:25 what i did ( don´t know if it is correct) is create a apn connection using nmcli and i added that connection to the distro installatiation Jan 17 15:28:27 mmcli -m 0 --simple-connect="apn=$APN,$OTHER_OPTIONS" ( that also should connect to the internet) Jan 17 15:28:49 m you did that Jan 17 15:30:25 mort: can i be that you are missing linux drivers ? Jan 17 15:30:55 quite possible, but I don't know what those drivers should be Jan 17 15:31:00 it is detected by the option driver Jan 17 15:32:53 that's https://github.com/torvalds/linux/blob/master/drivers/usb/serial/option.c#L13 this driver Jan 17 15:37:35 yes and you need qmi wan Jan 17 15:37:39 and prob another one Jan 17 15:39:02 * qmi_wwan Jan 17 15:42:06 under usb serial converter support there is also usb dirver vor gsm and cdma modems that you prob need to Jan 17 15:43:12 [*] Device Drivers →... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/79c85f7f8691fb07f2c817d9370dc1eb13323200) Jan 17 15:44:03 i think that is what you need for your wwan0 but not 100% sure Jan 17 15:50:39 I see Jan 17 15:51:54 I'll try to get the qmi_wwan driver working then Jan 17 17:14:47 nerdboy: i regularly run my rock-pi-e and it's running 5.15.6 as we speak off the sdcard Jan 17 17:14:58 nerdboy: (linux-yocto) Jan 17 17:17:58 i'd say there was some hw broken except u-boot works fine Jan 17 17:27:08 RP: Hi, I don't want to add extra load onto you, but could you please pick the U-Boot 2022.01 patch I sent to oe-core for kirkstone ? The 2022.01 looks like a nice release, so it would be good to have it in the upcoming LTS Jan 17 17:28:48 RP: this patch https://lists.openembedded.org/g/openembedded-core/message/160384 Jan 17 17:30:07 marex: queued, sorry it slipped through the cracks Jan 17 17:35:22 RP: no worries, thanks ! Jan 17 17:35:42 RP: it seems to me kirkstone is gonna be a good LTS release from the looks of it :) Jan 17 17:39:18 marex: I hope so! :) Jan 17 17:39:45 RP: so far it really does look good Jan 17 17:45:23 marex: I'm curious if anything in particular stands out? Jan 17 17:47:50 RP: u-boot 2022.01 , linux 5.15.y , mesa 21.3.y , looks good Jan 17 17:48:00 if we had gstreamer 1.20, that would be grand, but that;s not out yet Jan 17 17:50:56 :) Jan 17 18:28:46 marex, that's what lts mixin layers are for Jan 17 18:29:25 I would publish my go mixin work for dunfell if siemens would sort the maintenance support Jan 17 19:18:33 kanavin: doesnt siemens push their isar, which has the debian updates, or whichever river they called their thing after ? Jan 17 19:19:01 kanavin: I am pushing https://source.denx.de/denx/meta-mainline-common Jan 17 19:19:18 kanavin: that's where I stash my up-to-date kernel version + u-boot version + mesa3d Jan 17 19:20:04 kanavin: I recall there were other attempts at up-to-date base components, but I haven;t seen one which did stick Jan 17 19:20:49 I wouldn't mind making the above somehow more "official" Jan 17 19:58:14 marex, siemens consists of many parts, and they're not all using the same thing :) Jan 17 19:59:37 marex, this is the official one https://git.yoctoproject.org/meta-lts-mixins Jan 17 20:00:26 kanavin: that seems very outdated, we're at 5.10.92 now :-) Jan 17 20:00:53 marex, ask zeddii ;) Jan 17 20:01:05 kanavin: would it make sense to start mixin' in the https://source.denx.de/denx/meta-mainline-common ? Jan 17 20:01:30 marex, no Jan 17 20:01:51 create additional branches in meta-lts-mixin, and submit them to get merged Jan 17 20:01:57 5.10 is up to date, we just need the SRCREV bumps in the mixin. that's what Denys was going to do, so I stay out of his way. Jan 17 20:02:09 the idea is to check out different branches the same repo several times Jan 17 20:02:19 into different directories Jan 17 20:02:51 zeddii: it says 5.10.79-ancient , 5 weeks ago Jan 17 20:03:00 zeddii: https://git.yoctoproject.org/meta-lts-mixins/log/?h=dunfell/kernel here Jan 17 20:03:05 I repeat my statement Jan 17 20:04:08 still, the aforementioned layer also has u-boot and mesa updates, and i would also like to do gstreamer Jan 17 20:05:05 kanavin: uh ... what does it have to do with adding additional kernel recipes into that repository (or another repository) ? Jan 17 20:05:20 kanavin: I think I don't understand the statement about checking out repo Jan 17 20:05:35 * zeddii has to go get rid of 40cms of snow. will be back later. Jan 17 20:05:53 marex, if you want to provide official backports to dunfell, meta-lts-mixins is the layer to do that Jan 17 20:06:19 create a dunfell/thingy branch, and submit/maintain it Jan 17 20:06:24 zeddii: can;t you just bitbake universe and let the servers hot air melt the snow ? Jan 17 20:06:39 heh. Would be nice! Jan 17 20:07:12 marex: but to be more specific, I'm posting the SRCREVs to the oe-core list for 5.10, Denys was grabbing them for the layer. I could do the merges to that layer as well, but that's not how we arranged it to work. Jan 17 20:07:24 kanavin: and how do I go about that ? just submit the recipes to openembedded-core with [meta-lts-mixing] prefix ? Jan 17 20:07:25 when I'm done digging out from the snow, I can ping and get the mixin layer bumped. Jan 17 20:07:43 * zeddii really goes Jan 17 20:07:55 zeddii: I think I'll be around for a bit longer, let's continue the discussion later ? Jan 17 20:08:13 enjoy the workout Jan 17 20:08:14 marex, denix should be able to answer Jan 17 20:08:39 alex marex and denix, I guess we could all write our posix kernels :) Jan 17 20:08:42 kanavin: which reminds me ... I should trigger CI and AUH about that 'stderr' patch Jan 17 20:08:52 heh Jan 17 20:09:18 marex, fwiw latest master auh round went totally fine, so it must be a dunfell thing Jan 17 20:09:48 at some point recently bitbake and devtool stopped mixing stderr into stdout, so I had to adjust auh accordingly Jan 17 20:10:41 kanavin: the CI is running, let's see Jan 17 20:28:02 kanavin, zeddii: ok, updated meta-lts-mixin with few latest 5.10 commits - it fell behind a bit due to holidays... Jan 17 20:29:02 denix: what about adding u-boot and mesa into the mixin layer , and linux 5.4 and 5.15 ? Jan 17 20:31:37 marex: the concept of LTS mixin layer was to have a single-purpose topic branch - e.g. dunfell/kernel is to host newer kernels for dunfell release Jan 17 20:31:53 so, yeah, you can do dunfell/u-boot and dunfell/mesa if you want Jan 17 20:32:20 5.4 doesn't make sense for dunfell, as it's already there in oe-core, but 5.15 makes sense Jan 17 20:32:47 denix: why not put all the recipes in one branch ? Jan 17 20:33:22 (I now understand what kanavin meant with "multiple checkouts" though) Jan 17 20:33:34 am I right to assume that conditionally adding patches to SRC_URI based on some yocto variable isn't a good thing to do? Jan 17 20:34:11 dv__: like SRC_URI:append:machine = " file://foo.patch" ? Jan 17 20:34:45 marex: yeah, multiple checkouts is a downside of this conecpt... Jan 17 20:35:12 denix: so why this concept, is there a reason for that ? Jan 17 20:36:49 one use case for this that I was briefly thinking about: conditionally enabling a subsystem by patching a kernel's DTS Jan 17 20:37:06 marex: there was a discussion long back on oe-architecture list and this was the proposal that we agreed on, so TSC put it in writing here - https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_.E2.80.9CMixin.E2.80.9D_repositories Jan 17 20:37:12 dv__: do you also conditionally patch the hardware which the DT describes ? Jan 17 20:37:18 RP: anything to add ^^^? Jan 17 20:37:30 dv__: because DT is hardware description and does NOT encode policy Jan 17 20:37:48 marex: but enabling this subsystem increases power draw, so it is not always used Jan 17 20:38:12 dv__: should this subsystem be enabled at build-time or run-time ? Jan 17 20:38:43 dv__: have a look at fitImage and DTO , you can build the base DT with subsystem enabled and then have U-Boot apply DTO which adds some "status = disabled" into the DT Jan 17 20:38:49 or just ship two DTs in the fitImage Jan 17 20:38:49 from what I see here, there's no way to enable it at run-time currently. no idea if it would even be possible. Jan 17 20:39:03 hmm interesting Jan 17 20:39:22 dv__: if it is a DT modification, you can perform the modification before passing the DT to the kernel Jan 17 20:39:30 dv__: if you need build time, maybe you want to look at PACKAGECONFIG ? Jan 17 20:39:38 and maybe MACHINE_FEATURES (?) Jan 17 20:39:43 no, it is purely a DT modification Jan 17 20:39:54 dv__: do you use U-Boot ? Jan 17 20:39:58 or something else ? Jan 17 20:40:01 u-boot, yes Jan 17 20:40:09 so, DTO seems interesting, didn't know about it Jan 17 20:40:14 well, then maybe the DTO is really quite flexible approach Jan 17 20:40:24 dv__: the trick I deliver quite often is this Jan 17 20:40:50 build up a fitImage, encode single kernel, one (or more) base DTs and matching DTOs for expansion boards, and finally a boot.scr script Jan 17 20:41:10 when the system loads the fitImage, it can source the embedded script in it (which can be signed alognside the fitImage) and the script can apply the suitable DTO Jan 17 20:41:18 upside is, you can ship updated boot script, signed too Jan 17 20:42:00 and then in the boot script, you can script your "enable or disable whatever, based on e.g. u-boot environment variable, which you can set with libubootenv at runtime, or do what you want" Jan 17 20:42:11 hmm, neat Jan 17 20:42:23 certainly beats conditionally adding stuff to SRC_URI Jan 17 20:42:47 has DTO support been in u-boot for a while now? or is it new? Jan 17 20:43:14 dv__: and bonus is, you can stack the DTOs in U-Boot, so if you e.g. have multiple expansion boards which you can auto-detect, the boot script can auto-apply all those DTOs for you Jan 17 20:43:28 dv__: err .... let's see Jan 17 20:45:05 dv__: 5 years Jan 17 20:46:03 ddf67f71352 ("libfdt: Add overlay application function") Jan 17 20:46:06 Date: Tue Jul 5 10:26:44 2016 +0200 Jan 17 20:58:13 ok, great Jan 17 21:02:15 denix: lemme read that Jan 17 21:50:47 tlwoerner: i found your regulator patch, i'm having exactly that behavior with rk3328 renegade board Jan 17 21:51:56 well, the boot stopping part, waiting and poking the sdcard didn't do anything for me Jan 17 21:52:41 last thing in the console is [ 31.715247] vcc_sd: disabling Jan 17 21:57:42 the best part is at the beginning: https://paste2.org/6IX4y4Yp Jan 17 21:58:48 i should've tried the simple/manual sdcard sooner... Jan 17 23:21:32 kanavin: https://paste.debian.net/hidden/7d96eb98/ here is the backtrace Jan 17 23:28:48 kanavin: maybe if we pick bitbake 1ecc1d9424877df89fcda2f23c306998998a65ff to dunfell, that might do the trick, lets try Jan 17 23:43:40 kanavin: yep, that's the fix all right ... although I'm not sure whether backporting that to dunfell is the right approach Jan 18 02:16:59 tlwoerner: turns out wasn't the same cause as your issue: https://paste2.org/1ywkMWXP Jan 18 02:17:08 typo maybe? **** ENDING LOGGING AT Tue Jan 18 02:59:56 2022