Would it be possible to add an option build parameter, something along the lines of BUILD_MINIMAL_DISTRO to the compile system? Allowing it as a command line option to compile.sh would be great as well.

 

The purpose of the new option would be to use an alternative PAKETKI variable with only the packages absolutely required for running the system and configuring networking (ideally Ethernet and WiFI)  without the bloat of bluez, stress etc.

 

It would also be great if there was a call after install_external_applications to a user provided script that allows the user to install any additional packages that they require.

 

There may be reasons not to do this and / or better ways of implementing equivalent functionality but any thoughts / comments would be great.

 

Nick

Would it be possible to add an option build parameter, something along the lines of BUILD_MINIMAL_DISTRO to the compile system? Allowing it as a command line option to compile.sh would be great as well.

It would be easy to add an option to skip installing of PAKETKI/PACKAGES completely, leaving only stuff installed by debootstrap itself, but it will enable only basic wired networking and probably will break later stages of image creation.

Separation into "essential" and "non-essential" packages can be done, but it will take some time to check and test stuff, especially since "absolutely required" is subjective.

 

It would also be great if there was a call after install_external_applications to a user provided script that allows the user to install any additional packages that they require.

You can use "customize-image.sh" to achieve this.

 

It would be easy to add an option to skip installing of PAKETKI/PACKAGES completely, leaving only stuff installed by debootstrap itself, but it will enable only basic wired networking and probably will break later stages of image creation.

That's a interesting idea, I'm running a build at the moment but I'll try a build with PAKETI commented out later and see if / how much of the build process is broken. The combination of that and customize-image.sh may be exactly what I'm looking for.

 

 

 

especially since "absolutely required" is subjective

I agree entirely, which is why the use of customize-image is essential, for example I'm working on two projects at the moment one requires WiFi and the other doesn't, so even my initial thought of including the WiFi tools wouldn't be "minimal" enough for my other project.

 

One potential advantage to developing the the idea of an absolute minimal PAKETI would be to allow for future expansion of the install desktop menu option. Instead of being a simple install desktop yes / no, it could include options for building a server, building an access point, building a NAS image etc.

Well Armbian builds with PAKETI commented out which is good. the system boots and appears to run as expected. The MOTD fails as some of the required packages aren't present and I'm sure there will be other things that fail as well, but so far so good

I fully understand that people don't need a compiler, headers and selection of certain utilities on product deployment. The basic ideas of Armbian was to have all in one / general purpose CLI OS. We added some customization on the way within customize-image.sh but yes, this process is not optimal and takes some time.

 

Desktop is not where I wanted to be and should be developed further. I also don't like to waste time on providing several desktop options. If one urgently doesn't want the defaults ... it's easy to switch to whatever later and it's also possible in a process customize-image.sh ...

 

One potential advantage to developing the the idea of an absolute minimal PAKETI would be to allow for future expansion of the install desktop menu option. Instead of being a simple install desktop yes / no, it could include options for building a server, building an access point, building a NAS image etc.

 

 

I am doing something similar in a separate project. It's little outdated and would need update / rework. 

https://github.com/igorpecovnik/Debian-micro-home-server(latest commits DEV branch)

I guess the downside of customize-image.sh is that everything has to be downloaded, installed and then most of the packages uninstalled again via cust...sh as you say, not optimal. That said it works.

 

Having tried Zador's idea of commenting out PAKETI entirely, I do like that and it actually suits my application very well. So if there is any chance of having an option that ignores PAKETI entirely then that would be wonderful, as I can do everything else via customize-image.sh

 

 

I am doing something similar in a separate project. It's little outdated and would need update / rework. 

https://github.com/i...cro-home-server(latest commits DEV branch)

 

That looks like an interesting project and actually very close to one of the units in my project, you mention that it is outdated, by how much? Does it support the next kernel and the H3 SoC's by any chance? 

Perhaps merging it with Armbian is a way of bringing it up to date?

I noticed that you used a custom case, I'm using this one http://uk.farnell.com/pro-power/g17081ubk/case-19-abs-1u-black/dp/1526723?ost=1526723&selectedCategoryId=I don't know if that helps you at all?

 

The next question may require a topic of it's own, but I'll ask it here anyway for the moment:

Is there any way of adding new boards to the build process without having them added to the main Armbian code?

 

It's not a problem at the moment, however I'm hopefully going to be designing my own custom boards for these projects soon (I'm a Hardware engineer during the day) but my assumption is that if I were to add them into boards.sh then they would be overwritten when I next pull the build code from git?

I guess the downside of customize-image.sh is that everything has to be downloaded, installed and then most of the packages uninstalled again via cust...sh as you say, not optimal. That said it works.

Having tried Zador's idea of commenting out PAKETI entirely, I do like that and it actually suits my application very well. So if there is any chance of having an option that ignores PAKETI entirely then that would be wonderful, as I can do everything else via customize-image.sh

I probably will move packages definitions to configuration.sh (this should also help reducing data duplication in debootstrap.sh and debootstrap-ng.sh), after that you (or anyone else) should be able to overwrite packages list in lib.config

 

The next question may require a topic of it's own, but I'll ask it here anyway for the moment:

Is there any way of adding new boards to the build process without having them added to the main Armbian code?

Unfortunately no due to default case handler for board configuration in configuration.sh

*) echo "Board configuration not found"
	exit
