sfx2000 Posted February 1, 2019 Posted February 1, 2019 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?
Igor Posted February 1, 2019 Posted February 1, 2019 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.
Werner Posted February 2, 2019 Posted February 2, 2019 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),
guidol Posted February 2, 2019 Posted February 2, 2019 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.
Werner Posted February 2, 2019 Posted February 2, 2019 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.
Igor Posted February 2, 2019 Posted February 2, 2019 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. 1
sfx2000 Posted February 2, 2019 Author Posted February 2, 2019 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. 1
sfx2000 Posted February 2, 2019 Author Posted February 2, 2019 (edited) 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, 2019 by sfx2000 clarified the ask for the build and dest paths
sfx2000 Posted February 2, 2019 Author Posted February 2, 2019 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?
Werner Posted February 3, 2019 Posted February 3, 2019 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.
Recommended Posts