**** BEGIN LOGGING AT Mon Sep 21 08:50:38 2020 **** BEGIN LOGGING AT Mon Sep 21 09:30:01 2020 **** BEGIN LOGGING AT Mon Sep 21 09:32:16 2020 Sep 21 09:52:55 Hi folks! Sep 21 09:52:59 Is there a way to ensure the order in which images are created. Sep 21 09:53:05 I have IMAGE_FSTYPES = "ext4.gz wic.gz" and I would like the ext4 to be created first as the this then gets inserted into the wic file. **** BEGIN LOGGING AT Mon Sep 21 10:03:24 2020 Sep 21 10:07:09 dmation: try maybe IMAGE_TYPEDEP_wic += "ext4"? Sep 21 10:08:20 qschulz, I will give it a go. How is this different though? **** BEGIN LOGGING AT Mon Sep 21 10:18:10 2020 Sep 21 10:18:44 Sorry, did I miss read? Ah, I see my mistake sorry. Sep 21 10:19:22 :) Sep 21 10:22:42 That did not work off the bat, but has given me a lead, thank you. Sep 21 10:24:03 dmation: also, you might want to check you're looking into the correct directory when the wic image is being created Sep 21 10:24:33 (to find the ext4.gz tarball) Sep 21 10:25:40 I think that the directory is correct, if I add "-k" ie `bitbake -k core-image-...` the next run will work. **** BEGIN LOGGING AT Mon Sep 21 10:30:37 2020 Sep 21 10:38:28 Thanks qschulz, That did the trick! I changed where it was looking for the file. IMAGE_BOOT_FILES+="${WORKDIR}/deploy-${IMAGE_BASENAME}-image-complete/${IMAGE_BASENAME}-${MACHINE}.ext4.gz;rootfs.ext4.gz" Sep 21 10:42:27 what comes to mind first when there's a task to remotely support (SSH) a Yocto-enabled iot device? manual fiddling with VPN's? some vendor-specific solution? Sep 21 11:08:21 dmation: IMGDEPLOYDIR is what you're looknig for for the path **** BEGIN LOGGING AT Mon Sep 21 11:13:41 2020 Sep 21 11:44:07 Hi guys, I installed firewalld on my warrior based distro Sep 21 11:44:38 I had some problems in using it Sep 21 11:44:57 Every firewall-cmd --state results in failed state Sep 21 11:45:45 Do you know if I need to install some packages or if there are common pitfalls to watch out? Sep 21 11:54:18 qschulz, nice one, thanks again Sep 21 11:56:57 kriive, I do not have experience with firewalld, but I know I had some issues with iptables requiring some very specific kernel modules. Sep 21 12:00:16 dmation: thanks Sep 21 12:01:17 alternatively, do you know if there are other firewall tools that offer D-Bus interfaces or in general programmable interfaces? **** BEGIN LOGGING AT Mon Sep 21 12:56:36 2020 Sep 21 12:59:25 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/2494 **** BEGIN LOGGING AT Mon Sep 21 13:41:48 2020 Sep 21 13:57:13 kanavin_home: you had an ex-colleague write a buildstats critical path tool right? Sep 21 14:03:21 rburton: yes Sep 21 14:03:37 and not an ex-colleague, still current I think **** BEGIN LOGGING AT Mon Sep 21 14:22:31 2020 Sep 21 14:23:10 if there is no opposition i can submit a patch Sep 21 14:57:33 Having issues with an autotools build resulting in this eror: gnu-configize: 'configure.ac' or 'configure.in' is required. But the configure.ac is there, it's almost like bitbake invokes from wrong directory, Ideas? Sep 21 15:04:39 lxc have you checked if the S variable points to the location where the configure.ac is? Sep 21 15:05:05 It dos, S = "${WORKDIR}/git" Sep 21 15:05:50 can you add do_confiture_prepend() { bbwarn ${S} } Sep 21 15:05:56 just to be sure nothing is changing it Sep 21 15:06:24 do_configure_prepend, sorry for the typo Sep 21 15:08:46 ptsneves: French breakfast time :D? Sep 21 15:09:28 lxc: check B while you're at it. Might be one of those tools which requires autootols-broken and not autotools? Sep 21 15:10:06 eheh just prepending some warning :) Sep 21 15:10:58 ptsneves: (configure = jam in French :) ) Sep 21 15:11:02 confiture Sep 21 15:11:09 here I do the opposite typo :D Sep 21 15:11:40 yep. took me some time to connect it :) Sep 21 15:13:15 by the way i do not think B matters, nor autotools-brokensep because the error comes from checking AUTOTOOLS_SCRIPT_PATH which is defaulted to ${S}. The B would be important in the build or may configuration, but he did not even get to that part Sep 21 15:13:30 he/she, sorry Sep 21 15:13:36 qschulz ptsneves Both B and S looks correct. Using autotools-brokensep does not resolve the issue (but of course S and B is the same then) Sep 21 15:14:08 can you go to the path printed in the bbwarn and check if the configure.ac is there? Sep 21 15:14:26 can you confirm if configure.ac is in the root of the git repo? Sep 21 15:16:08 ptsneves it is there in the root of the repo. Sep 21 15:19:21 ok, so maybe let me try another approach. Could you get a paste of the log of the whole configure task and its error? Sep 21 15:24:31 ptsneves | autoreconf: configure.ac: tracing| autoreconf: configure.ac: adding subdirectory ext/tinydtls to autoreconf| autoreconf: Entering directory `ext/tinydtls'| autoreconf: configure.ac: not using Autoconf| autoreconf: Leaving directory `ext/tinydtls'| autoreconf: running: libtoolize --copy --force| libtoolize: putting auxiliary files in Sep 21 15:24:31 '.'.| libtoolize: copying file './ltmain.sh'| libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.| libtoolize: copying file 'm4/libtool.m4'| libtoolize: copying file 'm4/ltoptions.m4'| libtoolize: copying file 'm4/ltsugar.m4'| libtoolize: copying file 'm4/ltversion.m4'| libtoolize: copying file 'm4/lt~obsolete.m4'| autoreconf: running: Sep 21 15:24:32 /usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/recipe-sysroot-native/usr/bin/autoconf --include=/usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/git/m4/ Sep 21 15:24:32 --include=/usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/recipe-sysroot-native/usr/share/aclocal/ --force| autoreconf: running: /usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/recipe-sysroot-native/usr/bin/autoheader Sep 21 15:24:33 --include=/usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/git/m4/ --include=/usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/recipe-sysroot-native/usr/share/aclocal/ --force| autoreconf: running: automake --add-missing --copy --force-missing| configure.ac:38: Sep 21 15:24:33 installing './ar-lib'| configure.ac:33: installing './compile'| configure.ac:43: installing './config.guess'| configure.ac:43: installing './config.sub'| configure.ac:23: installing './install-sh'| configure.ac:23: installing './missing'| Makefile.am: installing './INSTALL'| Makefile.am: installing './depcomp'| autoreconf: running: gnu-configize| Sep 21 15:24:34 gnu-configize: 'configure.ac' or 'configure.in' is required| autoreconf: gnu-configize failed with exit status: 1| + die 'autoreconf execution failed.'| + bbfatal_log 'autoreconf execution failed.'| + '[' -p /usr/local/src/yocto-xr/build/infn-xr/qemux86/tmp/work/core2-32-poky-linux/libcoap/4.2.1-r0/temp/fifo.15549 ']'| + printf '%b\0' 'bbfatal_log Sep 21 15:24:34 autoreconf execution failed.'| + exit 1| + bb_exit_handler Sep 21 15:26:01 Entering directory `ext/tinydtls', so the build is not in the root of the repo. This is point one Sep 21 15:26:30 lxc: please use pastebin next time, easier to read :) Sep 21 15:27:08 ptsneves Leaving directory `ext/tinydtls Sep 21 15:27:34 oh you are right. Can you put it in pastebin? Sep 21 15:29:12 ptsneves how do you pastebin in the webchat? Sep 21 15:29:48 go to https://pastebin.com/ create a paste and share the url Sep 21 15:30:13 also, do you cnfirm you are trying to build libcoap from https://libcoap.net/install.html? Sep 21 15:33:19 ptsneves pastebin.com is blocked in firewall from where I'm located. Correct it is libcoap, 4.2.1 Sep 21 15:33:47 lxc: any pastebin found on google is fine basically :) Sep 21 15:33:58 or a gist on github if you want Sep 21 15:34:56 lxc also please also share the recipe if possible, given this is an open source project Sep 21 15:36:01 ptsneves Sep 21 15:36:05 @pts Sep 21 15:36:40 ptsneves pastebin.com is blocked in firewall from where I'm located. Correct it is libcoap, 4.2.1 Sep 21 15:37:06 ptsneves LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=4cba1bd050d08b2154b5c29de3a0e9c2"SRC_URI = "git://github.com/obgm/libcoap.git;tag=v4.2.1"S = "${WORKDIR}/git"inherit autotools pkgconfigEXTRA_OECONF += "--with-shared"EXTRA_OECONF += "--without-debug"EXTRA_OECONF += "--disable-doxygen"EXTRA_OECONF += "--disable-dtls"EXTRA_OECONF += Sep 21 15:37:07 "--disable-manpages"EXTRA_OECONF += "--without-gnutls" EXTRA_OECONF += "--without-openssl" EXTRA_OECONF += "--without-tinydtls" Sep 21 15:37:41 lxc: use this one https://pastebin.centos.org/ Sep 21 15:38:41 kriive ptsneves https://paste.centos.org/view/da0c680a Sep 21 15:39:41 much better. Will give it a try and let you know Sep 21 15:41:07 ptsneves thanx Sep 21 15:42:41 Is there any more detailed info about building / running images on QEmu around? I'd like to put together an ARM target which emulates (ideally) both NAND and eMMC to evaluate some different software update frameworks on as it looks to be a lot quicker than physical hardware, but im struggling to find much documentation bar the standard "MACHINE=quemuarm bitbake ..." Sep 21 15:43:22 pev: have a look at the testing manual? Sep 21 15:44:25 pev: http://docs.yoctoproject.org/test-manual/test-manual-intro.html#testimage - its testimage which boots up an image under qemu and allows us to run tests Sep 21 15:44:41 pev: or the runqemu command outside of bitbake Sep 21 15:46:19 RP: Great, thanks! Does the emulated machine configuration ever get changed in Yocto, or is that all done within QEmu itself? I can see I may need to actually do a QEmu tutorial rather than trying to shortcut...! :-D Sep 21 15:49:14 pev: we have certain targets we use for qemu which we don't change very often Sep 21 15:49:34 its just like any other BSP really Sep 21 15:53:15 RP: I have small patches https://lists.openembedded.org/g/openembedded-core/message/142632?p=,,,20,0,0,0::Created,,Khem,20,2,0,76904416 and https://lists.openembedded.org/g/openembedded-core/message/142626?p=,,,20,0,0,0::Created,,Khem,20,2,0,76900472 please take a look when you can Sep 21 15:53:24 helps with meta-oe testing a bit Sep 21 15:55:11 khem: ok, will take a look Sep 21 15:57:09 @lxc ok figured out your problem Sep 21 15:57:12 your flags are wrong Sep 21 15:57:50 ptsneves the EXTRA_OECONF flags? Sep 21 15:58:06 there is no without-tinytls which means that the tinytls is not actually disabled and there is a recursive autoreconf trying to run on ext/tinytls which is empty Sep 21 15:58:34 when you actually disable the tinytls correctly it will build but you will have other qa errors due to wrong EXTRA_OECONF flags Sep 21 15:58:39 RP: the systemd issue, I did not understand why its failing on you, I could see serial login was faster for me after disabling gshadow Sep 21 15:58:49 I wonder if there is another change poky has Sep 21 15:59:28 lxc set EXTRA_OECONF += "--with-tinydtls=no" and correct the other flags as advised by the QA configure error. Also have a look at the actual flag setting if they are important for you Sep 21 16:00:13 khem: I don't know. pam seems to be the big problem **** BEGIN LOGGING AT Mon Sep 21 16:04:39 2020 Sep 21 16:04:53 ptsneves still complaining about missing configure.ac Sep 21 16:05:21 let me clean. Sep 21 16:07:24 oh indeed :( so my flag was still wrong, but the follwowing unblocks me: Sep 21 16:07:25 diff --git a/configure.ac b/configure.acindex fb731a2..d8b45aa 100644--- a/configure.ac+++ b/configure.ac@@ -396,7 +396,6 @@ if test "x$build_dtls" = "xyes"; then # The user wants to use explicit OpenSSL if '--with-tinydtls was set'. if test "x$with_tinydtls" = "xyes" ; then if test -d "$srcdir/ext/tinydtls"; then- Sep 21 16:07:26 AC_CONFIG_SUBDIRS([ext/tinydtls]) have_tinydtls="yes" else have_tinydtls="no" Sep 21 16:07:29 ah crap Sep 21 16:07:46 remove the line AC_CONFIG_SUBDIRS([ext/tinydtls]) in configure.ac Sep 21 16:08:19 for some reason the flags are not correctly propagated. Figure that out and you do not need to patch the code Sep 21 16:12:02 @lxc i am leaving for now. let me know if it worked out for you. Sep 21 16:14:39 alejandrohs: nfs-utils gave me a simple template for modifying source before build, thanks! Sep 21 16:30:56 RP: http://sprunge.us/kGu0FD Sep 21 16:32:44 I can login into console within 3-4s after its appears Sep 21 16:36:41 khem: try an DISTRO=poky with my timing patch in the bugzilla and testimage for a core-image-sato-sdk Sep 21 16:36:48 er, DISTRO=poky-altcfg Sep 21 16:37:21 VIRTUAL-RUNTIME_login_manager="shadow-base" Sep 21 16:42:41 I'm porting a build-root system to yocto, working on U-boot. The original scripts run `mkimage' as a post-build step for U-Boot. When I run the call from do_compile_append() I get "mkimage: not found" Sep 21 16:43:59 I added DEPENDS=u-boot-mkimage, which installs 'uboot-mkimage' into ${D}${bindir}/uboot-mkimage Sep 21 16:45:01 But when I reference ${D}${bindir}/uboot-mkimage from a task in my U-Boot recipe, I still get an error, uboot-mkimage not found **** BEGIN LOGGING AT Mon Sep 21 16:52:29 2020 Sep 21 17:48:44 is there a way i can use a different toolchain for just one recipe? Sep 21 17:49:40 mischief: TOOLCHAIN = "clang" Sep 21 18:02:43 PaowZ: i cannot find any documentation on that variable or any use in the source of poky Sep 21 18:04:14 mischief: look at the meta-clang layer Sep 21 18:04:23 mischief: grep -r TOOLCHAIN /meta* Sep 21 18:05:14 mischief: the toolchain used is simply from the automatically added DEPENDS by base.bbclass. Set INHIBIT_DEFAULT_DEPS and then point at a different toolchain Sep 21 18:07:55 hm.. still not finding any references. is TOOLCHAIN part of zeus? Sep 21 18:08:20 I can grep it in DUNFELL Sep 21 18:21:31 Instead of `make' I ran 'oemake tools', which succeeds in making a .o file for every tool (fitimage, mkimage, etc) but fails on the final linking command, "Invalid architecture", which makes me think that some cross-compiled tools are mixing with native ones (which I want) Sep 21 18:22:01 so I'm cleaning the world now in case a previous invocation of "oemake crosstools" might have polluted the object directory Sep 21 18:57:48 what's the difference from using crops/poky or crops/yocto ? Sep 21 18:59:20 in particular, i would build dunfell, and ubuntu bionic seems to have some issues building samba, so trying to figure out proper ubuntu version to use for dunfell Sep 21 19:14:06 ad__: I believe crops/poky includes the wrapper script to ensure that your UID inside the container matches that outside the container Sep 21 19:14:14 I always use crops/poky Sep 21 19:14:59 Also, Ubuntu 18.04 should definitely be able to build the dunfell branch Sep 21 19:26:26 paulbarker, thanks, using FROM:crops/poky i get an error building samba Sep 21 19:26:28 Checking for system pyldb-util.cpython-38-arm-linux-gnueabi (>=1.5.8 <=1.5.999) : not found Sep 21 19:28:41 ad__: Please use a pastebin to share the command you ran and the full output Sep 21 19:28:54 We can't diagnose much from that one line Sep 21 19:38:37 paulbarker, ok thanks a lot, here the full log https://controlc.com/ba92b671 Sep 21 19:40:17 my understanding is that package "python3-ldb-devel" may be missing, but seems not available in crops/poky that is "bionic" Sep 21 19:40:40 but i can be totally wrong of course Sep 21 19:42:15 ad__: could you include the command you ran and the start of the output? Sep 21 19:43:05 The header printed by bitbake has some key info for debugging things like this Sep 21 19:51:46 paulbarker, ok let me add it Sep 21 19:57:33 paulbarker, https://controlc.com/95a66b3c Sep 21 19:57:37 i added also local.conf Sep 21 20:02:16 ad__: I wonder if the freescale layers are doing something crazy Sep 21 20:04:29 ad__: Maybe try running `bitbake-layers show-appends samba` and `bitbake-layers show-appends libldb`, see if any appends are listed Sep 21 20:04:58 I'd also recommend trying to build samba with a smaller set of layers enabled to isolate where the problem is being created Sep 21 20:05:58 paulbarker, ok thanks Sep 21 20:06:47 ad__: A last thought would be to retry with a lower value in BB_NUMBER_THREADS and PARALLEL_MAKE, it's unlikely but you could be exposing a race condition Sep 21 20:07:08 paulbarker, thanks a lot, will try Sep 21 20:07:46 ad__: If none of those resolve the issue, post to openembedded-devel@lists.openembedded.org with as much info as possible Sep 21 20:07:54 I have to go now though, good luck! Sep 21 20:08:08 paulbarker, thanks a lot ! Sep 21 20:13:24 I ran `file' on all the contents of ${B}/tools/, and all of them are x86_64 ELF, no ARM binaries. So why is gcc freaking out trying to link them? Sep 21 20:13:48 I just want to use uboot-mkimage from my uboot recipe Sep 21 20:29:35 ecdhe: its not using the arm linker is it? Sep 21 20:30:46 RP: I don't think so, invocation was oe_make, log shows bare gcc Sep 21 20:35:23 RP: it's tempting to install the package on the build host just to get one, but I want to stay consistent with the buildroot recipe I'm following, and ultimately, the fact that this is even an issue shows a hole in my understanding of yocto Sep 21 20:37:57 ecdhe: aren't these tools already available from a u-boot native recipe of some sort? Sep 21 20:39:13 RP: there is a u-boot-mkimage but it seems to actually cross compile the tool for use on the target Sep 21 20:39:23 A recipe, that is Sep 21 20:39:59 ecdhe: u-boot-tools-native ? Sep 21 20:41:00 So would I just add that to my DEPENDS? Sep 21 20:41:14 ecdhe: I'd think so Sep 21 20:41:51 find -type f -name '*u-boot-tools-native*' in my workspace gives me nothing Sep 21 20:42:12 ecdhe: look at the u-boot-tools recipe which has a BBCLASSEXTEND native Sep 21 20:48:09 grep -rn u-boot-tools returns no .bb files Sep 21 20:50:45 http://layers.openembedded.org/layerindex/recipe/5969/ Sep 21 20:52:54 zeddii: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot-tools.inc?h=master#n33 Sep 21 20:53:06 yup Sep 21 20:53:09 The invocation there is for the cross-tools target, cross compiled tools Sep 21 20:53:43 I had added this recipe to my DEPENDS and ran it, but it puts the tools in my target FS, not on my build machine. Sep 21 20:53:53 not if you didn't add the -native Sep 21 20:53:58 which is what RP was saying. **** BEGIN LOGGING AT Mon Sep 21 20:55:53 2020 Sep 21 20:56:04 The file's do_compile() calls oe_runmake cross_tools Sep 21 20:56:24 How does adding -native change the behavior to compiling native tools? Sep 21 20:57:10 it doesn't, but by default u-boot-tools is built for the target. -native says, build for the build host. Sep 21 20:57:14 ecdhe: it changes the CC and so on that is used Sep 21 20:57:41 see the changes native.bbclass makes Sep 21 20:58:20 Gotcha; so "cross_tools" is still called, but even though the Makefile _thinks_ it's doing a cross compilation, we override the CC with an environment variable and make it do a host compile anyway Sep 21 21:07:58 ecdhe: if you would like to use mkimage in your recipe - just add a line DEPENDS = "u-boot-mkimage-native" Sep 21 21:08:13 then you can call mkimage in your do_compile() task Sep 21 21:08:44 u-boot-mkimage-native is provided in u-boot tool via: PROVIDES_class-native = "u-boot-mkimage-native u-boot-mkenvimage-native" Sep 21 21:11:29 thanks RP zeddii, zandrey Sep 21 21:39:16 Anyone else seeing SSL expiry when trying to fetch a layer? Sep 21 21:39:16 layerindexlib.LayerIndexFetchError: Unable to fetch layerindex url https://layers.openembedded.org/layerindex/api/;branch=dunfell,gatesgarth: Unable to fetch layerindex url https://layers.openembedded.org/layerindex/api/: Unexpected exception: [Error 1] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1108) Sep 21 21:42:20 layers.openembedded.org key expired 20 minutes go Sep 21 21:42:23 ago **** BEGIN LOGGING AT Mon Sep 21 21:44:20 2020 Sep 21 21:44:45 jonmason: once that script starts moving time, let me know I desperately need that :) Sep 21 21:45:14 halstead: thanks :) Sep 21 21:45:17 RP, fray I've reloaded the cert and all is well. Sep 21 21:45:27 Thanks! Sep 21 21:50:28 thanks halstead Sep 21 21:52:50 jonmason: now about that meta-arm build warning ;-) (yes, I know its being worked on) Sep 21 21:56:08 RP: lesson learned, don't let stuff in on the promise of fixing things later, no matter how trivial. Because they seem to never find time to come back and fix it. And we have the choice of fixing it for them or making them do it. Sep 21 21:56:53 jonmason: I have learnt that the hard way too. Hence M3 being 2.5 weeks late! Sep 21 22:05:21 assign milesones to six months in the past Sep 21 22:05:54 you are an instant rock star. :-) Sep 21 22:07:44 * zeddii is already a rockstar Sep 21 22:08:34 * paulg giggles Sep 21 22:15:05 RP: So poky/4f568b44c6ff4e1cb47006efca2e3233035d9c77 moved sshkeygen to sshd.socket Sep 21 22:15:22 and sshd.socket is tied to socket.target Sep 21 22:15:31 whjich is tied to multi-user target Sep 21 22:15:43 RP: I think we should revert that change Sep 21 22:16:22 khem: JPEW and I discussed this. sshd.socket doesn't activate the socket, only listens as I understand it? Sep 21 22:16:53 does not seem that way Sep 21 22:17:20 it ties to socket.target Sep 21 22:19:51 systemd creates the socket and listens for a connection. When a connection is received, it spins up sshd.service to handle it Sep 21 22:21:06 see this http://sprunge.us/nOnvN7 Sep 21 22:21:21 JPEW: ideally yes Sep 21 22:25:07 in my case xserver-nodm.service was not in chain which was added by core-image-sato Sep 21 22:25:17 and that brings it into critical chain Sep 21 22:26:08 sockets.target really shouldn't be taking any time Sep 21 22:29:42 it really depends on what it depends on Sep 21 22:30:07 in sshd.socket we are asking for sshkeygen.service to run/finish Sep 21 22:30:14 so there we go Sep 21 22:53:03 RP: Wants=sshdgenkeys.service in sshd.socket means it will need sshdgenkeys.service be completed before it can activate **** BEGIN LOGGING AT Mon Sep 21 22:55:00 2020 Sep 21 22:57:07 khem: can we move it to the sshd.service then? **** BEGIN LOGGING AT Mon Sep 21 22:59:08 2020 Sep 21 22:59:52 if someone wants to generate them during first boot, they can use a fragment for sshd.socket in their own layer Sep 21 23:00:35 somthing like /etc/systemd/system/sshd.socket.d/key.conf and add the needed dependedency in key.conf Sep 21 23:01:21 but let the default be like it was which is to ghenerate the keys on first ssh requesrt Sep 21 23:02:50 during boot cpu is relatively busy and adding keygen operation to the mix of things its doing just makes boot slower for everyone Sep 21 23:04:38 thats what I am seeing, wehn I boot core-image-sato-sdk thr sshgenkey took 2min 46.961s ( sshdgenkeys.service ) but same take less than 2mins on core-image-minimal Sep 21 23:05:03 so my suggestion would be to revert 4f568b44c6ff4e1cb47006efca2e3233035d9c77 Sep 21 23:06:16 khem: is there a way we can trigger it right at the end of boot? Sep 21 23:06:38 khem: what we don't want is keygen happening at first ssh connection Sep 21 23:07:06 qemumips just gave <<< run_serial(): command timed out after 120 seconds without output >>> :) Sep 21 23:07:09 er, :( Sep 21 23:07:22 so we double the timeout, it still fails Sep 21 23:07:28 that is a fine idea, we have to think about it Sep 21 23:07:37 * RP -> sleep Sep 21 23:07:45 yeah 120s is not enough as you can see, it took amost 3mins in my case Sep 21 23:08:04 khem: sometimes we don't get the error though Sep 21 23:08:25 perhaps tester is sloppy too Sep 21 23:08:59 so before it sends out request for serial it might be delaying it long enough and it only will happen on first boot Sep 21 23:09:09 so if image is rerun then it will be fast Sep 21 23:09:22 khem: snapshot images, its always first boot Sep 21 23:10:37 right, I will think about launchin keygen service after serial-getty is up Sep 21 23:10:53 and perhaps try a run with 4f568b44c6ff4e1cb47006efca2e3233035d9c77 reverted Sep 21 23:10:57 and see if it is helping Sep 21 23:11:19 then we can tie another logic to preload it **** BEGIN LOGGING AT Tue Sep 22 00:01:28 2020 Sep 22 00:15:30 khem: Wants doesn't mean it has to wait, it just means it starts the generation Sep 22 00:16:10 Effectively, it's saying: "start ssh key generation no later than when I create the SSH sockets" Sep 22 00:16:42 But it is *not* saying "wait until key generation is complete before creating the socket". That would be After= **** BEGIN LOGGING AT Tue Sep 22 00:20:48 2020 **** BEGIN LOGGING AT Tue Sep 22 00:37:20 2020 Sep 22 00:45:31 khem, RP: Sent an RFC to the mailing list that I think will do what you are asking Sep 22 00:45:54 ...ish. systemd is really fuzzy on when "init" is "complete" :) **** BEGIN LOGGING AT Tue Sep 22 00:55:52 2020 **** BEGIN LOGGING AT Tue Sep 22 00:59:03 2020 Sep 22 02:43:34 rburton: am i rememberign wrong, or did you have something to lint python code that's in classes? Sep 22 02:46:28 RP: should think about running https://github.com/netromdk/vermin against bitbake (and possibly oe-core libs) as a CI/autobuilder operation to check against our defined dependent python versions **** BEGIN LOGGING AT Tue Sep 22 02:54:17 2020 **** ENDING LOGGING AT Tue Sep 22 02:59:57 2020