x-mode

URGENT: Kernel update already applied, bootloader points to 6.12.58! Current state: - Running: 6.12.44 - Boot configured for: 6.12.58 (symlinks updated) - usr-merge still broken (duplicate files in /bin, /sbin) Questions: 1. Should I revert boot symlinks to 6.12.44 immediately? 2. ODROID HC4 specific: Which file actually boots (Image vs vmlinuz)? 3. Will 6.12.58 boot with broken usr-merge? 4. Emergency procedure if forced to reboot? NOTE: I'm NOT taking any action until getting community advice.

Pardon me, something's always missing 😅 cat /etc/os-release PRETTY_NAME="Armbian 25.11.2 noble" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=noble LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 25.11.2 noble"

System Overview Hardware: ODROID HC4 OS: Armbian (current version) Kernel: 6.12.44-current-meson64 Use case: Production NAS with critical data Problem Description During apt upgrade, the following critical warnings appear: dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's dpkg: warning: back, breaking its core assumptions. This can cause silent file dpkg: warning: overwrites and disappearances System state analysis reveals: /bin, /sbin, /lib are correct symlinks to /usr/* BUT: Files exist in duplicate (/bin/bash and /usr/bin/bash identical) DKMS cannot build kernel modules (missing headers) systemd cannot set journal flags (symlink to SD card) NAS Configuration (Critical Infrastructure) Storage Setup: RAID1 with mdadm (two HDDs) + LUKS encryption /var/log relocated to SD card Filesystem: /dev/mmcblk0p1: LABEL="armbi_root" TYPE="ext4" /dev/sda: TYPE="crypto_LUKS" /dev/sdb: TYPE="crypto_LUKS" /dev/mapper/sda_luks: TYPE="linux_raid_member" /dev/mapper/sdb_luks: TYPE="linux_raid_member" /dev/md0: TYPE="ext4" Reproduction $ ls -la /bin /sbin /lib lrwxrwxrwx 1 root root 7 Apr 22 2024 /bin -> usr/bin lrwxrwxrwx 1 root root 7 Apr 22 2024 /lib -> usr/lib lrwxrwxrwx 1 root root 8 Apr 22 2024 /sbin -> usr/sbin $ ls -la /usr/bin/bash /bin/bash -rwxr-xr-x 1 root root 1543048 Mar 31 2024 /bin/bash -rwxr-xr-x 1 root root 1543048 Mar 31 2024 /usr/bin/bash # DUPLICATE! Urgent Questions 1. Root Cause Analysis Has anyone experienced this specific issue with Armbian on ODROID HC4? Is this a known upgrade problem with a particular Armbian version? 2. Solution Paths Which approach do you recommend for a production NAS? A) System repair tool (is there an Armbian-specific one?) Manual cleanup - any experiences with this? C) Migration to new image - best method with LUKS+RAID? D) Install kernel headers first despite warnings? 3. Migration Strategy with LUKS How to safely migrate: LUKS configuration (keys, passphrases) mdadm RAID1 setup Samba/NFS shares and ACLs WireGuard configuration Risk Assessment Current risk: Silent data corruption possible Kernel updates may break filesystem modules System might not boot after next reboot Time pressure: NAS must remain available, but security is top priority. System Details # dpkg --version Debian 'dpkg' package management program version 1.22.6 (arm64). # uname -a Linux odroidhc4 6.12.44-current-meson64 #3 SMP PREEMPT Thu Aug 28 14:31:16 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux # cat /etc/armbian-image-release BOARD=odroidhc4 BOARD_NAME="Odroid HC4" VERSION=25.2.1 REVISION=25.2.1 IMAGE_UUID=54c1127b-9e70-4d3f-bedd-3faf1f5e58fa BUILD_REPOSITORY_COMMIT=1f6972065 Request for assistance with: Immediate actions to stabilize the system Proven migration method for Armbian+ODROID+LUKS Experiences with this specific bug