Re: [yocto] Gratitude
Thanks for all the work Jefro Thanks, Manju > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Osier-mixon, Jeffrey > Sent: Tuesday, June 05, 2018 11:42 PM > To: yocto@yoctoproject.org > Subject: [yocto] Gratitude > > I have been the Yocto Project community manager for over 7 years now, and have > had the pleasure of knowing or conversing individually with several hundred of > you. It is with mixed feelings that I must announce that I am stepping down > from > my position as the YP community manager and the Advisory Board chair after 7 > years, as I am taking on a new role in my job. > > I am very proud of the progress that the project has made, growing from a > small > set of build tools into an industry standard for building and working with > embedded Linux-based operating systems, supporting upstream projects including > the Linux kernel, hosting projects like opkg, and inspiring many very > successful > downstream projects, including AGL and OpenBMC among many others, and also > supporting countless configurations of hardware among seven different > architectures. We have also seen the community of users grow from fewer than > 1000 in 2010 to a large city-sized community, estimated in the tens of > thousands > of developers. > > Please continue to participate, collaborate, and come together as a community! > The Yocto Project is a success because every one of you participates. > > Jeffrey "Jefro" Osier-Mixon, Intel Corporation Open Source Community Ecosystem > Strategist > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] partitions resizing on the fly
Before asking this question to YOCTO community, the simplier question will be to ask if anybody knows any Linux distro (RHEL, Fedora, Debian, Ubuntu, SuSE etc.), with the feature which can do this? I am dealing with Linux for years, but such a mechanism did not see/experience. As well, never found anybody who asked this question as a such even for the normal distros. In contrary, it is impossible to expand/shrink dynamically active (mounted) partitions, AFAIK. For this to happen, somebody needs to invent the new dynamically expanding active fs (the feature of it), which can do that. Zoran ___ On Tue, Jun 5, 2018 at 4:59 PM, Mihaela Apetroaie-Cristea wrote: > Hi, > > Thanks for your answer. However, my question is whether there is a mechanism > such that the root will keep it’s minimal size, but be able to expand if > there is free space on the disk when new files are added (not necessarily to > occupy the whole free space), and shrink back if files are deleted. At the > moment I am happy to flash it with the minimal size, but it runs out of > space when I want to add something to the partitions, although there is > extra space on the disk that it could take. I know the implementation of > this is complicated, but I am wondering if anyone knows a solution for this. > > Thank you > > > On 5 Jun 2018, at 15:50, Iván Castell wrote: > > I managed this issue redefining this script in my custom layer (rocko > branch): > > scripts/lib/wic/canned-wks/mkefidisk.wks > > and setting a bigger size for the root partition (80GB in my case): > > part / --source rootfs --ondisk sda --fstype=ext4 --label platform > --align 1024 --use-uuid --size 8 > > Its not very nice, I know. But yocto can't know the real size of your root > device until writing the final image. > > I don't know if this is the best way to fix this but it works. > -- Ivan > > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] partitions resizing on the fly
On 06/05/2018 10:33 PM, Mihaela Apetroaie-Cristea wrote: Hello, I have a minimal yocto OS built for RPI, which has three partitions: boot, root and data. Is there any way to resize root and data such that root expands/flattens when files and others are added/deleted? Such that I can make more space for the data partition. At the moment my partitions are built with minimal size and I expand them with gparted after I added them on the sd card. But if I put my device somewhere unreachable it would be very useful to have a way to expand and flatten portions on the fly. Thank you, Mihaela It is said that btrfs supports such feature? Frankly I didn't try it out. Yocto supports building out btrfs images. Maybe you can give it a try? Best Regards, Chen Qi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] partitions resizing on the fly
Here is one good topic which I already know about. Virtual Box virtual disks' sizes! https://superuser.com/questions/1096549/file-based-dynamically-allocated-hard-disk-on-linux Two questions (stress on [1]): [1] VirtualBox allows you to create VDI, VMDK, and VHD types of hard-disks that can be either fixed- or dynamically-sized. Is there any way to make a file-based dynamically-sized hard-disk for use by a Linux host OS? (although I never the found way how to dynamically shrink VDI VD, the expansion is obvious) [2] Is it possible to employ any of these three types of file-based, dynamically-sized hard-disks outside of VirtualBox, on a Linux host OS? Zoran ___ On Wed, Jun 6, 2018 at 11:17 AM, ChenQi wrote: > On 06/05/2018 10:33 PM, Mihaela Apetroaie-Cristea wrote: >> >> Hello, >> >> I have a minimal yocto OS built for RPI, which has three partitions: boot, >> root and data. Is there any way to resize root and data such that root >> expands/flattens when files and others are added/deleted? Such that I can >> make more space for the data partition. At the moment my partitions are >> built with minimal size and I expand them with gparted after I added them on >> the sd card. But if I put my device somewhere unreachable it would be very >> useful to have a way to expand and flatten portions on the fly. >> >> Thank you, >> Mihaela > > It is said that btrfs supports such feature? Frankly I didn't try it out. > Yocto supports building out btrfs images. Maybe you can give it a try? > > Best Regards, > Chen Qi > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] YOCTO kernel PF_CAN feature set and socketCAN layer of the shelf?
Hello to YOCTO community, I am looking into the new CAN FD (CAN Flexible Data rate) protocol. It is very similar to classical CAN. I am wondering the following (I'll ask very basic questions, just to see if I am on the right tracks): [1] Do YOCTO kernels have CAN drivers left as mandatory drivers in the drivers/ tree (CAN drivers exist on kernel.org kernels)? [2] If YES, are these drivers enabled by default, or I need to enable them? Anybody to quickly refresh me how to manipulate make menuconfig in YOCTO tree? I also need the feature called: SocketCAN. The following questions arise: [3] Do we have in the socket I/Fs added PF_CAN protocol family handling? https://en.wikipedia.org/wiki/SocketCAN [4] Does added SocketCAN layer exist, which covers this topic? It'll be layer on the top of the YOCTO-BSP layer, my best guess. Any examples, using such a layer? Or any Open Source example(s) of such a layer? Thank you, Zoran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gratitude
Hi Jeffrey, Many thanks for the hard work over the years. The Yocto Project has helped me a lot with creating great pieces of software for several clients. Good luck and a lot of fun with your new job! Cheers, Bas. On 2018-06-06 08:42, Osier-mixon, Jeffrey wrote: I have been the Yocto Project community manager for over 7 years now, and have had the pleasure of knowing or conversing individually with several hundred of you. It is with mixed feelings that I must announce that I am stepping down from my position as the YP community manager and the Advisory Board chair after 7 years, as I am taking on a new role in my job. I am very proud of the progress that the project has made, growing from a small set of build tools into an industry standard for building and working with embedded Linux-based operating systems, supporting upstream projects including the Linux kernel, hosting projects like opkg, and inspiring many very successful downstream projects, including AGL and OpenBMC among many others, and also supporting countless configurations of hardware among seven different architectures. We have also seen the community of users grow from fewer than 1000 in 2010 to a large city-sized community, estimated in the tens of thousands of developers. Please continue to participate, collaborate, and come together as a community! The Yocto Project is a success because every one of you participates. Jeffrey "Jefro" Osier-Mixon, Intel Corporation Open Source Community Ecosystem Strategist -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gratitude
On Wed, 2018-06-06 at 06:42 +, Osier-mixon, Jeffrey wrote: > I have been the Yocto Project community manager for over 7 years now, > and have had the pleasure of knowing or conversing individually with > several hundred of you. It is with mixed feelings that I must > announce that I am stepping down from my position as the YP community > manager and the Advisory Board chair after 7 years, as I am taking on > a new role in my job. Thanks for everything you've done for the project, I'm sorry to see you move on. As well as the obvious things, I know there are a lot of behind the scenes things which happen which all keep the project running smoothly. Good luck with the new role and I hope to see you around at conferences etc. in the future, its a small world! :) Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gratitude
Good Luck, Jeffrey... I do not know you, but (knowing well about INTEL inside) I know that you liked what you did. I do sincerely hope that on the new INTEL assignment, you'll find Peace of Mind and R&D Joy! > ...I know there are a lot of behind the scenes things which > happen which all keep the project running smoothly. There are many players behind the scenes. Not only INTEL. This is the assurance (my best guess) of said/written above. Time Will Tell. Zoran ___ On Wed, Jun 6, 2018 at 2:19 PM, Richard Purdie wrote: > On Wed, 2018-06-06 at 06:42 +, Osier-mixon, Jeffrey wrote: >> I have been the Yocto Project community manager for over 7 years now, >> and have had the pleasure of knowing or conversing individually with >> several hundred of you. It is with mixed feelings that I must >> announce that I am stepping down from my position as the YP community >> manager and the Advisory Board chair after 7 years, as I am taking on >> a new role in my job. > > Thanks for everything you've done for the project, I'm sorry to see you > move on. As well as the obvious things, I know there are a lot of > behind the scenes things which happen which all keep the project > running smoothly. Good luck with the new role and I hope to see you > around at conferences etc. in the future, its a small world! :) > > Cheers, > > Richard > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Resolved] Re: cgroups and iptables problems running docker - maybe my config wrong?
On 2018-06-06 10:33 AM, Jakob Hasse wrote: Hello Bruce, hello Yoctoers, my problem is solved. It was the kernel options. I added all additional kernel options which this check-script here suggests: https://github.com/moby/moby/blob/master/contrib/check-config.sh. This script was a big help Finally, docker runs, with one ERROR message and one WARNING though, but it does :) If I have more problems, I'll come back to the list. Great news. I was about to do another run of this, and still will, but this is good to know. Definitely let us know what breaks next :D Bruce Thank you for the help so far. All the Best, Jakob On 05.06.2018 18:23, Jakob Hasse wrote: Hello, right now, there is no insmod warning anymore, only iptables does still not work with the nat table: root@ccimx6uluvalue:~# dockerd INFO[] libcontainerd: new containerd process, pid: 1003 WARN[] containerd: low RLIMIT_NOFILE changing to max current=1024 max=4096 INFO[0001] [graphdriver] using prior storage driver: overlay2 INFO[0001] Graph migration to content-addressability took 0.00 seconds WARN[0001] Your kernel does not support cgroup memory limit WARN[0001] Unable to find cpu cgroup in mounts WARN[0001] Unable to find blkio cgroup in mounts WARN[0001] Unable to find cpuset cgroup in mounts WARN[0001] mountpoint for pids not found INFO[0001] Loading containers: start. Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain: iptables failed: iptables --wait -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (exit status 3) Best Regards, Jakob On 05.06.2018 18:11, Jakob Hasse wrote: On 04.06.2018 17:53, Bruce Ashfield wrote: On 2018-06-01 12:15 PM, Jakob Hasse wrote: Hello Bruce, Thank you very much for the quick response. I tried to built in the kernel changes. But the iptables error persists. I double checked over the weekend, and I have no problems with linux-yocto + the meta-virtualization fragment and docker. Thanks a lot for the work! Did you say that you confirmed on target via /proc/config.gz that all the options you tried to enable are still present in the running kernel ? I double checked with /proc/config.gz and all the modules are builting except for CONFIG_NF_TABLES, CONFIG_NF_TABLES_IPV4. The last two might not even exists, I was so desperate that I put everything into the configuration which I could find related to NAT. Some modules are builtin as modules instead (...=m instead of ...=y), however. Eventually, I tried to enable systemd again and it still breaks my build -.-: test$ bitbake core-image-base NOTE: Started PRServer with DBfile: /home/build/test/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40169, PID: 2335 Loading cache: 100% || Time: 0:00:00 Loaded 3023 entries from dependency cache. Parsing recipes: 100% |##| Time: 0:00:01 Parsing of 2194 .bb files complete (2193 cached, 1 parsed). 3024 targets, 146 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.36.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-dey-linux-gnueabi" MACHINE = "ccimx6ulstarter" DISTRO = "dey" DISTRO_VERSION = "2.4-r1" TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard cortexa7" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "HEAD:3befe6d7b7fa8c8481519aa8dd0cae52207ad339" meta-oe meta-python meta-networking meta-webserver = "HEAD:dacfa2b1920e285531bec55cd2f08743390aaf57" meta-qt5 = "HEAD:cfe02f26de53e5c20e6f9555059cbaaf5ab9b22f" meta-swupdate = "HEAD:6e4eab4f475b0129d6510815a3bbc4748c97dbbe" meta-freescale = "HEAD:d6141ea291a1ac9ab8fb1dd1110d408f840fda57" meta-fsl-demos = "HEAD:0ec6d7e206705702b5b534611754de0787f92b72" meta-digi-arm meta-digi-dey = "HEAD:1246ecff2cecea9247d94f36385608ac844d7abb" Initialising tasks: 100% |###| Time: 0:00:04 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: core-image-base-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/yum.repos.d --repofrompath=oe-repo,/home
Re: [yocto] partitions resizing on the fly
On 06/06/2018 04:46 AM, Zoran Stojsavljevic wrote: > Before asking this question to YOCTO community, the simplier question > will be to ask if anybody knows any Linux distro (RHEL, Fedora, > Debian, Ubuntu, SuSE etc.), with the feature which can do this? > > I am dealing with Linux for years, but such a mechanism did not > see/experience. As well, never found anybody who asked this question > as a such even for the normal distros. > > In contrary, it is impossible to expand/shrink dynamically active > (mounted) partitions, AFAIK. man resize2fs :) A carefully crafted script that uns on first boot should expand a partition to fill all available space. Philip > > For this to happen, somebody needs to invent the new dynamically > expanding active fs (the feature of it), which can do that. > > Zoran > ___ > > On Tue, Jun 5, 2018 at 4:59 PM, Mihaela Apetroaie-Cristea > wrote: >> Hi, >> >> Thanks for your answer. However, my question is whether there is a mechanism >> such that the root will keep it’s minimal size, but be able to expand if >> there is free space on the disk when new files are added (not necessarily to >> occupy the whole free space), and shrink back if files are deleted. At the >> moment I am happy to flash it with the minimal size, but it runs out of >> space when I want to add something to the partitions, although there is >> extra space on the disk that it could take. I know the implementation of >> this is complicated, but I am wondering if anyone knows a solution for this. >> >> Thank you >> >> >> On 5 Jun 2018, at 15:50, Iván Castell wrote: >> >> I managed this issue redefining this script in my custom layer (rocko >> branch): >> >> scripts/lib/wic/canned-wks/mkefidisk.wks >> >> and setting a bigger size for the root partition (80GB in my case): >> >> part / --source rootfs --ondisk sda --fstype=ext4 --label platform >> --align 1024 --use-uuid --size 8 >> >> Its not very nice, I know. But yocto can't know the real size of your root >> device until writing the final image. >> >> I don't know if this is the best way to fix this but it works. >> -- Ivan >> >> >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gratitude
Jefro, Sad to see you step down. You have been great for the project and especially for carrying the "documentation banner" truly caring about that aspect. I hope you do great in your next role and we will keep in touch. Scott On Wed, Jun 6, 2018 at 6:21 AM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > Good Luck, Jeffrey... > > I do not know you, but (knowing well about INTEL inside) I know that > you liked what you did. I do sincerely hope that on the new INTEL > assignment, you'll find Peace of Mind and R&D Joy! > > > ...I know there are a lot of behind the scenes things which > > happen which all keep the project running smoothly. > > There are many players behind the scenes. Not only INTEL. This is the > assurance (my best guess) of said/written above. > > Time Will Tell. > Zoran > ___ > > On Wed, Jun 6, 2018 at 2:19 PM, Richard Purdie > wrote: > > On Wed, 2018-06-06 at 06:42 +, Osier-mixon, Jeffrey wrote: > >> I have been the Yocto Project community manager for over 7 years now, > >> and have had the pleasure of knowing or conversing individually with > >> several hundred of you. It is with mixed feelings that I must > >> announce that I am stepping down from my position as the YP community > >> manager and the Advisory Board chair after 7 years, as I am taking on > >> a new role in my job. > > > > Thanks for everything you've done for the project, I'm sorry to see you > > move on. As well as the obvious things, I know there are a lot of > > behind the scenes things which happen which all keep the project > > running smoothly. Good luck with the new role and I hope to see you > > around at conferences etc. in the future, its a small world! :) > > > > Cheers, > > > > Richard > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Where to make image dependent kernel changes while hardware stays same
Hello, we would like to have different images with different kernel configs/device trees. E.g., we would like to have systemA with uart2 and systemB without uart2 but spi1 instead, with all the different configurations and device trees. The hardware does not change in this case. How can I make such kernel changes depending on the currently used image? My first trail was to make different machine configs anyway although technically the hardware doesn't change. Then I can append different kernel configs in the kernel recipe like this: SRC_URI_append_systemA = " file://defconfig" SRC_URI_append_systemB = " file://defconfig" ...with the corresponding defconfigs in their machine specific subdir. But maybe there is a better way to reflect these kind of changes? All the Best, Jakob -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Resolved] Re: cgroups and iptables problems running docker - maybe my config wrong?
Hello Bruce, hello Yoctoers, my problem is solved. It was the kernel options. I added all additional kernel options which this check-script here suggests: https://github.com/moby/moby/blob/master/contrib/check-config.sh. This script was a big help Finally, docker runs, with one ERROR message and one WARNING though, but it does :) If I have more problems, I'll come back to the list. Thank you for the help so far. All the Best, Jakob On 05.06.2018 18:23, Jakob Hasse wrote: Hello, right now, there is no insmod warning anymore, only iptables does still not work with the nat table: root@ccimx6uluvalue:~# dockerd INFO[] libcontainerd: new containerd process, pid: 1003 WARN[] containerd: low RLIMIT_NOFILE changing to max current=1024 max=4096 INFO[0001] [graphdriver] using prior storage driver: overlay2 INFO[0001] Graph migration to content-addressability took 0.00 seconds WARN[0001] Your kernel does not support cgroup memory limit WARN[0001] Unable to find cpu cgroup in mounts WARN[0001] Unable to find blkio cgroup in mounts WARN[0001] Unable to find cpuset cgroup in mounts WARN[0001] mountpoint for pids not found INFO[0001] Loading containers: start. Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain: iptables failed: iptables --wait -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (exit status 3) Best Regards, Jakob On 05.06.2018 18:11, Jakob Hasse wrote: On 04.06.2018 17:53, Bruce Ashfield wrote: On 2018-06-01 12:15 PM, Jakob Hasse wrote: Hello Bruce, Thank you very much for the quick response. I tried to built in the kernel changes. But the iptables error persists. I double checked over the weekend, and I have no problems with linux-yocto + the meta-virtualization fragment and docker. Thanks a lot for the work! Did you say that you confirmed on target via /proc/config.gz that all the options you tried to enable are still present in the running kernel ? I double checked with /proc/config.gz and all the modules are builting except for CONFIG_NF_TABLES, CONFIG_NF_TABLES_IPV4. The last two might not even exists, I was so desperate that I put everything into the configuration which I could find related to NAT. Some modules are builtin as modules instead (...=m instead of ...=y), however. Eventually, I tried to enable systemd again and it still breaks my build -.-: test$ bitbake core-image-base NOTE: Started PRServer with DBfile: /home/build/test/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40169, PID: 2335 Loading cache: 100% || Time: 0:00:00 Loaded 3023 entries from dependency cache. Parsing recipes: 100% |##| Time: 0:00:01 Parsing of 2194 .bb files complete (2193 cached, 1 parsed). 3024 targets, 146 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.36.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-dey-linux-gnueabi" MACHINE = "ccimx6ulstarter" DISTRO = "dey" DISTRO_VERSION = "2.4-r1" TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard cortexa7" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "HEAD:3befe6d7b7fa8c8481519aa8dd0cae52207ad339" meta-oe meta-python meta-networking meta-webserver = "HEAD:dacfa2b1920e285531bec55cd2f08743390aaf57" meta-qt5 = "HEAD:cfe02f26de53e5c20e6f9555059cbaaf5ab9b22f" meta-swupdate = "HEAD:6e4eab4f475b0129d6510815a3bbc4748c97dbbe" meta-freescale = "HEAD:d6141ea291a1ac9ab8fb1dd1110d408f840fda57" meta-fsl-demos = "HEAD:0ec6d7e206705702b5b534611754de0787f92b72" meta-digi-arm meta-digi-dey = "HEAD:1246ecff2cecea9247d94f36385608ac844d7abb" Initialising tasks: 100% |###| Time: 0:00:04 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: core-image-base-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/yum.repos.d --repofrompath=oe-repo,/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/oe-rootfs-repo --installroot=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/ro
Re: [yocto] Gratitude
Jefro, I am very sorry to see you go. I have very much enjoyed working with you from the beginning while still at the Linux Foundation. I cannot express enough gratitude for all the valuable work you have done for this community and for me personally by diligently reviewing the book and giving me tips. Thank you so much. You will be missed. Rudi On Tue, Jun 5, 2018 at 11:42 PM, Osier-mixon, Jeffrey < jeffrey.osier-mi...@intel.com> wrote: > I have been the Yocto Project community manager for over 7 years now, and > have had the pleasure of knowing or conversing individually with several > hundred of you. It is with mixed feelings that I must announce that I am > stepping down from my position as the YP community manager and the Advisory > Board chair after 7 years, as I am taking on a new role in my job. > > I am very proud of the progress that the project has made, growing from a > small set of build tools into an industry standard for building and working > with embedded Linux-based operating systems, supporting upstream projects > including the Linux kernel, hosting projects like opkg, and inspiring many > very successful downstream projects, including AGL and OpenBMC among many > others, and also supporting countless configurations of hardware among > seven different architectures. We have also seen the community of users > grow from fewer than 1000 in 2010 to a large city-sized community, > estimated in the tens of thousands of developers. > > Please continue to participate, collaborate, and come together as a > community! The Yocto Project is a success because every one of you > participates. > > Jeffrey "Jefro" Osier-Mixon, Intel Corporation > Open Source Community Ecosystem Strategist > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- *Rudolf J. Streif* -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gratitude
Jefro you have been very helpful all along has been great working with you. Your contributions have been significant for project, thanks for all your contributions. Small world I am sure I will see you around :) -Khem On Tue, Jun 5, 2018 at 11:42 PM, Osier-mixon, Jeffrey wrote: > I have been the Yocto Project community manager for over 7 years now, and > have had the pleasure of knowing or conversing individually with several > hundred of you. It is with mixed feelings that I must announce that I am > stepping down from my position as the YP community manager and the Advisory > Board chair after 7 years, as I am taking on a new role in my job. > > I am very proud of the progress that the project has made, growing from a > small set of build tools into an industry standard for building and working > with embedded Linux-based operating systems, supporting upstream projects > including the Linux kernel, hosting projects like opkg, and inspiring many > very successful downstream projects, including AGL and OpenBMC among many > others, and also supporting countless configurations of hardware among seven > different architectures. We have also seen the community of users grow from > fewer than 1000 in 2010 to a large city-sized community, estimated in the > tens of thousands of developers. > > Please continue to participate, collaborate, and come together as a > community! The Yocto Project is a success because every one of you > participates. > > Jeffrey "Jefro" Osier-Mixon, Intel Corporation > Open Source Community Ecosystem Strategist > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] partitions resizing on the fly
ChenQi wrote: > On 06/05/2018 10:33 PM, Mihaela Apetroaie-Cristea wrote: >> Hello, >> >> I have a minimal yocto OS built for RPI, which has three partitions: >> boot, root and data. Is there any way to resize root and data such that >> root expands/flattens when files and others are added/deleted? Such that >> I can make more space for the data partition. At the moment my partitions >> are built with minimal size and I expand them with gparted after I added >> them on the sd card. But if I put my device somewhere unreachable it >> would be very useful to have a way to expand and flatten portions on the >> fly. >> >> Thank you, >> Mihaela > It is said that btrfs supports such feature? Frankly I didn't try it out. > Yocto supports building out btrfs images. Maybe you can give it a try? With btrfs you can have multiple partitions (on the same or different disks), the partitions can form a single pool. In this single pool you can have multiple volumes. Space from the pool gets allocated to the files in a particular volume. The volume size is not really restricted, but when you ask df, it will give you the size of the pool. With 3 volumes on the partition you might think you have 3x the pool available, which is not true of course. If you run out of space it will hit all volumes at the same time. But you can then (temporarily) add f.i. a usb disk to instantly add space to all volumes. > Best Regards, > Chen Qi > -- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to make image dependent kernel changes while hardware stays same
On Wed, Jun 6, 2018 at 9:03 AM, Jakob Hasse wrote: > Hello, > > we would like to have different images with different kernel configs/device > trees. E.g., we would like to have systemA with uart2 and systemB without > uart2 but spi1 instead, with all the different configurations and device > trees. The hardware does not change in this case. > > How can I make such kernel changes depending on the currently used image? You can't. The kernel build can be influenced by global config files such as the distro config, the machine config, local.conf, etc, but it's not influenced by the image you choose to build. > My first trail was to make different machine configs anyway although > technically the hardware doesn't change. That's OK. There's no rule that says machine config files can only contain HW related options. You can think of the machine config files as just being a place to put global build configuration which is one level below the distro configuration. > Then I can append different kernel > configs in the kernel recipe like this: > SRC_URI_append_systemA = " file://defconfig" > SRC_URI_append_systemB = " file://defconfig" > ...with the corresponding defconfigs in their machine specific subdir. Putting the machine specific defconfig files into machine specific subdirectories is enough - you don't need to use machine specific appends to SRC_URI. For reference, see "log.do_patch" in the kernel working directory to see the file search paths. The machine specific paths will be checked first for every file in SRC_URI automatically. > But maybe there is a better way to reflect these kind of changes? There are other ways, but the way you have chosen is a good one. > > All the Best, > Jakob > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-intel][PATCH] mce-test: add it
Hi Dengke, On 06/01/2018 05:51 PM, Dengke Du wrote: > +SRC_URI = > "git://git.kernel.org/pub/scm/linux/kernel/git/gong.chen/mce-test.git;protocol=git > \ > + file://makefile-remove-ldflags.patch \ > + " > +# Use the commit date of SRCREV in PV. > +# > +SRCREV = "b3fdfaa7a025b68f30913c9cc7a8fe4ae9c7ed7f" This looks like a very old revision. Should this also be fetching from: https://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git/log/ Also, this should probably be sent to openembedded-devel list. Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
