Debian: Duplicate inode on the same filesystem

[Dan Voiculeasa]

Brief Description
-----------------
After installing the iso some files have the same inode.

Severity
-----------------
Critical: System/Feature is not usable after the defect

Steps to Reproduce
-----------------
Install iso.

Expected Behavior
-----------------
Files on the same filesystem don't have the same inode.

Actual Behavior
-----------------
Some files have the same inode on the same filesystem.

Reproducibility
-----------------
100% reproducible

System Configuration
-----------------
AIO-DX, AIO-SX

Load info (eg: 2022-03-10_20-00-07)
-----------------
Loads older than 21 June 2022, but I think this is day 0.

Last Pass
-----------------
?

Timestamp/Logs
-----------------
Proof of double inode, just after installing the iso (before running ansible bootstrap) :
root@controller-0:/var/home/sysadmin# cat /var/lib/dpkg/triggers/Unincorp /var/lib/nfs/rmtab
root@controller-0:/var/home/sysadmin# echo 1 >> /var/lib/dpkg/triggers/Unincorp
root@controller-0:/var/home/sysadmin# cat /var/lib/dpkg/triggers/Unincorp /var/lib/nfs/rmtab
1
1

root@controller-0:/var/home# df -h /var/lib/nfs/rmtab
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 20G 5,6G 13G 30% /var
root@controller-0:/var/home# df -h /var/lib/dpkg/triggers/Unincorp
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 20G 5,6G 13G 30% /var

Alarms
-----------------
N/A

Test Activity
-----------------
Developer Testing

Workaround
-----------------
For the specific issue observed: recreate the affected files.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/integ/+/852388
Committed: https://opendev.org/starlingx/integ/commit/2b1fbfd4bc5e8daa8fc2319af539ed82d36a20de
Submitter: "Zuul (22348)"
Branch: master

commit 2b1fbfd4bc5e8daa8fc2319af539ed82d36a20de
Author: Zhang Xiao <email address hidden>
Date: Sat Aug 6 05:42:23 2022 -0700

    Debian: Break hardlinks in /var

    Here the root filesystem is managed by OSTree. OSTree is designed to
    manage/deploy read-only filesystem. For read-only filesystem, hardlink
    all files with same content is safe and can save disk space. It is a
    good principle for readonly folders like /bin, /lib and so on. While
    "/var" is somehow special that it is designed to store variable data
    files, it can not be read-only, it must be read-write. Files in
    "/var" should not be hardlinked together like other folders, break
    them to make it.

    Do the same for /usr/homedirs/home as it gets mounted at /var/home
    at runtime.

    Test Plan:
    Pass: build ISO image
    Pass: In runtime system, no hardlink in /var

    Story: 2008862
    Task: 45966
    Related-Bug: #1983580

    Change-Id: I1a61f919e0a60f83e27b6c0bf402c20c2d43abb4
    Signed-off-by: Zhang Xiao <email address hidden>

[Ghada Khalil (gkhalil)]

@Xiao Zhang, can this bug be marked as Fix Released or are there additional fixes expected?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/starlingx/tools/+/858754

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/tools/+/858754
Committed: https://opendev.org/starlingx/tools/commit/73eead68fd11dba5e5cbeb63ee0c7f29f6a3fd4c
Submitter: "Zuul (22348)"
Branch: master

commit 73eead68fd11dba5e5cbeb63ee0c7f29f6a3fd4c
Author: Charles Short <email address hidden>
Date: Wed Sep 21 10:30:01 2022 -0400

    debian: Move dpkg database to /usr

    Move the dpkg database /var/lib/dpkg to /usr/share/dpkg/database.
    This is being done so ostree does not corrupt the package database
    if its in a read-only mode.

    A symlink the database on /usr to where dpkg expects to find it
    so packages operations dont break.

    Test Plan:
    Pass: build ISO image
    Pass: In runtime system, run dpkg -l | grep base-files succesfully.

    Story: 2008862
    Task: 45966
    Related-Bug: #1983580

    Signed-off-by: Charles Short <email address hidden>
    Change-Id: I2e679d038299ed731033b51751152457c78d9618