Shoka Posted February 1, 2020 Posted February 1, 2020 I have a small group of Orangepi R2's that I'm setting up as remote snort monitors. It's my first experience with Armbian, and Orangepi and I'm very impressed. I have an odd issue that is puzzling, not of practical importance to what I'm doing, but annoying none the less. The set up I'm running is based on the main Armbian buster "Armbian_20.02.0-rc1_Orangepi-r1_buster_current_5.4.14. Linux probe1 5.4.14-sunxi #rc1 SMP Sat Jan 25 15:19:01 CET 2020 armv7l GNU/Linux I've substantially modified that to use systemd-networkd, systemd-resolved and systemd-timesyncd. My issue is that I have a dummy interface appearing. I'm not clear where from. I've used dummy interfaces on previous devices I've configured, so conceivably I've unwittingly used a config fragment from the Raspbian configs I use on my Raspberry Pi's, but if I have, I've not found it. netadmin@probe1:/proc$ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 dummy0 ether off unmanaged 3 eth0 ether routable configured 4 eth1 ether no-carrier configuring 6 wlan0 wlan routable unmanaged 5 links listed. netadmin@probe1:/proc$ networkctl status dummy0 ● 2: dummy0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Driver: dummy HW Address: 32:eb:0b:5a:7d:c9 netadmin@probe1:/proc$ It has a MAC address associated ... netadmin@probe1:/proc/self/net$ lsmod | grep dummy I'm running NetworkManager managing the wifi interface only. verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 rootdev=UUID=517456d9-9b61-4087-a1d3-087b2b583f20 rootfstype=ext4 extraargs=net.ifnames=0 ipv6.disable=1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I cannot find any stray netdev files... root@probe1:/etc/sysctl.d# locate .netdev /usr/share/man/man5/systemd.netdev.5.gz root@probe1:/etc/sysctl.d# I'm very puzzled. Anybody got any other suggestions as to where this is coming from?? Harry
Shoka Posted February 26, 2020 Author Posted February 26, 2020 Further I've looked high and low for the dummy driver, without success. Is the dummy driver compiled in to the Armbian kernel, and if so why ? Harry
Shoka Posted March 4, 2020 Author Posted March 4, 2020 Looks like it's included by default, compiled in, not a module. Presumably because some users will be using SLIP connections? I understand that the kernel impact of compiling the module in is zero. Marginally irritating, I have one box with a config with two dummies. On a Raspbian box though, where dummy is a module. I guess I'm going to have to re-learn how to compile my own kernel.... from config-5.4.20-sunxi CONFIG_NET_CORE=y CONFIG_BONDING=m CONFIG_DUMMY=y <<<<<<<<<<< compiled in, not modular. # CONFIG_EQUALIZER is not set CONFIG_IFB=m # CONFIG_NET_TEAM is not set From Kconfig... config DUMMY tristate "Dummy net driver support" ---help--- This is essentially a bit-bucket device (i.e. traffic you send to this device is consigned into oblivion) with a configurable IP address. It is most commonly used in order to make your currently inactive SLIP address seem like a real address for local programs. If you use SLIP or PPP, you might want to say Y here. Since this thing often comes in handy, the default is Y. It won't enlarge your kernel either. What a deal. Read about it in the Network Administrator's Guide, available from <http://www.tldp.org/docs.html#guide>. To compile this driver as a module, choose M here: the module will be called dummy. If you want to use more than one dummy device at a time, you need to compile this driver as a module. Instead of 'dummy', the devices will then be called 'dummy0', 'dummy1' etc.
Werner Posted March 5, 2020 Posted March 5, 2020 Quote I guess I'm going to have to re-learn how to compile my own kernel.... Using the build script available on Github this is an easy task https://github.com/armbian/build
Igor Posted March 5, 2020 Posted March 5, 2020 Changing kernel config is also a very simple example and opportunity to (re) learn GitHub contribute process https://docs.armbian.com/Process_Contribute/
Shoka Posted March 5, 2020 Author Posted March 5, 2020 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
Igor Posted March 5, 2020 Posted March 5, 2020 10 minutes ago, Shoka said: I'll look at documenting the need for them. Better adding them here: https://github.com/armbian/build/blob/master/lib/general.sh#L798-L806 1
Shoka Posted March 5, 2020 Author Posted March 5, 2020 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
Shoka Posted March 5, 2020 Author Posted March 5, 2020 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
Shoka Posted March 6, 2020 Author Posted March 6, 2020 More missing packages. Getting further now I have swig and python-dev installed. Still failing though. Harry
Igor Posted March 6, 2020 Posted March 6, 2020 1 minute ago, Shoka said: More missing packages. Getting further now I have swig and python-dev installed. Still failing though. Harry You understand now why we choose to stick to one host OS? You will eventually find the right combination, but after a few months something critically will be changed ... we will only fix it for actual Ubuntu version. Or Debian if we choose to move the base there.
Shoka Posted March 6, 2020 Author Posted March 6, 2020 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.
Shoka Posted March 6, 2020 Author Posted March 6, 2020 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
Shoka Posted March 7, 2020 Author Posted March 7, 2020 (edited) 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 Edited March 7, 2020 by Shoka Added note that I'm not 100% listd-dev is required, it may have come in automatically with u-boot-tools
Recommended Posts