Jump to content

y52

  • Posts

    234
  • Joined

  • Last visited

Recent Profile Visitors

2438 profile views
  1. 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.
  2. 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.
  3. 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 ?
  4. 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
  5. 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/
  6. 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?
  7. 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
  8. 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.
  9. I've tried the above generated image for the AR-775 trunk to boot my espressobin v5. The major concern at this point which requires the fix is that the reboot is being suspended [ OK ] Deactivated swap /dev/zram0. [ OK ] Reached target Unmount All Filesystems. [ OK ] Reached target Final Step. [ OK ] Finished Reboot. [ OK ] Reached target Reboot. [ 582.436469] watchdog: watchdog0: watchdog did not stop! Espressobin gets stuck at this point and requires hardware reset or full power off. It may concomitated with the error message of u-boot log: U-Boot 2022.01-armbian (Mar 05 2022 - 21:54:52 +0100) DRAM: 2 GiB WDT: Not starting watchdog-timer@8300 Other observations, which I made are as follows : 1) u-boot ======= CZ.NIC's Armada 3720 Secure Firmware was not implemented. I haven't noticed a delay for the firmware to initialize DDR and run DDR training algorithm. It produces different CPU voltage : Armbian u-boot @ espressobin v5 SVC REV: 3, CPU VDD voltage: 1.155V compared to mainline u-boot @ espressobin v7 (which I reported earlier here) SVC REV: 5, CPU VDD voltage: 1.225V The difference could arrise from different board versions, but I have no knowledge about it. Here are the 2 u-boot log for comparison : Armbian u-boot @ espressobin v5 ========================== Marvell>> reset resetting ... TIM-1.0 mv_ddr-devel-g7753d4b DDR3 16b 2GB 2CS WTMI-devel-18.12.1-e733e9f-dirty WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):510155aa NOTICE: BL1: Built : 22:37:08, Mar 5 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):510155aa NOTICE: BL2: Built : 22:37:08, Mar 5 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):510155aa NOTICE: BL31: Built : 22:37:08, Mar 5 2022 U-Boot 2022.01-armbian (Mar 05 2022 - 21:54:52 +0100) DRAM: 2 GiB WDT: Not starting watchdog-timer@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 5 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: neta@30000 [PRIME] mainline u-boot @ espressobin v7 ========================== 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) DRAM: 1 GiB Core: 37 devices, 21 uclasses, devicetree: separate WDT: Not starting watchdog-timer@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 As for the "Armbian 22.02.0-trunk Bullseye!" itself : I haven't noticed corrections to terminal and network settings, which we reported with @Pali here: The serial console output settings need to be fixed. It doesn't produce the timestamp. bootargs in boot.cmd setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) ${extraargs}" As it was stated by @Pali : #Remove hardcoded mtdparts= option. U-Boot already supplied correct one via DT. #Missing logs are probably caused by loglevel=1 option. Remove it too. setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait usb-storage.quirks=${usbstoragequirks}, ${extraargs}" I've also found it necessary disabling networkd-dispatcher.service enabled enabled networking.service enabled enabled NetworkManager-dispatcher.service enabled enabled <-- disable NetworkManager-wait-online.service disabled enabled NetworkManager.service enabled enabled <-- disable root@espressobin:/etc/systemd/network# systemctl disable NetworkManager-dispatcher.service Removed /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service. root@espressobin:/etc/systemd/network# systemctl disable NetworkManager.service Removed /etc/systemd/system/multi-user.target.wants/NetworkManager.service. systemd-network-generator.service disabled disabled systemd-networkd-wait-online.service enabled disabled <-- disable systemd-networkd.service enabled enabled root@espressobin:/etc/systemd/network# systemctl disable systemd-networkd-wait-online.service Removed /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service. The eth0 DHCP setting needs to be disabled. root@espressobin:/etc/systemd/network# vi 10-eth0.network [Match] Name=eth0 [Network] #DHCP=ipv4 <<- Otherwise, it produces unnecessary DHCP queries which leads to confusions. #ethXaddr settings need to be disabled as well : root@espressobin:/boot# cat /boot/armbianEnv.txt verbosity=1 emmc_fix=off spi_workaround=off #eth1addr=0E:98:6A:3C:2F:FF #eth2addr=fa:ad:4e:84:25:2f #eth3addr=00:50:43:0d:19:18 ethXaddr should be removed from the u-boot environment settings if any. ethaddr should be set to the MAC printed on espressobin sticker or generated a valid one. More other fixes will be required, but it would be worth fixing at least above ones. I shall try using this setup to build the trunk directly on Espressobin. It will also show the board stability. The main board used to reset itself sporadically with now old u-boot 2019 and older Armbian. Here is the Arbian log : ================ Failed to load '/boot.scr' ## Executing script at 06d00000 Wrong image format for "source" command /boot/ 1063 bytes read in 15 ms (68.4 KiB/s) ## Executing script at 06d00000 240 bytes read in 12 ms (19.5 KiB/s) 21572096 bytes read in 925 ms (22.2 MiB/s) 8908506 bytes read in 392 ms (21.7 MiB/s) Failed to load '/boot/dtb/marvell/armada-3720-community.dtb' 11618 bytes read in 28 ms (404.3 KiB/s) ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8908442 Bytes = 8.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06000000 Booting using the fdt blob at 0x6000000 Loading Ramdisk to 7f27d000, end 7fafbe9a ... OK Using Device Tree in place at 0000000006000000, end 0000000006005d61 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.15.26-mvebu64 (root@builder) (aarch64-linux-gnu-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) #trunk SMP PREEMPT Mon Mar 7 08:48:21 CET 2022 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] printk: bootconsole [ar3700_uart0] enabled Loading, please wait... Starting version 247.3-6 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.36.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 42974/4462976 files, 648013/15567872 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian 22.02.0-trunk Bullseye! [ OK ] Created slice system-getty.slice. [ OK ] Created slice system-modprobe.slice. [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Created slice User and Session Slice. [ OK ] Started Forward Password R…uests to Wall Directory Watch. [ OK ] Set up automount Arbitrary…s File System Automount Point. [ OK ] Reached target Local Encrypted Volumes. [ OK ] Reached target Slices. [ OK ] Reached target Swap. [ OK ] Reached target System Time Set. [ OK ] Listening on RPCbind Server Activation Socket. [ OK ] Listening on Syslog Socket. [ OK ] Listening on fsck to fsckd communication Socket. [ OK ] Listening on initctl Compatibility Named Pipe. [ OK ] Listening on Journal Audit Socket. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Listening on Journal Socket. [ OK ] Listening on Network Service Netlink Socket. [ OK ] Listening on udev Control Socket. [ OK ] Listening on udev Kernel Socket. ... [ OK ] Finished system activity accounting tool. [ OK ] Finished Generate a daily summary of process accounting. [ OK ] Finished Daily man-db regeneration. [ OK ] Finished Rotate log files. [FAILED] Failed to start Wait for Network to be Configured. See 'systemctl status systemd-networkd-wait-online.service' for details. [ OK ] Reached target Network is Online. Starting LSB: Advanced IEEE 802.11 management daemon... Starting /etc/rc.local Compatibility... [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started /etc/rc.local Compatibility. [ OK ] Started Getty on tty1. [ OK ] Started Serial Getty on ttyMV0. [ OK ] Reached target Login Prompts. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Finished Update UTMP about System Runlevel Changes.
  10. I was building on Debian 10 host. It would be quite cumbersome to reinstall everything. I don't have currently another spare host. I am waiting for the cable for my new espressobin setup running Bullseye. Once it gets delivered, I'll be able using it for the new build. Will it be possible to build image on an Arm system? Alternatively, could I reproduce the last failed step from Bullseye@espressobin, thus creating the image on a different host ?
  11. I followed your build instructions. I understand that all components sources were build successfully, but the final image creation failed as follows : ... I: Extracting mount... I: Extracting util-linux... I: Extracting libxxhash0... I: Extracting liblzma5... I: Extracting zlib1g... [ o.k. ] Installing base system [ Stage 2/2 ] W: Failure trying to run: /sbin/ldconfig W: See //debootstrap/debootstrap.log for details [ error ] ERROR in function create_rootfs_cache [ main.sh:578 -> main.sh:539 -> debootstrap.sh:58 -> debootstrap.sh:238 -> general.sh:0 ] [ error ] Debootstrap base system for current espressobin bullseye no second stage failed [ o.k. ] Process terminated [ error ] unmount_on_exit() called! [ main.sh:1 -> image-helpers.sh:0 ] [ o.k. ] Unmounting [ /mnt/sda1/Armbian.src/build/.tmp/rootfs-9e4f7fab-ad4f-4c4e-b9da-7fb6b4637f04/ ] [ 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: 19385.060161 seconds I do not see any problem with root@deb10:~# /sbin/ldconfig --version ldconfig (Debian GLIBC 2.28-10) 2.28 Copyright (C) 2018 Free Software Foundation, Inc. I was unable to find debootstrap.log on the system. Could it be fixed ? Mainline u-boot images were created successfully. But I haven't tried them with espressobin, waiting for the base system image generation completed without error. The following packages were built: root@deb10:/mnt/sda1/Armbian.src/build# ls -al output/debs/ total 458112 drwxrwxr-x 3 root root 4096 Mar 6 15:19 . drwxrwxr-x 8 root root 4096 Mar 6 15:19 .. -rw-r--r-- 1 root root 418388 Mar 6 15:19 armbian-bsp-cli-espressobin_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 126972 Mar 6 15:11 armbian-config_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 7987392 Mar 6 15:11 armbian-firmware_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 240743148 Mar 6 15:19 armbian-firmware-full_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 2251236 Mar 6 15:11 armbian-zsh_22.02.0-trunk_all.deb drwxrwxr-x 2 root root 4096 Mar 6 09:59 extra -rw-r--r-- 1 root root 27448 Mar 6 15:11 linux-dtb-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 11848012 Mar 6 15:11 linux-headers-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 34116236 Mar 6 15:11 linux-image-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 1179588 Mar 6 15:11 linux-libc-dev_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 169641548 Mar 6 11:03 linux-source-current-mvebu64_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 729576 Mar 6 10:54 linux-u-boot-current-espressobin_22.02.0-trunk_arm64.deb
  12. Could you provide with more detailed directions for the above tasks, so that they could be executed? Our recent experience with @Pali building mainline u-boot could serve as a good example and practice.
  13. Could you be more specific if anything needs to be done.
  14. It doesn't help either. Log mount is saturating VEEERY quickly. While I was installing different services, I was blocked several times with the log mount reaching the limits. The whole armbian-ramlog service needs to be revisited.
  15. Yes, you are right and thanks for looking into it. There exist several varieties of dtb : -rwxr-xr-x 1 root root 11K Aug 25 21:19 armada-3720-espressobin.dtb -rwxr-xr-x 1 root root 12K Aug 25 21:19 armada-3720-espressobin-emmc.dtb -rwxr-xr-x 1 root root 11K Aug 25 21:19 armada-3720-espressobin-v7.dtb and each board needs adjustments in boot.cmd. So I changed to: setenv fdt_name_a dtb/marvell/armada-3720-community.dtb #setenv fdt_name_b dtb/marvell/armada-3720-espressobin.dtb setenv fdt_name_b dtb/marvell/armada-3720-espressobin-v7.dtb followed by # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Now physical port positions correspond to dtb settings and there is no confusion with cables.
×
×
  • Create New...