**** BEGIN LOGGING AT Thu Jul 28 02:59:57 2022 Jul 28 07:42:11 good morning Jul 28 12:08:26 I have an image built on kirkstone with debug-tweaks in EXTRA_IMAGE_FEATURES, and it has EXTRA_USER_PARAMS = "usermod -p $(openssl passwd somepassword) root;" Jul 28 12:08:38 yet logging in with that password doesn't work Jul 28 12:09:35 I did verify with bitbake -v that it does run `usermod -p root`, and I have verified with openssl that the password + the salt openssl picked hashes to the value which usermod was given Jul 28 12:09:41 what's going on here? Jul 28 12:23:40 hmm if I have `EXTRA_IMAGE_FEATURES ?= "debug-tweaks"` and then later `EXTRA_IMAGE_FEATURES += "package-management"` I suppose the += overwrites the ?= Jul 28 12:24:23 mort: bitbake -e is your friend Jul 28 12:25:11 hmm that does show IMAGE_FEATURES = " debug-tweaks package-management splash" Jul 28 12:48:10 don't you have to expliccitly allow root login?! Jul 28 12:52:41 yeah Jul 28 12:53:24 oh, you never said you're trying to login via ssh Jul 28 12:54:05 but if you are, dropbear has root login disabled in /etc/default/dropbear via DROPBEAR_EXTRA_ARGS="-w" Jul 28 12:56:51 I'm trying to log in via serial Jul 28 12:57:15 there is an ssh server on the system but the default firewall config disallows any incoming connections Jul 28 13:04:53 oh.. I know what it is Jul 28 13:05:30 it'll run some variant of usermod -p $1$jYIAbyr3$IUBDCbWgvqraUglaQ6eAd1, without shell escapes Jul 28 13:07:23 what it runs, after the openssl substitution and expanding the variables, is usermod -p /oa6/ root Jul 28 13:29:22 hey, can anyone explain this to me, I've started seeing this recently with mesa already in DL_DIR (i.e. if I remove mesa from DL_DIR and retrigger download, no problem) Jul 28 13:29:25 LANG=C git -c core.fsyncobjectfiles=0 fetch -f --progress https://gitlab.freedesktop.org/mesa/mesa.git refs/*:refs/* failed with exit code 128, no output Jul 28 13:29:36 git just hangs for a long time and then gets terminated Jul 28 13:29:55 if I run the command manually, no problem, it only goes nuts within bitbake Jul 28 13:31:29 marex: probably not the same root cause as you're using git fetcher, but check https://lists.openembedded.org/g/openembedded-core/message/167274 https://lists.openembedded.org/g/openembedded-core/message/167275 Jul 28 13:31:47 JaMa: well, look at that, mesa as well Jul 28 13:32:21 JaMa: I did suspect server-side issue, since it started happening when FDO last time had some sort of server outage and they moved things around Jul 28 13:32:48 yes, but don't know if git uses gnutls (git recipe uses openssl) Jul 28 13:33:10 JaMa: doesnt the git fetcher call host git ? Jul 28 13:33:49 git in gentoo also uses openssl, YMMV in your distro Jul 28 13:34:36 JaMa: checking, I think the CI where I see it uses ubuntu Jul 28 13:34:37 https://stackoverflow.com/questions/36939033/how-to-see-if-git-binary-is-using-openssl-or-gnutls Jul 28 13:35:02 so yes, it could be the same root cause Jul 28 13:35:59 so yes, it seems debian does use gnutls, ubuntu probably as well Jul 28 13:36:25 the SOF answer said ubuntu does as well Jul 28 13:36:50 Apparently in Ubuntu packages git is using gnutls, but on other platform openssl. However building from sources, even on Ubuntu, uses openssl ... Jul 28 13:38:23 in 22.10 docker container it's even weirder https://pastebin.com/NRU4sr7T Jul 28 13:38:49 it uses both ? Jul 28 13:39:34 sorry that was gentoo git, this is 22.10 https://pastebin.com/aKm7cJm7 Jul 28 13:40:01 apt-cache show git | grep ^Dep Jul 28 13:40:02 Depends: libc6 (>= 2.33), libcurl3-gnutls (>= 7.56.1), libexpat1 (>= 2.0.1), libpcre2-8-0 (>= 10.34), zlib1g (>= 1:1.2.0), perl, liberror-perl, git-man (>> 1:2.36.1+next.20220505), git-man (<< 1:2.36.1+next.20220505-.) Jul 28 13:41:22 heh https://gitlab.com/gnutls/gnutls/-/issues/1335 .. as far as I read it, it seems to be recurring unfixed issue then Jul 28 13:41:59 would it make sense to build its own git native and use that instead ? Jul 28 13:59:12 uh ... wait ... how come git outside of bitbake works and within the git fetcher it fails ? Jul 28 14:02:05 how exactly is values like EXTRA_USER_PARAMS expanded Jul 28 14:02:22 I think I have an issue with it messing with dollars Jul 28 14:14:45 I think the string in EXTRA_USERS_PARAMS ends up getting interpreted twice somehow and needs to be double-escaped? Jul 28 14:17:05 sounds about right Jul 28 14:17:43 the example in the documentation works, that looks like double escaped also Jul 28 14:17:57 https://docs.yoctoproject.org/ref-manual/classes.html?highlight=password#extrausers-bbclass Jul 28 14:19:44 the fun thing is, literally none of the myriad of stackoverflow answers and answers other places do this correctly Jul 28 14:20:21 they all either use -P, which was removed, or just do EXTRA_USERS_PARAMS = "usermod -p $(openssl passwd whatever) root;" without even trying to escape anything Jul 28 14:20:50 which maybe happens to work if the version of openssl it happens to use happens to default to a hashing scheme which doesn't contain dollars, but the default in kirkstone's openssl uses dollars **** ENDING LOGGING AT Fri Jul 29 02:59:56 2022