**** BEGIN LOGGING AT Tue Jan 05 03:01:24 2021 Jan 05 08:38:23 hello guys, thanks to @qschulz I finally got a wic image using this .wks template Jan 05 08:39:12 part /media/card --source bootimg-partition --ondisk mmcblk --fstype=vfat --label card --active --align 4 --size 128part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 --extra-space 2000 Jan 05 08:39:20 part /media/card --source bootimg-partition --ondisk mmcblk --fstype=vfat --label card --active --align 4 --size 128part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 --extra-space 2000 Jan 05 08:39:27 part /media/card --source bootimg-partition --ondisk mmcblk --fstype=vfat --label card --active --align 4 --size 128 Jan 05 08:39:31 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 --extra-space 2000 Jan 05 08:40:17 sorry for te repetition. Now the question is, How can I add a new partition with a specific set of files inside it ? Jan 05 08:40:33 I though something as: Jan 05 08:41:16 part /data --source rootfs --MYDIR=MYDATA --ondisk "mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200 Jan 05 08:43:08 but I don't find any reference to something like that Jan 05 09:42:17 Hello everyone and a happy new year :) Jan 05 09:43:02 dleppich: o/ happy new year 🎉 Jan 05 09:43:25 When I have two recipes present "mongodb_2.6.7.bb" and "mongodb_git.bb", which one will be chosen by bitbake? Jan 05 09:44:38 Will it try to determine the version number from git and then chose the higher one or does some other mechanism decide this? Jan 05 09:50:21 dleppich: version numbers, layer priorities and preferred providers play a role in the decision Jan 05 09:50:35 so answer depends on your setup Jan 05 09:52:00 mcfrisk: Thanks, I am preparing a yocto project update to a newer version. I guess I will see which version is chosen then :) Jan 05 09:54:25 dleppich: "bitbake -e mongodb" will show details without building. then you can change the decision by adjusting layer priorities, preferred probviders/versions and the actual version numbers (higher one will be taken) Jan 05 09:56:05 Unfortunately I am missing parts of the project and am not able to run bitbake right now. But I'll keep this in mind :) Jan 05 12:15:01 Has someone used the meta-freescale layer before? I'm trying to build a core-image-minimal for the imx8mmevk board using kas. One of the recipes states, that a dependency is not present. The meta-freescale layer states, that it depends on openembedded-core. When I try to include this layer, kas throws this error: "Multiple init scripts found (meta-openembedded-core vs. poky)." Is openembedded-core some kind of special layer? Jan 05 12:18:47 dleppich: openembedded-core is poky/meta Jan 05 12:19:05 (or more the opposite actually) Jan 05 12:19:56 So I can't use poky's meta and openembedded-core/meta at the same time? Jan 05 12:21:29 they are the same thing Jan 05 12:21:45 poky/meta is just openembedded-core included in another git repo, that's it Jan 05 12:23:51 Ah okay Jan 05 13:05:59 Would you know if the servers are down? I'm trying to rebuild dunfell-22.0.4 with systemd and I'm stuck at: "Checking sstate mirror object availibility" Jan 05 13:14:12 Sponge5: you could always disable them? Jan 05 13:17:27 RP: huh, why would it keep checking mirrors if they're down and the main server works? Jan 05 13:17:42 RP: anyway, thanks, that was the fix Jan 05 13:47:09 I'm rebuilding with systemd instead of sysvinit and it's taking pretty much the same time as building from scratch.. is this normal behavior? Jan 05 13:51:05 Sponge5: yes, it needs to rebuild glibc :( Jan 05 13:51:40 RP: oh well... Jan 05 13:51:50 rburton: I noticed "speed improvements" mentioned in the autoconf notes, was anything noticeable ? Jan 05 13:53:53 not massively, iirc Jan 05 13:54:31 rburton: fair enough, was just curious as its one of our major bottlenecks Jan 05 13:54:48 I can rebenchmark gettext and see what the numbers are Jan 05 14:11:28 Hi, I'm trying to update my build host from thud to support dunfell, and python3 fails with "The necessary bits to build these optional modules were not found: _dbm _gdbm". Is these some new requirements for host or what is missing? Jan 05 14:16:30 stuom1: well, if you're asking, first go through the required host packages in the dunfell documentation, so you have this out of the equation Jan 05 14:18:41 stuom1: I suspect that isn't the actual error Jan 05 14:26:36 stuom1: I had problems with gdbm when building zeus from scratch, but dunfell from scratch had no such problem Jan 05 14:27:19 I have installed all dependencies told in 3.1.1 mega manual, and that is the only error in the log Jan 05 14:27:51 stuom1: can you share the log for the failing task somewhere? Jan 05 14:30:03 here is the do_install log https://pastebin.com/Sab0zwwp Jan 05 14:31:20 little messed up the copypaste from terminal but maybe there is enough :P Jan 05 14:45:43 hello! I would need some piece of advice. Jan 05 14:46:32 RP: gettext configure is 10 seconds faster on my test machine (202 -> 195) Jan 05 14:46:33 I'm trying to figure out a way how to run a recipe that requires at the compile time some data from the rootfs Jan 05 14:46:59 nucatus: whatever data it needs, the recipe that provides it should put it in the sysroot Jan 05 14:47:17 and then your recipe can depend on that other recipe, and get the data from the sysroot Jan 05 14:48:12 rburton: thanks for the advice. The question is what if that data is modified by other recipes Jan 05 14:48:33 how are they doing that then? Jan 05 14:48:43 for instance, I want the last snapshot of the /etc/passwd just before do_rootfs Jan 05 14:48:59 well you can't know the contents of passwd in a recipe build Jan 05 14:49:14 as how can you make a package of your recipe to put in the rootfs if the rootfs doesn't exist yet because your package doesn't exist Jan 05 14:49:29 you can add a hook that runs at rootfs time Jan 05 14:50:18 I was investigating the `recrdeptask` avenue Jan 05 14:51:02 but my knowledge in that respect is pretty limited and this is why I decided to ask here. Jan 05 14:51:49 nucatus: package recipes, can't modify other packages' content (and a file is content) Jan 05 14:51:54 yeah that's not at all what you want Jan 05 14:52:03 nucatus: either a bbappend to fix it Jan 05 14:52:04 the workflow is recipes build packages, then packages are unpacked into a rootfs Jan 05 14:52:16 so *by definition* you can't look in the rootfs at package build time Jan 05 14:52:23 nucatus: else as rburton suggests, a rootfs hook in the image recipe Jan 05 14:52:44 ROOTFS_POSTPROCESS_COMMAND IIRC or something along those lines Jan 05 14:52:55 that's the brute force hammer Jan 05 14:53:01 pkg_postinst is the easier one Jan 05 14:53:09 is there a precise term to describe a board without its casing, for direct access to the pcb? "open" board? Jan 05 14:53:29 rburton: this is done in a bbappend of the original package recipe right? Jan 05 14:54:10 in this case i suspect nucatus wrote the recipe in the first place, so just put it in the .bb Jan 05 14:54:24 but yes a postinst is package-scope Jan 05 14:54:31 I read about the ROOTFS_POSTPROCESS_COMMAND, but I'm still confused about how that hook could call into the do_compile task of a recipe Jan 05 14:54:47 it can't Jan 05 14:55:00 you *really* can't at compile time know the contents of passwd Jan 05 14:55:11 rburton: they want to read /etc/passwd, so I guess this being so common it's already installed by some other recipe right? Jan 05 14:55:30 nucatus: why would you want to? what if passwd changes after compile? Jan 05 14:55:34 @RP did you see anything interesting in that do_install log? Only error message I see is about dbm and gdmb (but also says they are optional??) Jan 05 14:56:32 we would like to have a hash of the passwd, so that we make sure the file wasn't tampered at runtime Jan 05 14:56:45 stuom1: any particular DISTRO_FEATURES enabled or some bbappend for python3 by any chance? (don't know really but your log is not very helpful :/) Jan 05 14:56:53 (not your fault obviously :p) Jan 05 14:57:16 nucatus: if someone can tamper passwd can't they tamper the check too? Jan 05 14:57:34 change passwd then change the hash Jan 05 14:58:34 there are ways to avoid that, for instance to use that hash as a key to decrypt a vault Jan 05 14:59:11 and that check can't be tampered, because you're not checking against a known value Jan 05 15:00:01 nucatus: this smells very much like you want some secure boot and/or a RO filesystem (squashfs)? Jan 05 15:00:15 encrypt the value at rootfs time when you know the hash of passwd Jan 05 15:00:34 you don't know what packages are in the rootfs, so you don't know what passwd will contain, until rootfs time Jan 05 15:01:10 qschulz: yes, something along those lines Jan 05 15:01:15 rburton: that should make a real world difference to builds Jan 05 15:02:23 qschulz there was indeed a bbappend with DEPENDS_remove = "gdbm", no idea why or why it worked before. Thanks so much, would have never found that myself :P Jan 05 15:02:38 stuom1: sorry, pulled into meetings. Looking at the log, you're right, there isn't anything else in there. It says they're optional which makes things a bit strange Jan 05 15:02:39 @rburton ok, I'll investigate that route. Thanks! Jan 05 15:03:49 stuom1: if there was a missing/removed PACKAGECONFIG or EXTRACONF value in the python3 recipe in your old version of Yocto... maybe that made sense Jan 05 15:04:21 if it's not in your git history, I suggest you write proper commit logs (and/or ask people to do so) so you don't have to guess next time Jan 05 15:05:09 because there'll be a next time :) (I';ve been saved multiple times with my commit logs :) ) Jan 05 15:07:15 Should I define a new machine for the "open" version of my production board, used for development (with TTY access, tftpboot, etc. even though it's the same hardware)? Jan 05 15:08:06 v0n: a lot depends on how you're using it. It can sometimes be convenient to. One machine can inherit from another too Jan 05 15:08:44 Is there some required configuration that needs adding to local.conf before running `oe-selftest`? I have all wic tests which try to run qemu failing locally Jan 05 15:09:05 qschulz, thanks for tip. Git history seems to suggest it was removed because it is GPLv3 and thus not compatible with us...so for a reason. Now, how to remove it AND let python3 build, it is an optional module after all, and still fails without Jan 05 15:10:09 I wonder if it's getting stuck waiting for a sudo password to start qemu but I can't tell too clearly from the logs Jan 05 15:10:33 RP: indeed, I have trouble figuring out if it's clearer to have two distinct build directory for "" and "open" or if it's better to have some kind of logic based on features like enabling tftpboot in u-boot when debug-tweaks is present for example. Jan 05 15:10:43 paulbarker: we do usually run the gentaps script to presetup the interfaces Jan 05 15:11:29 v0n: unfortunately the answer isn't clear, it really depends on the circumstances Jan 05 15:12:21 stuom1: meta-gplv2 could be of help Jan 05 15:12:48 with everything it implies (outdated/unmaintained/unpatched SW) Jan 05 15:13:46 stuom1: otherwise, remove gdbm from PACKAGECONFIG in a bbappend of the python3 recipe Jan 05 15:14:01 (either with _remove (not super nice) or by overriding PACKAGECONFIG) Jan 05 15:14:14 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3_3.9.1.bb?h=master#n98 Jan 05 15:14:27 you want to change it probably at least for the class-target Jan 05 15:14:46 RP: I feel like having a logic based on features is neat, but more obscure, compared to stupidly defining a new machine (which appears easier to maintain) Jan 05 15:15:15 qschulz: thanks, I will look into it! Jan 05 15:27:04 kanavin: just looking at ppp which has released. Did you think any of our patches were needed? I can possibly see one but tempted to drop even that Jan 05 15:45:50 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/2885 Jan 05 15:48:48 sakoman: so who won the CVE raffle? how many fixes from how many people were done in the end? Jan 05 15:50:32 rburton: Just started tabulating all the entries, so it will a day or so for me to sort through it all Jan 05 15:50:46 cool Jan 05 15:51:21 rburton: yay :) Jan 05 15:52:04 sakoman: does rburton get negative points for all the ones he added? :) Jan 05 15:52:16 wait what?! Jan 05 15:52:21 Of course! It is only fair :-) Jan 05 16:03:35 YPTM: Scott Murray is on Jan 05 16:05:36 well crap. my perf build issues with v5.11 went away, after I switched to 5.10 to fix the vboxdriver build. Now I just have to look over my shoulder for when it comes back. Jan 05 16:18:00 is it better to split the conf into distro and machine layers, even though all go into a single private repository? Jan 05 16:20:13 distro layer, bsp layer and recipe layers that's basically the best practice IIRC Jan 05 16:31:50 any kas users here? Jan 05 16:32:19 a few Jan 05 16:34:13 Any input regarding MULTICONFIG vs. having multiple kas .yml files? Jan 05 16:34:33 surely they're different things? Jan 05 16:35:31 I was about to create 2 different kas files to build my distro on my board (both based on beaglebone) but it seems to be what MULTICONFIG is about? Jan 05 16:35:39 no Jan 05 16:35:57 multiconfig is building multiple configurations at the same time in the same build Jan 05 16:36:08 (I meant my "dev" board and "prod" boards which are both the same, based on bbb.) Jan 05 16:36:38 in your setup i'd have a common yml and then prod and dev ymls that include the common one Jan 05 16:39:17 rburton: hum ok. But since they are all bbb, shouldn't I share the build somehow? Jan 05 16:39:33 you can still share dldir/sstate Jan 05 16:39:40 multiconfig is about in the *same build* Jan 05 16:40:03 like, doing a build which in one bitbake will build firmware for one processor and userland for another Jan 05 16:40:06 (my board is a bbb with a custom daughter board, the dev board is physically the same and I'd like to build for bbb (no daughterboard support), dev and prod.) Jan 05 16:43:01 rburton: interesting, because the doc says that "Suggested practice dictates that you do not overlap the temporary directories used during the builds" even though you can define the same TMPDIR in some cases Jan 05 16:43:42 v0n: usually machine can overlap, distro changes can't Jan 05 16:44:20 zeddii: it'll wait for the most inconvenient time Jan 05 16:44:37 truth. Jan 05 16:45:05 mmh ok. I'll go with the simple split kas files that rburton suggested then, multiconfig seems error-prone to me at the moment. Jan 05 16:45:06 I just did a cleanall on both the kernel and perf, and it built. As you know, there's reproducibility issues with perf, so this may just be a symptom. I'll keep digging at it. Jan 05 16:47:57 v0n: its not error-prone, its just complications you don't need Jan 05 16:48:58 which may lead to me not using it right :D Jan 05 16:51:23 a kas file per machine and distro to be included look very intuitive anyway. Jan 05 16:55:05 they also make clear what the repository provides Jan 05 17:07:03 RP: I had checked that; all patches can be dropped except the one that redirects /etc/ppp/resolv.conf writing to /var (I think?) and even that should be dropped and properly rewritten by whoever needs it. Jan 05 17:18:28 zeddii: kernelci does not currently build/test perf, but it is on the list next (after kselftest). Everyone agrees with the pain. Jan 05 17:18:45 cool. Jan 05 17:19:37 nice Jan 05 17:30:31 kanavin: right, that was the one I wondered about. I will drop it as well... Jan 05 17:34:45 RP: if you're in update mood, you have other pending updates as well :) qemu at least Jan 05 17:37:13 kanavin: well, yes :) Jan 05 17:53:29 Hello, I got this message: ERROR: Layer filesystems-layer is not compatible with the core layer which only supports these series: dunfell (layer is compatible with gatesgarth hardknott) Jan 05 17:54:32 it looks like meta-openembedded and poky-dunfell are not compatible. But I cannot find documentation about this trouble Jan 05 17:55:33 Please, could someone gives me support? Jan 05 17:55:36 warlock: did you check out the dunfell branch of meta-openembedded ? Jan 05 17:56:23 yes I check for dunfell tags in the oe repository Jan 05 17:56:33 but I found nothing Jan 05 17:57:33 if you had, you won't see that message. Jan 05 17:57:38 http://cgit.openembedded.org/meta-openembedded/tree/meta-filesystems/conf/layer.conf?h=dunfell Jan 05 17:57:40 warlock: it's a branch, not a tag Jan 05 17:57:46 as you can see, if on the right branch, it is compatible. Jan 05 17:58:30 what you've described is master. Jan 05 17:58:38 http://cgit.openembedded.org/meta-openembedded/tree/meta-filesystems/conf/layer.conf?h=master Jan 05 18:00:11 oh, thank you mush Jan 05 18:00:24 sorry "much" Jan 05 18:01:04 ok, I have done git pull. So I have all branch in my local repo, is not it true? Jan 05 18:01:17 now I have to do git checkout Jan 05 18:01:52 but how can I find the right branch? Jan 05 18:03:14 have you worked with git based projects before ? This is standard git operations. There are some tools that can help with setup of layers (others can suggest them, I don't use them), and how to get the right branches may be covered in the yocto docs. Jan 05 18:03:41 https://github.com/siemens/kas is one setup tool. there are others. Jan 05 18:03:51 remotes/origin/dunfell Jan 05 18:03:58 is it correct? Jan 05 18:04:17 because poky is dunfell Jan 05 18:04:17 that means the branch is in the repo, but it isn't the one that is checked out, and hence used. Jan 05 18:04:47 git checkout -b origin/dunfell Jan 05 18:04:53 is not it true? Jan 05 18:05:12 yes, but meta-oe is a separate repository. you need to do that there as well. Jan 05 18:06:02 I have done but the file has not been updated :-( Jan 05 18:06:43 git status returned me "On branch origin/dunfell" Jan 05 18:07:15 it looks like correct, but the meta-filesystems/conf/layer.conf file still the same Jan 05 18:08:32 git checkout -b dunfell origin/dunfell is what I'd use. not all git versions (older ones in particular) detect and automatically track a remote branch of the same name when you check it out. Jan 05 18:08:34 I cloned meta-openembedded by another repo Jan 05 18:11:49 if I do git log, I can see the following row: Jan 05 18:11:50 69bae2a23 (HEAD -> dunfell, origin/master, origin/HEAD, origin/dunfell, master) Jan 05 18:12:30 it means origin/master is equal to origin/dunfell, is not it true? Jan 05 18:21:03 warlock: I think you have a broken meta-openembedded tree Jan 05 18:21:23 See https://git.openembedded.org/meta-openembedded/log/?h=dunfell for what the current HEAD of the dunfell branch should be Jan 05 18:27:31 thank you paul, I have cloned the repo again, but just with that branch Jan 05 18:27:44 it functions very well now :-) Jan 05 18:28:28 now I have another trouble: ERROR: ParseError at /home/warlock/YOCTO/sources/poky/meta-virtualization/recipes-core/busybox/busybox-initrd_1.32.0.bb:3: Could not include required file recipes-core/busybox/busybox_1.32.0.bb Jan 05 18:29:10 I tried to find the busybox_1.32.0.bb file, but It does not exist Jan 05 18:29:39 perhaps, I have to download it by some place Jan 05 18:40:30 kanavin: you shamed me into at least getting the recipe to do_compile :) Jan 05 18:51:47 warlock: Sounds like you may be mixing up layer branches again. I recommend cloning everything from the proper upstream repos and ensuring you have the same branch checked out for each layer Jan 05 19:01:24 kanavin: 5.2.0 moves to meson with some horrible mix of meson and their configure script :( Jan 05 19:02:18 RP: yeah, I saw that :-/ they claim that there are no visible user effects, which I'd say is highly optimistic Jan 05 19:02:46 RP: still meson-ish is in the long term better than 100% custom configure stuff Jan 05 19:05:09 kanavin: "no visible user effects" is a joke for us cross compiling Jan 05 19:05:56 "Could not invoke sanity test executable [] meson-private/sanitycheckc.exe" Jan 05 19:06:35 kanavin: meson-ish is looking like having to hack chunks of meson.bbclass into the qemu recipe Jan 05 19:06:55 anyway, food, this is going to take longer than I have time for. Jan 05 19:07:02 kanavin: I do have the patches rebased at least Jan 05 19:07:23 RP: yeah, looks like one of those updates that will take a while Jan 05 20:18:04 the fonts in core-image-sato look a bit out of order for me for few months see https://i.imgur.com/ugtnRRB.png Jan 05 20:18:08 any ideas ? Jan 05 20:42:52 khem: could be caused by cantarell-fonts version update? we jumped from 2016 straight to 2020 Jan 05 20:43:23 (and I'm planning to obsolete sato, weston all the way :) Jan 05 20:43:44 e.g. weston would be the new default image Jan 05 20:44:26 thats good I usually test wayland more than X11 but this is a regression been seen for quite few months Jan 05 22:03:12 * moto-timo will be glad when we can let X11 go away Jan 05 22:22:20 moto-timo: there are lots of things I wouldn't mind seeing fade away. I still kind of like X11 for some reason Jan 05 22:22:42 stockholm syndrome? :) Jan 05 22:25:43 fedora has switched to wayland and support for wayland is steadily improving in kwin/Plasma so I think 2021 will perhaps have few main distros shipping wayland by default alongside fedora Jan 05 22:26:10 things are definitely changing and we need to adapt too Jan 05 22:29:16 kanavin: the issue with qemu's meson integration is that it requires qemu's internal meson :/ Jan 05 22:30:08 RP: so it's not really meson at all, simply yet another homegrown build system :-/ Jan 05 22:31:19 kanavin: it may be if we don't specify a specific python interpreter, we can use our meson Jan 05 22:32:00 kanavin: its like I'm just randomly iterating config combinations to find one that works :/ Jan 05 22:32:09 HNY RP and folks! Jan 05 22:32:17 sgw: HNY! Jan 05 22:32:41 hello, I'm trying to use 96boards meta. It has a HOST_EXTRACFLAGS definition for its linux kernel, so that extract-cert doesn't fail while searching for openssl Jan 05 22:33:06 I updated kernel version from 4.14 to 5.4, and now it fails exactly because it can't find openssl/bio.h Jan 05 22:33:22 and the kernel's makefiles are getting empty HOST_EXTRACFLAGS Jan 05 22:33:34 So I found some time and looked at QMP stuff again, I found there is a pypi class for qmp (it's in the qemu source as well possibly). What is the best way to import some outside python and is it even allowed? Jan 05 22:33:47 however, newer meta-intel and meta-freescale doesn't seem to use HOST_EXTRACFLAGS. What am I missing? Jan 05 22:34:12 sgw: pure python or compiled modules? Jan 05 22:34:57 RP: pure python (from qemu source code here: ./python/qemu/qmp.py) Jan 05 22:35:14 the arm psuedo coreutils issue is looking like xattr symbol version differences arm vs x86 in case anyone is interested btw. Jan 05 22:35:22 sgw: that helps and should make it easier to use Jan 05 22:38:52 my thought might be to copy it to the lib/oeqa/utils and just make it part of our git with reference to it's source. Jan 05 22:39:45 sgw: what is the license? does it change much? would we install and use it alongside the qemu binaries? Jan 05 22:40:43 kanavin: this is going to be a total nightmare, I'm not sure upstream have even tried cross compiling with this :( Jan 05 22:41:34 RP: that's unfortunate, don't sink too much time into this Jan 05 22:41:43 but in the long term we need to keep up with qemu :-/ Jan 05 22:42:29 RP it's GPLv2, I guess we could install it, but where? It does not seem to get installed anywhere from qemu itself, so we would need to do it in the -native actions I guess Jan 05 22:43:09 sgw: right, extend qemu-system-native's do_install ? Jan 05 22:43:26 kanavin: I agree, we'll have to figure this out. It needs someone used to meson :/ Jan 05 22:45:24 kanavin: its because we don't use the "cross_prefix" mess in qemu's configure. I wonder if I can switch to that Jan 05 22:52:44 kanavin: something actually just compiled for target. I found the right hammer by going oldschool and patching it :) Jan 05 23:11:17 kanavin: I'll give it a go on the autobuilder overnight Jan 05 23:30:41 armpit: I cancelled a build and reported the issues on the list, ccing you so SWAT needed worry about that build Jan 05 23:37:28 armpit: well, I tried to cc you but added an extra character to the address and broke it Jan 05 23:37:33 time to sleep :) Jan 05 23:47:44 night Jan 06 00:05:03 thanks Jan 06 02:11:59 Hello, folks! I have the following errors in dmesg [ 8277.175241] Buffer I/O error on device mtdblock0, logical block 0 [ 8277.186081] end_request: I/O error, dev mtdblock0, sector 0 [ 8277.191689] FAT-fs (mtdblock0): unable to read boot sector Jan 06 02:12:07 are they something to worry about? Jan 06 02:44:38 How can i check where this is [ 32.556547] imx2-wdt 20bc000.wdog: Unexpected close: Expect reboot! **** ENDING LOGGING AT Wed Jan 06 02:59:58 2021