Edwin

I've rebased my branch and pulled in commits up to b4e5c589169a076dc081c101448b35cff26b6f12 (Dec 6) and I'm seeing the same problem i.e. Local repo [temp] successfully added. You can run 'aptly repo add temp ...' to add packages to repository. Loading packages... [+] xserver-xorg-video-armsoc-sun4i_1.4.1~armbian5.65+1_armhf added [+] xserver-xorg-video-armsoc-sun4i_1.4.1~armbian5.67+1_armhf added Loading packages... [+] hostapd-realtek_3:2.5-1~armbian5.65+1_arm64 added ... snip [+] sunxi-tools_1.4.2-2~armbian5.67+1_armhf added Loading packages... Generating metadata files and linking package files... Finalizing metadata files... Signing file 'Release' with gpg, please enter your passphrase when prompted: gpg: WARNING: unsafe ownership on homedir '/home/vagrant/.gnupg' gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect gpg: skipped "925644A6": No secret key gpg: signing failed: No secret key ERROR: unable to publish: unable to detached sign file: exit status 2 It's reproducible in the VM (without going through the build process each time), and poking around further I wonder whether something's wrong with the secret keyring: root@vagrant:/home/vagrant/armbian# gpg --no-default-keyring --keyring packages/extras-buildpkgs/buildpkg.gpg --list-keys gpg: DBG: FIXME: merging secret key blocks is not anymore available gpg: Oops; key lost! gpg: DBG: node 0x000055f20ab67cd0 01/00 type=secret-key gpg: DBG: node 0x000055f20ab67e10 00/00 type=user-id "Armbian builder (Temporary key for installing packages during Armbian image creation) <root@localhost>" .... gpg: DBG: node 0x000055f20ab67fc0 00/00 type=signature class=13 keyid=925644A6 ts=1470410930 gpg: DBG: node 0x000055f20ab6a7a0 00/00 type=secret-subkey gpg: DBG: node 0x000055f20ab6ab60 00/00 type=signature class=18 keyid=925644A6 ts=1470410930 packages/extras-buildpkgs/buildpkg.gpg -------------------------------------- root@vagrant:/home/vagrant/armbian# gpg --no-default-keyring --keyring packages/extras-buildpkgs/buildpkg.gpg --list-secret-keys root@vagrant:/home/vagrant/armbian# I'm quite unfamiliar with GPG, so it's possible I'm way off track but the "Oops; key lost!" is consistent with the inability for aptly to publish because it can't find the secret key. Any suggestions?

Thank you, Igor. When I get it building successfully, and have done some testing, would there be appetite for a PR to bump the Armbian version to 2.7?

