 Hello, thanks for joining me on this conference. I will present you today how to build a non-bedded Debian or a Brintery system with Elbe. It's my first presentation on such a conference, so please excuse me if I hesitate a bit or anything else. I will try to do my best. So let's get over it. So I'm Kori Masal. I'm an embedded Linux engineer at Butlin since the beginning of this year, just the beginning of COVID. I work on different projects with different embedded build systems. So Butlin is an open source contributor for lots of different open source projects and I contributed to support Ubuntu in Elbe. So I work on two projects with Elbe, so in an ARM32 EMX6 and Rackchip RK3399 platform. I'm living in Toulouse and I'm in the office of Columbia of Butlin. So what is the content of this presentation? So it's first, I will first present you the different available options on how to build a non-bedded system. Then I will make another review of Elbe. Then I'll just explain how to build a simple Debian or Ubuntu image with Elbe and how to customize the image to fit what you want. So what are the different possibilities to build a distribution for a number of boards? So the first option and the hardest way to do it is to build everything manually. So the advantages are it's full-flexible and you learn a lot about how to destroy the content, the aspect of it, what is a toolchain, how it's made, etc. The cons are it's hard, so you need to understand a lot of things before to make a good distribution. It's not really reproducible. There is no compatibility between versions, etc. The second option is use binary distribution. So like Debian Ubuntu Fejera, which already exists. So it's easy to create and extend. There is already a large set of package and it's the security updates for this package are made quite often. So it's really robust and it's good for a non-embedded expert because it's like a desktop. So the cons are it's hard to customize and to optimize for a number of boards. Indeed, a number of boards may not have the power like a desktop, as a computer. So some binary distribution will not work well on such a small embedded board. It's often a large system. It has a lot of dependency and it's not available for all the different architecture. And so the most common option for an embedded board is to use a build system like Buildroot, Yocto, PtexDix, etc. The interest of it is its full flexibility. You can't configure it as you want and some of them are maybe more complicated than others, but it's really full flexible. It's also fully reproducible. You can easily have a toolchain. It uses cross-compilation and there is a lot of features. The con is that it has not regular security updates like in the distribution like a Debian and it takes time to build your distribution. So we will focus on how to build a Debian build system. It's our point today. So there is several projects that have been tried to automate the process. Of course, first, you may try to use homemade scripts, but it's hard and it's not common for every project and everybody has its own scripts. So it's not really maintainable. The second is Albo, so it's the focus of this call today. It's a new build system. It's first released in 2015. It's mostly a pattern code that uses a generic Debian tool like Debootstrap, Schrot on others. First, it only supports Debian, but now it supports Ubuntu. I contributed to this book. So you may try to build for other distribution, but you might encounter some issue, maybe, or maybe it will work well. Another tool is DeboS. It's also interesting because you can create an image and a customisable image, but the main advantage, as I said, is to build your own package from source. You can manage easily, easily sends, use several architecture and tune your root FS. So it's easily customizable. So let's focus on the Albo process. Albo, when you first run it, it will create an initvm virtual machine for building a root FS inside of it. So it's like this square. So it's a Debian initvm. So all the work will happen in this initvm. When then you want to create an image for your project or your board, you will create a project in this. When you will submit an XML file to Albo, and Albo will create a project in its initvm, in this project it will create a different root for a different process. So the main is for the sysroot which will be installed in the vault. So the steps are to use the bootstrap, then update the mirror of the sysroot, then install the desired packages, tune the root FS in like firetuning. When all the sysroot is undone and it is customized as you want, it will generate an image or a tar or a newbie image as you describe it in the XML and it will output in a build repository the image corresponding to the final image. So as I said, the first use of Albo is to create the initvm. So the first command you will make is Albo initvm create. You will do this command only once because after the initvm has been created, you just have to use it. So if you rebuild your computer, you just need to start the initvm. So start the Debian virtual machine. In Albo, all the configurations description of your image is made is described in a XML file. So after you create the initvm, you can submit whatever XML file you want to create an image or distribution for the board. So the first example is to create an image for the Bigelbund black. It takes about 50 minutes on my computer and another is to make an Ubuntu distribution image. All these two are in the Albo source, in the example directory. The Ubuntu example does not have bootloader or canal, it's only the rootfs. So after you run this command, it will build and you will have a result directory which will have the timestamp in its name. The difference file in this directory are bincederum and sourcecederm iso which are a mirror of all the packages used to create your distribution, your image, so that later you can reuse this package. There is also the image.jz which is the final image that you want to use and maybe that you want to flash on your board. There is a rural license file to add the license description of all your packages for the main route, for the this route host, target, etc. You have the source XML file which describes all the packages and their versions. This Albo build directory has been made with builder's description, so we have also this two file. The one is an extraction of the sysroute and the other is a script, a Yocto-like script to install where you want a toolchain. The toolchain made with suite the image described in the XML file. I said the description of your image is use.xml file, so now we will dive into this how to say it. We will just explain how to what the content of this XML. First, there is a global node which embraces the whole XML file. This is the first of a big edge, so let it like it is in the example. Then you have the project node. This node will describe the name of the project, the description and other information of this project. So also the architecture, the mirror to use, also where to download your package and which should to use. Then the interesting node is the target node. It's really where you will customize and describe the content of your image, of your distribution. It has for example the password, the console option, the image node, so how will it be generate your image and which file system to use. All the fighting, the tune of your root FS will be in this node. And then the list of your package that you want to install. So I first have presented you the submit command. The submit is good when you want to build an image from scratch. So you just have to submit the XML file and it will do all the builds. So you just have to wait until it's end and you will have your result directory. But when you want to work on this, on your distribution, you may want to not build all each time. So the good manner is to use Elbe control command. Because it will not build everything, it just will update the root of the project and other things. So to use this control command, let's see an example. So first you create a project. This command just creates the directory, the empty directory for your project. So it will send in the event. So it will send, it will return the location of the project directory in the event. Then you configure this project with the rise XML file where project corresponds to the path of the project. And then you can build it. To build it, you have to first use the build command, control build command, and then control weight basic command. So it's the first build of your project. Then you may tweak the XML and just rebuild again. And this will not rebuild all, it just updates the root with new packages. You can also reset your project. If you add something you do not want, there is a control reset. And then a rebuild again. At least because when you use control, it will not create output a result directory as a submit command. So you need to export the file you want from the project directory in the event for that. Just list the file that can be exported with get files and then export it with get file without the s. So now we want to customize our project or distribution. So elbow allows to tune your root reference with different way. So you can do another layer. So just copy the contents of a directory direct in the in the schruth. Of course, you can add as deviant package as you want. You can add in the XML file different command to tweak the file system. So we'll see that later. And you can, most importantly, build your own package and add it to the XML file. So first, how to tune your root FS inside the XML file. So it will be in the file tuning note for I just took the example from the big open black file. So for example, you can first just copy file move file inside the schruth. There is lots of command that have already been implemented like that. And you can find it in this URL. You can also just do shell command. For example, this will just set the UBOOT environment. So it creates a U of context that UBOOT will use. So as I said, you can also there is a different command. So there is also RM command to remove the files or directory to clean your distribution before the delivery, before the output delivery. And there is also a way to tell Elbow to add a special file to the list of files that you may want to export. So for example, the MLO of UBOOT is in the root FS and you want to have this file to flash it maybe in another memory than your memory of your distribution. So you may want to have the MLO alongside your image. So to do it, you have to use the artifact node. Yes, you have to. So for example, all these two commands would add MLO to the list of files that you can download on the device tree also. So after you can use the control get file command to get those files. Now I will present you how to add an overlay to the image. So an overlay is a content of a directory that will be copied over the root file system, of course, at the end of it, of the of the build process. So for example, if you want to have an SSH config and you want to copy it in your image, so just create the overlay directory with the location of the SSH config, of course, copy it, and then load the overlay directory in the XML file. To do it, you have to use the TI SHG archive command. So it will load all the content of the overlay directory in the project XML file in encoded style. So it's base 64 encoded. And then you will see in the project XML a node archive with the content of the overlay directory. One easy trick is to add a Debian package. So the list of, as I said, the list of all the packages of the image are in the package list node. So you just have to add like this, like OpenSSH server to the package list node like this. And now we will look how to build your own package with Arbe. So it is an important step if you want to do a Debian for your own board. So you will need to add a bootloader on the kernel, specify to this board. So you have to create one of these packages and add it to Arbe. You can also use whatever package you want. For example, in one of my projects, I need to rebuild QT. So it takes a bit of time, but I manage to do it. So the different steps to do it is first to Debianize the source code of the package you want to make. Then to add this Debianized package to the image and then to build the package with Arbe. So first, how to Debianize your source of your package. For some well-known packages and well-used packages, like Ubud, Bearbox or Linux, Elbe have already script that automatize this UI display. In this UI display, you can configure the version, the name and other options of the packages. So for example, in the Linux, for Linux, you can choose the DevConfig, the architecture, the release, etc. After you complete all this configuration, Elbe will create the Debian repository inside the package, so here Linux. So for example, for Linux, it will create all of those files. As I said, for Linux, it's already scripted. So normally, if you just configure this UI correctly, you will have a usable Debian directory. Then when you have an usable Debian directory, so your package is Debianized, you can build your package just to forget. So we will see how to build it later. For other packages, other than Linux and Ubud or Bearbox, you have to Debianize the package manually. So for that, you have to create four requisite files. So changelog, control, source and copyright. It's required to debianize properly your package. For that, you can see this URL and it will explain how to do it. But it's easier to use or inspire from an already Debianized package, because Debianized package from scratch is not so easy. So how to build your package? Once it is Debianized, you may want to build it. To build it, you have to use Elbe paybuilder commands. No, paybuilder creates a shrooter in the InVM and all the package that will be built will be built inside this shrooter. So you use the command Elbe paybuilder create and it will return the file project.prg which will return the path of the project. So if you want to build your packages, you create the shroot, you go inside the directory of your packages and you run the paybuilder build command to build your packages. You can point it to the output directory created before and in the output directory, you will have the .deb files of your packages. So for Linux, you will have linux azure, linux image, and linux libcdev packages. When you use paybuilder build command, you can use cross-option and this option will enable cross-building. So it will increase the speed of the build process. Now your packages has been built. It has been automatically added to the repository of the project. So you just need to add it to the list of the package. So for example, you can just add linux image to the list of your packages. But in a project where you do not run Elbe paybuilder, so it's in a hunting project, you can just add the description in the xml file and Elbe will know that you will have to build it. So in the paybuilder node, you just have to add the url of your source of your packages. But like that, for now Elbe, there is no way to cross-build the package in the actual Elbe version. There are parts purchased on the mailing list to enable cross-compilation and the xml file. So now you know how to build your own package, to devionize build your own package and to add it to your description of your project. When you create a new project, you may not want to build the package a second time. So for that, I just give you a tip to avoid to rebuild your packages. So you have the output directory filled with dev packages. So you just have to add it with the Elbe project repo upload command. So just the example is like that, so you create an empty project, you configure it with the description xml file, then you go on the directory where the packages are and you just add it to your actual project, to the new project and build your new project with the two command belts on wait busy. So Elbe, as I said at the beginning of this talk, Elbe can generate SDK which provides cross-compiler and liberator to build whatever application you want. So to do it, you just have to add the build SDK option on the Elbe submit command or you have also a build SDK in the Elbe control command. And so you will have, for example, for Armour Ubuntu, you will have a script that is a Yachto-like script that will generate the little chain. And you can add, for example, if you want to add Cumake to the host part of the tool chain, you can add it with the host package list note. So this, for example, this will add Cumake, the binary of Cumake and its DevTools to the host part of the tool chain. So I think that's all. Yes, it's time for conclusion. So we can see that Elbe is really an interesting tool. It's free only because it's only one XML file that describes all the distribution on all the image generation and the file system, etc. So it's all in one XML file. It's really customizable, even if the Debianize part can be quite hard and painful. But it's for your first packages after several times you Debian, you get used to it. So Elbe, it's good for for this for have a distribution like Debian with and and access all the important secure patch that Debian purpose. So here is the references for learn about Elbe and other presentation like this one. So now if you have any question, suggestion and comments at the time.