This might be more targeted towards security, but building Armbian should not be as a root/privileged user...

 

https://docs.armbian.com/Developer-Guide_Build-Preparation/#how-to-start

 

OpenWRT builds fine as a normal user account, does not need elevated access.

 

Also - FWIW - the local build directory should be armbian, not build - too many other things use /build.

 

@Igor-- thoughts here?

If we downgrade install UX to OpenWRT levels, this is possible. We use loop devices to create bootable images and this method need super user privileges. If you find/create alternative method, this could be changed.

By the way it is recommended to create a building environment encapsulated in a VM and not

Quote

running natively on a dedicated PC or a server (not recommended),

 

1 hour ago, Werner said:

By the way it is recommended to create a building environment encapsulated in a VM and not

running natively on a dedicated PC or a server (not recommended),

 

I also did read that - but why?
The VM also needs internet access for getting the updates for ubuntu and the armbian-build-system.

 

I have two armbian-build-systems 

The first is in a VirtualBox VM on a AMD QuadCore 3Ghz and

the second is on a dedicated Intel Core2Duo 2.4Ghz.

 

Sometimes I got the feeling the "slower" dedicated Intel is faster than the AMD Virtualbox VM.

 

Everything is a bit slower when running through virtualization.  Depending on the task more or less. 

It is kind an insurance as the build script messes with the system like stated with loop devices, apt and so on. 

4 minutes ago, Werner said:

Everything is a bit slower when running through virtualization. 

By default yes, but it is possible to tune-up (at least KVM) to run almost at the same speed.

11 hours ago, Werner said:

By the way it is recommended to create a building environment encapsulated in a VM and not

 

I have a dedicated KVM image, as I don't want to introduce changes from the distribution that might impact the build process - it's an old habit of mine.

 

Anyways - root is a major deity on a *nix system, and an errant script could do a fair amount of damage - it doesn't have to be a "bad actor" but even a typo...

 

Started looking at fakeroot as an option, as this does provide the opportunity to do file manipulation as needed to build an image.

 

The second item...

 

Instead of doing from "/build" as the top directory for the build platform, how much would it be to have "/armbian" as the top level?

 

For example - /armbian_h5 or /armbian/rk3288 (so this is two options actually) - this can help with the nightly builds, and also with folks that are working on multiple platforms.

 

EDIT - actually, would be better to have the final target directory instead - so "~/armbian/target/boardname/image"

 

Some folks have multiple build environments - I have ~/builds/openwrt, and ~/builds/build - would be nicer to have ~/builds/armbian

 

 

Edited February 2, 20197 yr by sfx2000
clarified the ask for the build and dest paths

And since I'm thinking about things.... not complaining, but looking to provide some opportunity to make things better over time.

 

Armbian-Installer (or Armbian Minimal) - this would be a minimalist image - since both the Debain and Ubuntu flavors have the same uboot/kernel/device tree, along with basic rootfs...

 

Then the installer can do the customization. at first run.

 

1) Select Environment - Debian/Ubuntu Desktop/Ubuntu Server for example - this would set the apt sources list, along with the packages needed to complete the install

2) Personalization - create the admin user account (not root), hostname, initial network config

 

If one does a full build now - it's a fairly large chunk of disk space and package downloads - which isn't really needed when one is doing iterative builds across multiple boards - while most of my SBC's are Allwinner based, I do have a Rockchip and a Marvell board, so it does take time and space for all those images - a minimal image like discussed about has benefits here...

 

1) less network bandwidth needed

2) less storage requirements over time

 

Thoughts?

A few month ago someone else already had the idea to create a script that was able to manipulate a complete images with stuff you mentioned as personalization and also provided an early version of this script. Unfortunately I do not remember the name or the script.