Hi, I’m trying to integrate the newly released hostapd 2.7 into an image and I’m having trouble including it as a part of the image build process (bionic on vagrant - by the book). My tree is a few weeks out of date, but I can’t see any subsequent commits to the scripts that seem to be the source of my trouble. My build config is: KERNEL_ONLY="no" KERNEL_CONFIGURE="no" CLEAN_LEVEL="make,debs,oldcache" DEST_LANG="en_US.UTF-8" # sl_SI.UTF-8, en_US.UTF-8 KERNEL_KEEP_CONFIG="no" # do not overwrite kernel config before compilation EXTERNAL="yes" # build and install extra applications and drivers EXTERNAL_NEW="compile" # compile and install or install prebuilt additional packages CREATE_PATCHES="no" BUILD_ALL="no" BSPFREEZE="" INSTALL_HEADERS="" BOARD="nanopineo" BRANCH="next" RELEASE="stretch" Additionally, I’ve change packages/extras-buildpkgs/90-hostapd.conf to have local package_ref="tag:hostap_2_7" local package_upstream_version="3:2.7-00" And have removed the patches under packages/extras-buildpkgs/hostapd/debian/patches. During the build, I see the 2.7-00 package being loaded into the temporary repo created in chroot_installpackages_local Local repo [temp] successfully added. You can run 'aptly repo add temp ...' to add packages to repository. Loading packages... [+] xserver-xorg-video-armsoc-sun4i_1.4.1~armbian5.65+1_armhf added Loading packages... [+] hostapd-realtek_3:2.5-1~armbian5.65+1_arm64 added [+] hostapd-realtek_3:2.5-1~armbian5.65+1_armhf added [+] hostapd_3:2.7-00~armbian5.65+1_arm64 added [+] hostapd_3:2.7-00~armbian5.65+1_armhf added [+] mmc-utils_0~gita3d3331-3~armbian5.65+1_arm64 added [+] mmc-utils_0~gita3d3331-3~armbian5.65+1_armhf added [+] sunxi-tools_1.4.2-2~armbian5.65+1_arm64 added [+] sunxi-tools_1.4.2-2~armbian5.65+1_armhf added But then see errors when setting up the temporary repo: Generating metadata files and linking package files... Finalizing metadata files... Signing file 'Release' with gpg, please enter your passphrase when prompted: gpg: WARNING: unsafe ownership on homedir '/home/vagrant/.gnupg' gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect gpg: skipped "925644A6": No secret key gpg: signing failed: No secret key ERROR: unable to publish: unable to detached sign file: exit status 2 [ .... ] Installing additional packages [ EXTERNAL_NEW ] No published repositories, unable to serve. OK Err:1 http://localhost:8189 stretch InRelease Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused) [IP: 127.0.0.1 8189] Subsequently it is unable to find the 2.7 deb and hostapd stays at armbian’s 2.6-99 Reading package lists... W: Failed to fetch http://localhost:8189/dists/stretch/InRelease Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused) [IP: 127.0.0.1 8189] W: Some index files failed to download. They have been ignored, or old ones used instead. Reading package lists... Building dependency tree... Reading state information... hostapd is already the newest version (3:2.6-99~armbian5.60+1). Can anyone suggest what might be happening here, and where I might look next as I try to resolve this? It’s the first time I’ve tried to compile extra applications but I can’t find anything in the doco or forum that seems related to this situation. Thanks, Edwin.

Thank you. I didn't understand that pinning was necessary. Works a treat!

Hi, I'm running the next branch on a NanoPi NEO. Having built my own xenial image from current sources, I notice that an apt-get upgrade brings old kernel and dtb packages (4.14.18). It looks like these old packages are coming from http://apt.armbian.com/pool/main/l/linux-4.14.18-sunxi/ (these are dated 10th Feb). Would it be possible to remove these packages from this location, please? Thanks, Edwin.

The fix that I mentioned seems to keep a stable MAC address on the NEO across reboots, but not across power cycles. Is debian keeping MAC across power cycles and reboots? I'm keen to find the problem on Ubuntu for the NEO, regardless, and perhaps that'll shed some more light on this Duo problem. Can anyone comment on whether a changing MAC when power cycling sounds is generally a uboot problem rather than a device tree problem?

I had a similar issue with the next branch for a NanoPi NEO. There was a missing device tree entry which was fixed in https://github.com/armbian/build/commit/f6c6e05b8e09c843f9389a176d819349db0de389 Perhaps it's a similar issue?

On the NanoPi NEO (a similar board), one of the USB ports on the pin headers didn't show until an extra overlay was added per the last post in this thread: You'll need to add the overlay itself back in whenever you update the kernel Can anyone see a reason why the usbhost1 overlay can't be added into our patches? The overlays for usbhost0, 2 and 3 were added in https://github.com/armbian/build/commit/0630d4dcd9f1f7e995d9f7bca7d6a952ba5ce92c#diff-7a324c1a1d17511d2a3728f2cb90d449 but there's no indication or comment on why usbhost1 was omitted.

Hi Elliot, We have a shrink-image.sh script (https://github.com/ConnectBox/connectbox-tools/blob/master/deployment/shrink-image.sh) when preparing images for our Connectbox project. We prepare the image on a "master" machine, then shutdown and move the microSD to another machine, where we run that script. It's important to re-enable the `resize2fs` service on the "master" machine before shutting-down, or the root partition won't expand when the images are used. We don't trigger a firstrun (open to suggestions on whether we should!) Cheers.

Try devices with the RT5372 chipset. It works out of the box with the NEO mainline and legacy, and because it's 2x2 MIMO you should see 50-70mbit/sec instead of the 30-40mbit/sec that comes from the 1x1 MIMO adapters. There's a compatibility matrix of our testing of a bunch of adapters against mainline and legacy if you want to consider more chipsets: https://github.com/ConnectBox/connectbox-pi/wiki/USB-WiFi-Adapters