;;

In theory it's possible to rework this part in the future (i.e. separate board config into files and include by file name, something like

if [[ -f $SRC/lib/configuration/$BOARD.cfg ]]; then
  source $SRC/lib/configuration/$BOARD.cfg
else
  echo "Board configuration not found"
  exit 0
fi

but the best way to include new board now is a pull request to Armbian building framework (if this board is/will be available to anyone)

 

It's not a problem at the moment, however I'm hopefully going to be designing my own custom boards for these projects soon (I'm a Hardware engineer during the day) but my assumption is that if I were to add them into boards.sh then they would be overwritten when I next pull the build code from git?

If there are merge conflicts changes shouldn't be overwritten (update code doesn't use force checkout)

Hi Zador

 

 

I probably will move packages definitions to configuration.sh (this should also help reducing data duplication in debootstrap.sh and debootstrap-ng.sh), after that you (or anyone else) should be able to overwrite packages list in lib.config

 

Thanks for that, if you would like me to test it at any point let me know.

 

As for the custom board idea, it's not a problem. I like your idea of including the configurations as separate files and would love to see something similar implemented in the future, however as I mentioned it's not something that is critical for me at the moment.

In theory it's possible to rework this part in the future (i.e. separate board config into files and include by file name, something like

 

Agree. Configuration is also getting messy so this should be done at some point.

I hope you guys don't mind, I have created a patch to ignore PAKETKI from a command line option.

 

The patch does 2 things:

1) corrects a spelling mistake in debootstrap.sh

2) checks to see if the variable NOPAKETKI == yes. If it is then it sets PAKETKI to "" just before install_packet is called.

 

This is the first time I have prepared a patch for public consumption so please let me know if I have done anything wrong.

 

On another note, if you guys don't mind I would like to look at the idea of moving board configs into separate files, but I'll create a separate thread for that if you don't mind me having a go.

diff --git a/debootstrap.sh b/debootstrap.sh
index fcc331d..8f09152 100644
--- a/debootstrap.sh
+++ b/debootstrap.sh
@@ -48,7 +48,7 @@ fi
 LOOP=$(losetup -f)
 
 if [[ "$LOOP" != "/dev/loop0" && "$LOOP" != "/dev/loop1" ]]; then
-display_alert "You run out of loop devices" "pleese reboot" "error"
+display_alert "You run out of loop devices" "please reboot" "error"
 exit
 fi
 
@@ -181,6 +181,10 @@ LC_ALL=C LANGUAGE=C LANG=C chroot $DEST/cache/sdcard /bin/bash -c "locale-gen $D
 LC_ALL=C LANGUAGE=C LANG=C chroot $DEST/cache/sdcard /bin/bash -c "export CHARMAP=$CONSOLE_CHAR FONTFACE=8x16 LANG=$DEST_LANG LANGUAGE=$DEST_LANG DEBIAN_FRONTEND=noninteractive"
 LC_ALL=C LANGUAGE=C LANG=C chroot $DEST/cache/sdcard /bin/bash -c "update-locale LANG=$DEST_LANG LANGUAGE=$DEST_LANG LC_MESSAGES=POSIX"
 
+if [[ $NOPAKETKI == yes ]]; then
+    PAKETKI=""
+    display_alert "Ignoring" "PAKETKI" "O.K."
+fi
 
 install_packet "$PAKETKI" "Installing Armbian on the top of $DISTRIBUTION $RELEASE base system ..."
 
@@ -211,4 +215,4 @@ mount -t proc chproc $DEST/cache/sdcard/proc
 mount -t sysfs chsys $DEST/cache/sdcard/sys
 mount -t devtmpfs chdev $DEST/cache/sdcard/dev || mount --bind /dev $DEST/cache/sdcard/dev
 mount -t devpts chpts $DEST/cache/sdcard/dev/pts
-}
\ No newline at end of file
+}

I like the idea of moving packages list to configuration.sh more, since it won't require adding extra variables and will apply to both debootstrap variants.

 

About board configurations - I thougt about moving some extra options from boards.sh to board configuration files and doing some refactoring; in addition it will require changing board selection menu in main.sh and code in build-all.sh too.

I'll try to do some of this next week, and if I feel that I don't have enough free time, I'll write here.

Can the variables in configuration.sh be overwritten from the command line then?

 

Looking at the way everything is put together, source configuration.sh seems to come after the variables are parsed and therefore overwrite anything that is added to the command line. I haven't actually tried it yet though, so it may be that I have just mis-read the code.

Near the end of configuration.sh is this

	# For user override	
	if [[ -f "$SRC/userpatches/lib.config" ]]; then 
		display_alert "Using user configuration override" "userpatches/lib.config" "info"
		source $SRC/userpatches/lib.config
	fi

which should allow overwriting anything set in configuration.sh or earlier

Oh wonderful, I hadn't noticed that bit. When you mentioned lib.config earlier, I thought you were referring to the lib/config directory. I couldn't see how that would work.

 

You guys seem to have thought of everything :-)