09:35 <DC-IRC> [Discord] <cedivad> Hello! I'm a hardware vendor trying to understand what OS to ship with his boards, so I'm showing up here with some silly questions trying to understand my way around it all.

09:35 <DC-IRC> [Discord] <cedivad> Right now I have a custom yocto build recipe handling uboot, kernel and rootfs. I also have a working OTA software update/rescue system that can overwrite the rootfs partition and do other things.

09:35 <DC-IRC> [Discord] <cedivad> All is good, but I would like to give users a chance to _apt_ the entire world without any fuss, which is why I'm thinking maybe replacing the rootfs with something based off armbian might be the way to go.

09:35 <DC-IRC> [Discord] <cedivad> Now, on to the silly questions:

09:35 <DC-IRC> [Discord] <cedivad> - Should I just extract a standard, precompiled rootfs onto my board, customize it slightly and then compress it for my OTA update system, or would it be better to setup a build system?

09:35 <DC-IRC> [Discord] <cedivad> - I want armbian to handle my rootfs only, not uboot/kernel.

09:35 <DC-IRC> [Discord] <cedivad> - I assume the armbian apt repositories would be compatible between the build method and the extract method? I don't really understand how that works.

09:53 <DC-IRC> [Discord] <Werner> Hi. Armbian userspace comes from Debian/ubuntu packages. So if you want armbian to handle userspace only then you can go for Debian/ubuntu bootstrap directly.

10:33 <DC-IRC> [Discord] <igorpec> Armbian is similar to yocto but end resoult is standard debian. Or ubuntu. In very tl;dr;

10:34 <Manneveru> cedivad: out of curiosity, what SoC?

10:34 <Manneveru> cedivad: you know Yocto can build debian packages you could distribute using own APT repository?

10:36 <DC-IRC> [Discord] <igorpec> Here armbian takes for all infra. And visibility

10:37 <Manneveru> cedivad: wise way for the sake of the community if you'd like Armbian, would be adding support for your board with the kernel and uboot built from your forks

10:41 <DC-IRC> [Discord] <cedivad> Thank you all, and sorry for the silly questions.

10:41 <DC-IRC> [Discord] <cedivad> The SoC is an imx8mp (it's a software defined radio, rfnm.io).

10:41 <DC-IRC> [Discord] <cedivad> Yes, I have noticed that I can yocto bitbake basically anything, and that then, by pointing apt to my internal repository url, install the package. I don't have any idea how scalable that is though -- I might be wrong but if there is a tested/deployed set of packages that are already known to work well out there (eg, ubuntu), then why should I compile and publish my own? Sounds l <clipped message>

10:41 <DC-IRC> [Discord] <cedivad> ike a recipe for headaches.

10:41 <DC-IRC> [Discord] <cedivad> The reason I'm against having this as a supported Armbian board is the software upgrade/rescue system, that is fairly custom and might be messy to integrate. I have an onboard emmc, so it's not like I would be pointing users to the latest and greatest Armbian to download on an sd card anyways (rather I will be asking them to use the embedded OTA software upgrade system, and when <clipped message>

10:41 <DC-IRC> [Discord] <cedivad> that's not required, just update the board-specific packages I can release with my own repository).

10:45 <Manneveru> "and sorry for the silly questions" - there are no silly questions, there are only silly answers...

10:54 <DC-IRC> [Discord] <igorpec> we are using classic way uf updating. uboot, kernel and packages are updated via APT, so nothing fancy Mender OTA style

10:55 <DC-IRC> [Discord] <igorpec> this needs to be integrated separetely, but it was done by some people / companies already

10:55 <DC-IRC> [Discord] <igorpec> so its not impossible

10:56 <DC-IRC> [Discord] <igorpec> we also have imx8 family already in the system, so it might be some help

10:56 <DC-IRC> [Discord] <igorpec> and another SoC with it is coming by the end of the year

10:58 <Manneveru> cedivad: you make a lot of effort to make your life significantly harder, you know?

10:58 <Manneveru> cedivad: you can fork Armbian for yourself and maintaining your release train, the fact you'd have recovery on another flash doesn't change things

10:59 <Manneveru> You want images that your recovery can flash on main storage, right?

11:16 <DC-IRC> [Discord] <cedivad> I'd be building my images and my kernel anyways. I would be releasing it either via the rescue system or via packages anyways. I don't think I'm making my life any harder as all of this is ready to go.

12:52 <DC-IRC> [Discord] <boo2832> Hi, Where i can put my own BOOTCONFIG= file and use it in csc file ?

12:52 <DC-IRC> [Discord] <boo2832> _defconfig i mean

13:21 <Manneveru> cedival: why bother then, do debootstrap and you're done

14:38 <DC-IRC> [Discord] <cedivad> I spent a good couple of hours extracting ubuntu .isos and then purging all of the cloud config stuff manually, while debootstrap did the job perfectly! Thanks! 🙂

17:34 <Manneveru> cedivad: 😄

18:28 <Manneveru> want deal with changes to existing ISOs: https://github.com/michalfita/packer-plugin-cross (I've realised documentation is not updated, as my fork doesn't require prebuilding, board files need to point at plugin)