Jump to content

y52

Members
  • Posts

    241
  • Joined

  • Last visited

Recent Profile Visitors

2714 profile views
  1. I have a working BPi M1 with [ 0.000000] Linux version 5.15.25-sunxi (root@d72d155687c7) (arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.02.1 SMP Sun Feb 27 09:23:25 UTC 2022 Due to inconvenient USB placements, I thought using OTG micro USB (the one right next to the SD slot), but it doesn't seem to be operational. I bought a Micro USB Male To Female OTG Adapter Cable, but the attached devices are not detected neither connected to OTG port, nor to the normal power-in micro USB connector (located between SATA and SATA-pwr). I attached the same Micro USB Male To Female OTG Adapter Cable to my Android phone and devices are recognized and activated. For example an external keyboard worked with the phone. What is the current USB OTG support status and what is necessary to debug its functionality? I quick look at kernel configuration: root@bananapi:~# zcat /proc/config | grep OTG CONFIG_USB_OTG=y # CONFIG_USB_OTG_PRODUCTLIST is not set # CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB is not set # CONFIG_USB_OTG_FSM is not set CONFIG_USB_FOTG210_HCD=m # CONFIG_USB_FOTG210_UDC is not set root@bananapi:~# zcat /proc/config | grep CONFIG_USB_DWC CONFIG_USB_DWC3=y # CONFIG_USB_DWC3_HOST is not set # CONFIG_USB_DWC3_GADGET is not set CONFIG_USB_DWC3_DUAL_ROLE=y CONFIG_USB_DWC3_OF_SIMPLE=m CONFIG_USB_DWC2=y # CONFIG_USB_DWC2_HOST is not set # CONFIG_USB_DWC2_PERIPHERAL is not set CONFIG_USB_DWC2_DUAL_ROLE=y # CONFIG_USB_DWC2_DEBUG is not set # CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set What is necessary to make OTG working?
  2. Hello Pali, Thank you again for pointing out this flaw. I recall your alert earlier this year : https://forum.armbian.com/topic/19564-making-espressobin-v7-work-in-2022/page/2/# Beware, 1.2 GHz CPU is broken and Marvell refused to fix it. Hence kernel maintainers decided to delete/deactive 1.2 GHz mode. https://lore.kernel.org/linux-pm/20210809040224.j2rvopmmqda3utc5@vireshk-i7/ So rather stick with 1 GHz mode. Now kernel upgrade reminded this bug again. It remains yet unclear to me, why the 5.10.60-mvebu64 kernel works on 1.2 GHz variant of A3720 SOC and apparently does frequency scaling, while the next 5.15 tree does not. If init sequence related to CPU voltage configuration satisfy the 5.10 tree, why is it no more valid for 5.15? I have another ancillary issue with uboot implementation. When I followed your u-boot build guidance in February 2022, I didn't implement U-Boot distroboot feature by that time as Armbian distribution was not yet ready. Thus I haven't set default environment in u-boot so far. Armbian is currently passed from boot_targets=usb sata mmc1 mmc0 bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done instead if distroboot implementation : bootcmd=run distro_bootcmd What are implications of not setting default environment (=> env default -a) in u-boot with "distroboot Armbian"?
  3. I used Igor's advice for another issue : Workaround: armbian-config -> system -> Other -> Switch to other kernels , pick previous, freeze, wait | |linux-image-current-mvebu64=22.08.2 5.15.69-mvebu64 | | | |linux-image-current-mvebu64=22.05.3 5.15.48-mvebu64 | | | |linux-image-current-mvebu64=22.05.1 5.15.35-mvebu64 | | | |linux-image-current-mvebu64=21.08.1 5.10.60-mvebu64 | | <<-- CPU scaling is not broken I progressively downgraded to kernels 5.15.69, than to 5.15.48 and 5.15.35. None of them allowed to fix CPU scaling. This is rather strange, as I run another espressobin, which doesn't loose CPU scaling with kernel 5.15.48-mvebu64. This second espressobin is version 5 and u-boot running at 1000 MHz. This could give a clue to fix broken CPU scaling in kernel 5.15.xx. Just to remind, that root@ebinv7# dmesg -l emerg,alert,crit,err [ 1.917740] debugfs: Directory 'd0060900.xor' with parent 'dmaengine' already present! [ 2.420702] Unsupported CPU frequency 1200 MHz <<-- vs -->> ebinv5 @1000 MHz After 5.15.x disenchantment I've downgraded to 5.10.60-mvebu64, which fixed CPU scaling : root@ebinv7:/boot# dmesg -l emerg,alert,crit,err [ 2.319871] debugfs: Directory 'd0060900.xor' with parent 'dmaengine' already present! [ 5.739975] advk-pcie d0070000.pcie: link never came up root@ebinv7:/boot# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:22.65%, 300 MHz:8.94%, 600 MHz:0.09%, 1.20 GHz:68.32% (1637) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:22.65%, 300 MHz:8.94%, 600 MHz:0.09%, 1.20 GHz:68.32% (1637) root@ebinv7:/boot# lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 4 Model name: Cortex-A53 Stepping: r0p4 CPU max MHz: 1200.0000 CPU min MHz: 200.0000 BogoMIPS: 25.00 NUMA node0 CPU(s): 0,1 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Not affected Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Has this bug been reported and scheduled for fixing? On the other side, why do I still receive 2 upgrades available, while 22.08 is already setup? Welcome to Armbian 22.08.6 Bullseye with Linux 5.10.60-mvebu64 root@ebinv7:/boot# apt list --upgradable Listing... Done linux-dtb-current-mvebu64/bullseye 22.08.6 arm64 [upgradable from: 21.08.1] linux-image-current-mvebu64/bullseye 22.08.6 arm64 [upgradable from: 21.08.1]
  4. What could also be relevant to fix CPU scaling: # ls /sys/devices/system/cpu/cpu0 cpu_capacity crash_notes crash_notes_size hotplug node0 of_node online power regs subsystem topology uevent (no cpufreq) CPU governors are not available. root@tiger:~# dmesg -l emerg,alert,crit,err [ 1.917740] debugfs: Directory 'd0060900.xor' with parent 'dmaengine' already present! [ 2.420702] Unsupported CPU frequency 1200 MHz [ 3.937067] advk-pcie d0070000.pcie: link never came up I use the mainline u-boot with CPU frequency 1200 MHz, which proved itself stable before upgrade: Marvell>> reset resetting ... TIM-1.0 mv_ddr-devel-g7753d4b DDR4 16b 1GB 1CS WTMI-devel-18.12.1-4392eaf WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.225V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware v2021.09.07-27-g489262b (Feb 9 2022 18:50:42) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL1: Built : 18:52:58, Feb 9 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL2: Built : 18:53:02, Feb 9 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL31: Built : 18:53:12, Feb 9 2022 U-Boot 2022.04-rc1-00087-gb5c5b9a0be (Feb 09 2022 - 18:44:33 +0100)
  5. By some unknown reason cpufreq device has become unavailable after upgrade: cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: No such file or directory The old working system had : # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors conservative ondemand userspace powersave performance schedutil
  6. I was running espressobin v7 with Welcome to Armbian 21.08.1 Bullseye with Linux 5.10.60-mvebu64 and made an upgrade in a regular way : # apt upgrade The following packages will be upgraded: apache2 apache2-bin apache2-data apache2-dev apache2-utils armbian-bsp-cli-espressobin armbian-config armbian-firmware armbian-zsh asterisk asterisk-config asterisk-modules asterisk-voicemail avahi-autoipd base-files bash curl deb.torproject.org-keyring dirmngr distro-info-data dpkg dpkg-dev ffmpeg gnupg gnupg-l10n gnupg-utils gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv gzip hostapd ifenslave inetutils-inetd inetutils-telnet libapache2-mod-php7.4 libavahi-client3 libavahi-common-data libavahi-common3 libavcodec58 libavdevice58 libavfilter7 libavformat58 libavresample4 libavutil56 libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libcups2 libcurl3-gnutls libcurl4 libdpkg-perl libfreetype6 libfribidi0 libgnutls30 libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 libldap-2.4-2 libldap2-dev libldb2 liblzma5 libnm0 libnss-myhostname libntfs-3g883 libpam-systemd libpcre2-16-0 libpcre2-32-0 libpcre2-8-0 libpcre2-dev libpcre2-posix2 libpostproc55 libpq5 libsdl2-2.0-0 libsmbclient libsnmp-base libsnmp40 libssl-dev libssl1.1 libswresample3 libswscale5 libsystemd0 libtiff5 libtirpc-common libtirpc-dev libtirpc3 libudev1 libwbclient0 libxml2 libxslt1.1 linux-dtb-current-mvebu64 linux-image-current-mvebu64 linux-libc-dev linux-u-boot-espressobin-current locales logrotate nano network-manager ntfs-3g openssh-client openssh-server openssh-sftp-server openssl php7.4 php7.4-cli php7.4-common php7.4-curl php7.4-json php7.4-opcache php7.4-readline python3-ldb python3-samba rsyslog samba samba-common samba-common-bin samba-libs smbclient systemd systemd-sysv tcpdump tor tor-geoipdb tzdata udev unzip wireless-regdb xz-utils zlib1g ... update-initramfs: Converting to u-boot format update-initramfs: Converting to u-boot FIT image FIT description: EspressoBIN 3720 FIT Image Created: Sun Oct 23 13:08:21 2022 Image 0 (kernel) Description: Vanilla Linux kernel Created: Sun Oct 23 13:08:21 2022 Type: Kernel Image Compression: lzma compressed Data Size: 6882687 Bytes = 6721.37 KiB = 6.56 MiB Architecture: AArch64 OS: Linux Load Address: 0x07000000 Entry Point: 0x07000000 Hash algo: sha1 Hash value: c8d92b9c244fdcc9fb56f640d05e6fc4d3f7ffb6 Image 1 (ramdisk) Description: Boot ramdisk Created: Sun Oct 23 13:08:21 2022 Type: RAMDisk Image Compression: Unknown Compression Data Size: 8909801 Bytes = 8700.98 KiB = 8.50 MiB Architecture: AArch64 OS: Linux Load Address: unavailable Entry Point: unavailable Hash algo: sha1 Hash value: 3be954cf886386101311f7673115fa0be0c95366 Image 2 (fdtv5) Description: Flattened Device Tree ebinv5 Created: Sun Oct 23 13:08:21 2022 Type: Flat Device Tree Compression: uncompressed Data Size: 11618 Bytes = 11.35 KiB = 0.01 MiB Architecture: AArch64 Load Address: 0x06f00000 Hash algo: sha1 Hash value: dcfa1e753a26493b713b8d6eee19e0895db09cc3 Image 3 (fdtv7) Description: Flattened Device Tree ebinv7 Created: Sun Oct 23 13:08:21 2022 Type: Flat Device Tree Compression: uncompressed Data Size: 11646 Bytes = 11.37 KiB = 0.01 MiB Architecture: AArch64 Load Address: 0x06f00000 Hash algo: sha1 Hash value: 0230f9e11a6f364dc66c0aca9a72620b19a0f1e0 Default Configuration: 'v5' Configuration 0 (v5) Description: Standard Boot ebinv5 Kernel: kernel Init Ramdisk: ramdisk FDT: fdtv5 Hash algo: sha1 Hash value: unavailable Configuration 1 (v7) Description: Standard Boot ebinv7 Kernel: kernel Init Ramdisk: ramdisk FDT: fdtv7 Hash algo: sha1 Hash value: unavailable After upgrade and reboot the kernel was upgraded to : Welcome to Armbian 22.08.6 Bullseye with Linux 5.15.74-mvebu64 The side effect is that cpu-freq regulation seems to be broken: root@tiger:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. The # htop is unable to determine it either : Cpu Freq: 0 MHz The previous setup before upgrade "Armbian 21.08.1 Bullseye with Linux 5.10.60-mvebu64" ran frequency switch flawlessly: # cpufreq-info current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:93.04%, 300 MHz:0.48%, 600 MHz:0.18%, 1.20 GHz:6.30% (215) Due to inability of CPU frequency regulation, I found that the board temperature has been increased by about 5 deg. C. What could be done to fix this issue?
  7. armbian-ramlog & armbian-truncate-log are not executed due to an error parsing the XTRA_RSYNC_TO=(--delete) from /etc/default/armbian-ramlog This results in quick saturation of /var/log. I've made some advancement in debugging "armbian-ramlog & armbian-truncate-log" complex, based on the master tree here: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-ramlog Your /usr/lib/armbian/armbian-ramlog has a syntax error in the array expression ${XTRA_RSYNC_TO[@]+"${XTRA_RSYNC_TO[@]}"} The 1st array lacks a closing } curly braces. Secondly, I can't figure out, why the same array is duplicated. Even if you parse a variable XTRA_RSYNC_TO=(--delete) from /etc/default/armbian-ramlog, it will result in : --delete+--delete Another problem comes, when you call /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 from /usr/lib/armbian/armbian-truncate-logs. It actually produces the error: # /usr/lib/armbian/armbian-truncate-logs /usr/lib/armbian/armbian-truncate-logs: 23: /etc/default/armbian-ramlog: Syntax error: "(" unexpected I believe there is a syntax error in the way the call is made, where the XTRA_RSYNC_TO=(--delete) variable is not accounted for. Otherwise, if the XTRA_RSYNC_TO=(--delete) variable is remarked in /etc/default/armbian-ramlog and "--delete" option is hard coded in /usr/lib/armbian/armbian-ramlog, the complex starts running without raising exceptions.
  8. I've made some advancement in debugging "armbian-ramlog & armbian-truncate-log" complex. Your /usr/lib/armbian/armbian-ramlog has a syntax error in the array expression ${XTRA_RSYNC_TO[@]+"${XTRA_RSYNC_TO[@]}"} The 1st array lacks a closing } curly braces. Secondly, I can't figure out, why the same array is duplicated. Even if you parse a variable XTRA_RSYNC_TO=(--delete) from /etc/default/armbian-ramlog, it will result in : --delete+--delete Another problem comes, when you call /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 from /usr/lib/armbian/armbian-truncate-logs. It actually produces the error: # /usr/lib/armbian/armbian-truncate-logs /usr/lib/armbian/armbian-truncate-logs: 23: /etc/default/armbian-ramlog: Syntax error: "(" unexpected I believe there is a syntax error in the way the call is made, where the XTRA_RSYNC_TO=(--delete) variable is not accounted for. Could you give it a glance? Otherwise, if the XTRA_RSYNC_TO=(--delete) variable is remarked in /etc/default/armbian-ramlog and "--delete" option is hard coded in /usr/lib/armbian/armbian-ramlog, the complex starts running without raising exceptions.
  9. This fix is incomplete. It fixes only XTRA_RSYNC_FROM=() procedure declaration in /etc/default/armbian-ramlog But this procedure IS NOT called in armbian-truncate-logs : /usr/lib/armbian# vi armbian-truncate-logs ... # truncate, save and clean logs if they get over 75% of the /var/log size # working only when armbian-ramlog is enabled treshold=75 # % JOURNAL_SIZE=5M # size to shrink systemd-journal [ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog [ "$ENABLED" != true ] && exit 0 logusage=$(df /var/log/ --output=pcent | tail -1 |cut -d "%" -f 1) if [ $logusage -ge $treshold ]; then # write to SD /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 # rotate logs on "disk" /usr/sbin/logrotate --force /etc/logrotate.conf # truncate /usr/bin/find /var/log -name '*.log' -or -name '*.xz' -or -name 'lastlog' -or -name 'messages' -or -name 'debug' -or -name 'syslog' | xargs -r truncate --size 0 /usr/bin/find /var/log -name 'btmp' -or -name 'wtmp' -or -name 'faillog' -or -name 'firewalld' | xargs -r truncate --size 0 /usr/bin/find /var/log -name 'mail.err' -or -name 'mail.info' -or -name 'mail.warning' | xargs -r truncate --size 0 # remove /usr/bin/find /var/log -name '*.[0-9]' -or -name '*.gz' | xargs -r rm -f # vacuum systemd-journald [ -d /var/log/journal ] && journalctl --vacuum-size=${JOURNAL_SIZE} fi Thus armbian-truncate-logs still produces the same error : /usr/lib/armbian# ./armbian-truncate-logs ./armbian-truncate-logs: 24: /etc/default/armbian-ramlog: Syntax error: "(" unexpected Despite that variables are well parsed from armbian-ramlog : armbian# [ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog armbian# echo $USE_RSYNC true armbian# echo $SIZE 50M armbian-truncate-logs script doesn't contain XTRA_RSYNC_FROM=() procedure. Could you show both fixed /usr/lib/armbian/armbian-truncate-logs script and /etc/default/armbian-ramlog ?
  10. This is a different issue. Operand below from the script executes without error on its own. [ -d /var/log/journal ] && journalctl --vacuum-size=5M The current error comes from some sort of syntax error in the script as it explicitly raises : Syntax error: "(" unexpected
  11. How could the mainline sources be patched with this hotfix? armbian-truncate-logs doesn't execute resulting in full /var/log pretty quickly. :/usr/lib/armbian# ./armbian-truncate-logs ./armbian-truncate-logs: 18: /etc/default/armbian-ramlog: Syntax error: "(" unexpected Line 18 points to a blank one :/usr/lib/armbian# vi armbian-truncate-logs #!/bin/sh # # Copyright (c) Authors: https://www.armbian.com/authors # # This file is licensed under the terms of the GNU General Public # License version 2. This program is licensed "as is" without any # warranty of any kind, whether express or implied. # # truncate, save and clean logs if they get over 75% of the /var/log size # working only when armbian-ramlog is enabled treshold=75 # % JOURNAL_SIZE=5M # size to shrink systemd-journal [ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog [ "$ENABLED" != true ] && exit 0 <<-- this is line 18 logusage=$(df /var/log/ --output=pcent | tail -1 |cut -d "%" -f 1) if [ $logusage -ge $treshold ]; then # write to SD Expressions before and after line 18 look good and execute individually well. Sadly enough the errors are not reported in journal files. It took me some time to discover it. Could somebody figure out where the error comes from? Besides, I've found, that journald.conf settings are not taking effect on limiting logging capacity. armbian# cat /etc/systemd/journald.conf # See journald.conf(5) for details. [Journal] .. SystemMaxUse=20M <<- this option is set by armbian-zram-config SystemKeepFree=10M <<- set manually to keep the min. /var/log space available None of the above options are respected resulting in growing /var/log/journal/
  12. u-boot compiled from mainline sources logs the following error when booting Espressobin v.7: kernel: spi-nor spi0.0: unrecognized JEDEC id bytes: e7 60 16 00 00 00 kernel: spi-nor: probe of spi0.0 failed with error -2 It seems, that U-Boot found the flash but couldn't find its JEDEC ID in its table. Typically this means support is not compiled in, and you need to add support in the U-Boot configuration. Will it be taken care of in future mainline sources, so that new spi id's are added to uboot?
  13. I wonder if mainline u-boot is capable booting ZFS file system and logical volume manager? It is worth considering setting up Armbian directly on the ZFS as SSD and SD cards are far from being reliable. I've experienced a series of hard setbacks due to their failures. Apparently, only those file systems are supported : => fstypes Supported filesystems: fat, ext4, btrfs, squashfs
  14. We discussed this issue on Feb. 10th here: eth0 is the internal switch interface. It is not used in providing user network functionality. It has neither any PHY interface, no it requires any ip address. If DHCP is left enabled, it inquires a supplementary address from the DHCPD server, like it was my case here : Mar 12 10:16:01 tiger dhcpd[981]: DHCPDISCOVER from 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:02 tiger dhcpd[981]: DHCPOFFER on 192.168.1.244 to 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPDISCOVER from 6e:05:2a:97:c4:0c via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPDISCOVER from 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPOFFER on 192.168.1.244 to 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPOFFER on 192.168.1.243 to 6e:05:2a:97:c4:0c (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPREQUEST for 192.168.1.243 (192.168.4.15) from 6e:05:2a:97:c4:0c (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPACK on 192.168.1.243 to 6e:05:2a:97:c4:0c (espressobin) via lan Despite it, espressobin is accessible through x.243 only. Build script on espressobin with Bullseye hasn't completed again with the following errors : E: Failed to fetch http://deb.debian.org/debian/pool/main/u/unzip/unzip_6.0-26_arm64.deb 502 Connection closed [IP: ::1 3142] E: Failed to fetch http://deb.debian.org/debian/pool/main/u/usbutils/usbutils_013-3_arm64.deb 502 Connection closed [IP: ::1 3142] E: Failed to fetch http://deb.debian.org/debian/pool/main/v/vim/vim_8.2.2434-3%2bdeb11u1_arm64.deb 502 Connection closed [IP: ::1 3142] E: Failed to fetch http://deb.debian.org/debian/pool/main/v/vlan/vlan_2.0.5_all.deb 502 Connection closed [IP: ::1 3142] E: Failed to fetch http://deb.debian.org/debian/pool/main/w/wireless-tools/wireless-tools_30~pre9-13.1_arm64.deb 502 Connection closed [IP: ::1 3142] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? [ error ] ERROR in function create_rootfs_cache [ main.sh:589 -> main.sh:550 -> debootstrap.sh:58 -> debootstrap.sh:311 -> general.sh:0 ] [ error ] Installation of Armbian main packages for current espressobin bullseye no failed [ o.k. ] Process terminated [ error ] unmount_on_exit() called! [ main.sh:1 -> image-helpers.sh:0 ] [ o.k. ] Unmounting [ /src/Armbian/build/.tmp/rootfs-c0d7eabc-a7bf-4b6e-a83a-67dc454eb8f4/ ] [ error ] ERROR in function unmount_on_exit [ main.sh:1 -> image-helpers.sh:94 -> general.sh:0 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated Execution time: 56132.596534 seconds <- 15 hours 36 min. [1] 267691 Sun 13 Mar 2022 06:05:45 AM CET Apt commands run separately are executed without error : root@espressobin:/src/Armbian/build# apt-get update .. Get:11 http://deb.debian.org/debian bullseye-backports/main arm64 Packages T-2022-03-13-0802.23-F-2022-03-13-0802.23.pdiff [196 B] Get:13 http://security.debian.org bullseye-security/main arm64 Packages [152 kB] Get:12 http://deb.debian.org/debian bullseye-backports/main all Contents (deb) T-2022-03-13-0802.23-F-2022-03-13-0802.23.pdiff [87 B] Fetched 625 kB in 13s (49.0 kB/s) Reading package lists... Done root@espressobin:/src/Armbian/build# apt install unzip Reading package lists... Done Building dependency tree... Done Reading state information... Done unzip is already the newest version (6.0-26). On the positive side, espressobin with the new u-boot and armbian 22 is so far stable both idle and under heavy load during building. root@espressobin:/src/Armbian/build# uptime 10:43:03 up 23:17, 2 users, load average: 0.00, 0.01, 0.05 When building : Time CPU load %cpu %sys %usr %nice %io %irq CPU 14:02:21: 1000MHz 3.26 99% 14% 84% 0% 0% 0% 27.0°C 14:02:26: 1000MHz 3.24 100% 11% 88% 0% 0% 0% 27.0°C 14:02:37: 1000MHz 3.28 100% 14% 85% 0% 0% 0% 28.0°C NetworkManager and systemd-networkd are duplicating services and can't be run concurrently. You should choose enabling one of them. I understand that systemd-networkd is a preferred choice under Debian, thus NetworkManager should be disabled in order not to interfere in network functioning. User can switch between them if he prefers NetworkManager.
×
×
  • Create New...