Hi All,

 

I have looked at the "How to build your own image/kernel post", but am wondering what the best way for me is to contribute. Basically, I often use the pine64 running armbian as an IoT control hub/gateway where it is running an install of nginx/php/mysql/mosquito/nodered. The php part is mostly because of phpmyadmin, so nginx comes in that case configured with node-red mounted on / and phpmyadmin on /phpmyadmin.

I could create my own image with all this stuff on it, and also configure some default usernames, passwords and wifi setup, but I also noticed the "Software" section in armbian-config.

So my question is which of these 3 options would be the easiest to do, and which one (if any) would be most appreciated as contribution back to armbian from me?

1. Create a new image using the standard guide with all my software
2. Somehow modify an existing image with additional software
3. Contribute a new menu item under "Software" of armbian-config that will install the standard setup I have in mind, so  it would work with any image

 

1 hour ago, Dolf Andringa said:

Contribute a new menu item under "Software" of armbian-config

 

The biggest problem is not creating a script but its maintaining. Such scripts might work fine now, for few months ... and once they break. We can only accept zero maintenance work or work that comes with a maintenance. 

Next, scripts also have to be as generic as possible.

 

1 hour ago, Dolf Andringa said:

Create a new image using the standard guide with all my software

Starting with a most recent clean image + your software and data deployment script is the best way if you do it for you only. If you need to distribute images than you need to build them with your modifications.

Thanks for the answer.

 

Ok, makes sense about the maintenance. As a wild thought: Wouldn't something like integrating Ansible or something make sense? That way maintenance would be limited to maintaining ansible roles and playbooks, which wont be incredibly hard.

 

For now, I will just build my own image indeed.

Ehrm, maybe I completely missed some docs somewhere and this is a stupid question,  but how do I modify the actual image? I went through the whole build process and successfully created an image, but how can I change the software, repositories, etc for the image? Can I drop in a shell or something? Or do I need to modify files somewhere? Just mounting the image and chrooting won't work as I am doing the build on an x64 system.

36 minutes ago, Dolf Andringa said:

Ehrm, maybe I completely missed some docs somewhere and this is a stupid question,  but how do I modify the actual image?

 

https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

Ah, awesome. Missed that bit. Thanks.

One more question: to test my build without having to write it to an sd and boot it, I have kvm and qemu-system-arm. Would it be possible to test my image by running an arm vm? Which board should I compile the kernel for in this case so I have a supported processor? qemu-arm doesn't support the Cortex A53 from my pine64. I don't mind compiling the kernel for a different board just for testing, since the only thing I'm doing is building a software installation script that should run regardless of the exact kernel.

2 hours ago, Dolf Andringa said:

I don't mind compiling the kernel for a different board just for testing, since the only thing I'm doing is building a software installation script that should run regardless of the exact kernel.

I assume you want to use on your x86 desktop? Just go with stock Debian or Ubuntu under KVM/some virtualization for testing the bash install scripts. I do it this way and its fast, convenient and 100% compatible. If you need to talk deeply with hardware in this process you will need to boot real hardware anyway.

Why didn't I think of that. Much better idea. You are awesome @Igor. Thanks for all the quick replies.

Just beware the differences between Ubuntu and Debian userspace. They are different enough to make troubles in install scripts.

Cool. Thanks. I am testing everything on ubuntu xenial (vm) and developing to for ubuntu xenial. So thats fine. Question though: I am running into networking related problems that cause the compile.sh to fail. Is there a way for me to chroot into the system where customize-image.sh script is being executed so I can debug the issue? Normally chrooting won't work on a different architecture (at least as far as I have tried) but it looks like it is being used by the build process. I see the lib/chroot-buildpackages.sh script but have a hard time figuring out how exactly it is used and how I can use it to enter the chroot manually.

 

5 minutes ago, Dolf Andringa said:

Is there a way for me to chroot into the system where customize-image.sh script is being executed so I can debug the issue?

Yes, put

/bin/bash

into your customize-image.sh to launch a shell from the customization script, do what you want and then exit the shell to continue the build process. Don't forget to kill any running services or background processes if you start any otherwise you may get unexpected issues later.

 

6 minutes ago, Dolf Andringa said:

Normally chrooting won't work on a different architecture (at least as far as I have tried) but it looks like it is being used by the build process.

It uses qemu-user emulation to execute binaries for the different architecture.

 

9 minutes ago, Dolf Andringa said:

I see the lib/chroot-buildpackages.sh script but have a hard time figuring out how exactly it is used and how I can use it to enter the chroot manually.

This is responsible for building additional packages, outside the normal image creation process.

3 minutes ago, zador.blood.stained said:

Yes, put

/bin/bash

into your customize-image.sh to launch a shell from the customization script, do what you want and then exit the shell to continue the build process. Don't forget to kill any running services or background processes if you start any otherwise you may get unexpected issues later.

 

It uses qemu-user emulation to execute binaries for the different architecture.

 

This is responsible for building additional packages, outside the normal image creation process.

Jeez, why didn't I think of that. Answers are obvious when someone else gives them Thanks!