**** BEGIN LOGGING AT Wed Oct 10 03:00:00 2018 Oct 10 07:32:53 I'm having problems booting my yocto image on an intel atom cpu. Using an old-style msdos partition table is ok, but when I change the wks script to use "--ptable gpt", the system drops me to an EFI shell. Any ideas ? Oct 10 09:23:33 hi guys. anybody here can give me some barebox advice? i got a phycore imx6ul mounted on a custom board. i've confirmed that the boot params are set correctly but this is what i see in console: https://pastebin.com/jRV6GHhQ Oct 10 09:24:28 basically there's some ubi device it detects but can't find kernel there? there's no actual "spi", "mmc" or "net" targets here, i just wanna boot from nand Oct 10 09:30:56 waterscale: should exist a barebox channel Oct 10 09:35:00 i'll repost it there, thanks Oct 10 14:13:05 hi Oct 10 14:14:09 I am still struggling with migration from 2.0 to 2.5.1 and ran into a strange issue; is it somehow possible that DATETIME changes during the build? I thought its supposed to stay fixed for the entire build duration; we have a bbclass that adds a couple of links after the image has been built Oct 10 14:14:38 and it does not work anymore because this class somehow ends up with a DATETIME that differs from the one in the image Oct 10 14:15:02 I'm using IMAGE_NAME whic DATETIME is a part of Oct 10 15:36:28 i'd change the bbclass to do the linking at a different point in the build process, ideally right after the image itself is constructed Oct 10 15:36:33 add it to IMAGE_CLASSES, ... Oct 10 16:28:44 kergoth: thaank you, I'll try that, currently I had it in do_image_complete postfuncs Oct 10 16:28:53 will move to IMAGE_CLASSES and see what happens Oct 10 16:29:17 IMAGE_CLASSES is just how the class gets inherited, but yeah i'd consider moving it to the individual do_image_ tasks rather than complete.. still a bit odd, though.. Oct 10 16:29:19 hmm Oct 10 16:29:40 i just figured moving the link closer to when the actual file is created would sidestep the issue Oct 10 16:42:27 the linking is generic, the generated files done in do_image_ext3 etc, i.e. by fs type Oct 10 16:42:45 we were just looping through the fstypes with IMAGE_NAME in the deploy directory Oct 10 16:43:11 ah Oct 10 16:43:48 and in 2.0 we had it in the do_rootfs postfunc hook Oct 10 16:43:58 which worked just fine Oct 10 16:49:38 but isnt DATETIME supposed to stay fix throughout the entire build process or are there exceptions? Oct 10 16:49:52 just trying to understand why I ran into this in the first place **** ENDING LOGGING AT Thu Oct 11 02:59:59 2018