[Critical dpkg usr-merge warning on ODROID HC4 - Production NAS affected (RAID1+LUKS)]

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.

[Critical dpkg usr-merge warning on ODROID HC4 - Production NAS affected (RAID1+LUKS)]

vor 2 Minuten schrieb eselarm:

You should also mention what OS/distro it is based (Debian or Ubuntu) , see /etc/os-release

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"

[Critical dpkg usr-merge warning on ODROID HC4 - Production NAS affected (RAID1+LUKS)]

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