Shoka

Thanks Igor.

I'm setting up a new Armbian system from a cold start. I ran armbian-config and used the personal > welcome option to set the MOTD_DISABLE options in /etc/defaults/armbian-motd. It did not do anything to the welcome screen. I asked for the header tips and updates to be excluded. Looking at the resulting /etc/defaults/armbian-motd file : netadmin@ups-monitor:/etc/update-motd.d$ cat /etc/default/armbian-motd # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE="" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached netadmin@ups-monitor:/etc/update-motd.d$ The edit has been applied, but to the comment line, not the actual MOTD_DISABLE line. I don't know where the script that takes the action is located to check it, but I guess this is not intentional, and thus it needs to be updated to ignore lines beginning with # Second point, I'm reasonably sure, some time back, I put in a change to modify the script 41-armbian-config to change it's THIS_SCRIPT line to "config" rather than "armbian-config", so that it's disable syntax matched the other files in the set. At the moment, on a fresh install, it still needs armbian-config in the MOTD_DISABLE line. My build today is: Has that pull request got lost somewhere ? Harry

Next run worked for me as well. As you say probably temporary. I realize the internet is overloaded at the moment. I cannot work out if the request timed out in the build system, or the remote end responded with 504. If it timed out in the build system we should worry, since crappy internet is with us for some time, and maybe the timeout value is not long enough. If it came from the other end, nothing will help. Harry

Just got this error at the very end of a build. [ o.k. ] Checking git sources [ linux-firmware-git master ] fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Fetching updates fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Checking out error: pathspec 'FETCH_HEAD' did not match any file(s) known to git. I checked a very few minutes later and the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ did eventually respond with a reasonable page, though with a huge delay. Presume that git.kernel.org had a problem, and returned the 504 error, not that the build system timed out waiting, but maybe wiser heads than me can check. If it was just lag, we may see a lot more of this sort of error, given the load on the internet at the moment.... Harry

I have a supported build host running, and successfully building and testing kernels for a few targets that I have examples of. I'm looking to extend my repertoire to building complete armbian images. I think I also want to use EXTERNAL and/or EXTERNAL_NEW to configure additional packages into the image. This has led me to this stanza: BUILD_MINIMAL (yes|no): set to “yes” to build bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP=”yes” and BUILD_EXTERNAL=”yes” I can find no BUILD_EXTERNAL referenced elsewhere, should this be simply EXTERNAL ? or have I missed something. Is there documentation on how EXTERNAL and EXTERNAL_NEW parameters are invoked? Harry

Igor, as far as I can tell your documentation omits mention of the SYNC_CLOCK parameter to the build scripts. If your build host is a system already synced to NTP, for example by systemd-timedated this fragment from general.sh 895 # sync clock 896 if [[ $SYNC_CLOCK != no ]]; then 897 display_alert "Syncing clock" "host" "info" 898 ntpdate -s ${NTP_SERVER:- pool.ntp.org} 899 fi seems to simply mess with the system clock to no purpose. What is the objective? To force an NTP synch or to force the time into the log? timedatectl seems to give correct answers about NTP status even when chrony is managing the clock. I don't have a system to test if it works reasonably with NTPD handling the clock, but if it does, possibly preceding the ntpdate with a check using timedatectl to check if we are already synched to NTP and if so skip the ntpdate would be a good idea? Document the parameter? If we add the check for NTP synch, possibly remove the parameter? Harry

I encountered this running apt-get update, not during a build. Tried several fixes without success. Eventually fixed it using info from the bug report for the last time it occurred in 2018. here sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-keys ED75B5A4483DA07C Harry

Looks like an expired key on http://repo.aptly.info/dists/nightly/InRelease EXPKEYSIG ED75B5A4483DA07C Andrey Smirnov <me@smira.ru> Harry

Built a kernel finally. . Not tested it yet, but it built with no errors. The final total of packages missing from the build was: ccache aria2 libusb-1.0-0-dev Already generated a pull request to add them AND swig python-dev libncurses-dev libstb-dev (not absolutely certain this is required, but I strongly suspect it is) lzma pixz u-boot-tools Will add an additional pull request to add those additional seven packages to the required list. Harry

And another missing component. libncurses-dev. Now struggling with the STB truetype renderer. I can see its missing, but cant find a package for it Its use in u-boot is discussed here. There is a github repository, not sure how it should be installed by the build script. Harry

I understand the development teams position entirely. I'm only reporting the issues I've come up against, because they are rooted in required packages that are not identified in the existing install set up. I've put in a pull request to add the first three omissions to the hostdeps list, since even the supported host configuration is also vulnerable to upstream changes to the set of standard packages. I'll put in requests to add these two as well as any more I find. So far none of the issues I've found are inherent in the choice of host, I suspect I would have has similar issues with a fresh Ubuntu install. Possibly not if those packages are installed by default in that release of Ubuntu, but it's dangerous to rely on that.

More missing packages. Getting further now I have swig and python-dev installed. Still failing though. Harry

Suggested changes to general.sh 796 export LC_ALL="en_US.UTF-8" 797 798 # packages list for host 799 # NOTE: please sync any changes here with the Dockerfile and Vagrantfile 800 local hostdeps="wget ca-certificates device-tree-compiler pv bc lzop zip binfmt-support build-essential ccache debootstrap ntpdate \ 801 gawk gcc-arm-linux-gnueabihf qemu-user-static u-boot-tools uuid-dev zlib1g-dev unzip libusb-1.0-0-dev fakeroot \ 802 parted pkg-config libncurses5-dev whiptail debian-keyring debian-archive-keyring f2fs-tools libfile-fcntllock-perl rsync libssl-dev \ 803 nfs-kernel-server btrfs-progs ncurses-term p7zip-full kmod dosfstools libc6-dev-armhf-cross \ 804 curl patchutils liblz4-tool libpython2.7-dev linux-base swig aptly acl python3-dev \ 805 locales ncurses-base pixz dialog systemd-container udev lib32stdc++6 libc6-i386 lib32ncurses5 lib32tinfo5 \ 806 bison libbison-dev flex libfl-dev cryptsetup gpgv1 gnupg1 cpio aria2 pigz dirmngr python3-distutils \ 807 ccache aria2 libusb-1.0-0-dev" 808 809 local codename=$(lsb_release -sc) 810 When I get my build environment working, and can adequately test, I'll submit this as a pull request. Harry

I know I'm not supposed to pester with issues on non supported build platforms. This is probably due to my choice of build platform, but in case it's not: build is quitting with this log.... scripts/dtc/pylibfdt/Makefile:27: recipe for target 'scripts/dtc/pylibfdt/_libfdt.so' failed scripts/Makefile.build:432: recipe for target 'scripts/dtc/pylibfdt' failed scripts/Makefile.build:432: recipe for target 'scripts/dtc' failed Makefile:528: recipe for target 'scripts' failed [ error ] ERROR in function compile_uboot [ compilation.sh:204 ] [ error ] U-boot compilation failed [ o.k. ] Process terminated That first make fail seems to occur in here: 13 PYLIBFDT_srcs = $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_SRCS)) \ 14 $(obj)/libfdt.i 15 16 quiet_cmd_pymod = PYMOD $@ 17 cmd_pymod = unset CROSS_COMPILE; unset CFLAGS; \ 18 CC="$(HOSTCC)" LDSHARED="$(HOSTCC) -shared " \ 19 LDFLAGS="$(HOSTLDFLAGS)" \ 20 VERSION="u-boot-$(UBOOTVERSION)" \ 21 CPPFLAGS="$(HOSTCFLAGS) -I$(LIBFDT_srcdir)" OBJDIR=$(obj) \ 22 SOURCES="$(PYLIBFDT_srcs)" \ 23 SWIG_OPTS="-I$(LIBFDT_srcdir) -I$(LIBFDT_srcdir)/.." \ 24 $(PYTHON2) $< --quiet build_ext --inplace 25 26 $(obj)/_libfdt.so: $(src)/setup.py $(PYLIBFDT_srcs) FORCE 27 $(call if_changed,pymod) 28 29 always += _libfdt.so 30 31 clean-files += libfdt.i _libfdt.so libfdt.py libfdt_wrap.c I suspect something amiss with the python config on my build host, but python is definitely not my strong suit. Anybody suggest tests to verify the python config? Harry

I'm not inclined to use docker, nor vagrant, and I don't have access to a Ubuntu system these days, all the systems I have to hand are Linux Mint. Linux Mint tricia is a derivative of Ubuntu 18.04, the supported build host. So I'm being a naughty boy and trying to set up a build environment on an existing Mint system. I'm not expecting support from here on setting this up, but a few of the hurdles I've overcome may reflect bugs/missing documentation in the supported build system. The setup failed initially for the test for supported systems. Fixed that, not of interest here. It failed for lack of ccache, again for lack of aria2 and again for lack of libusb-1.0. I've tried to determine if those would be installed in a new Ubuntu installation, but I don't seem to be able to locate the package manifest for 18.04. So if someone can check if they are default installed, I'll forget about it, but if they are missing from a default Ubuntu install, I'll look at documenting the need for them. Harry