[SOLVED] Inode No. 12

sjox · Yesterday 19:03:07

With the new update (Debian 13.2) an updated Cups is also included!
This installs a file "dnssd" in the directory "/usr/lib/cups/backend-available/" and two further hard links
in the directory "/usr/lib/cups/backend"! (dnssd and mdns). The Inode was 12!
Of course you can view these files or directories using "ls -li"!
But that changes after a reboot!
If I try to list this directory on my PC using "ls -l" I get the message: "The structure must be cleaned up"!
(dnssd is only displayed with ? and the file system is shot!!)
Then I get the message for each following command: "input/output error"
A following "fsck.ext4 -y -f /dev/nvme0n1p3" reports "invalid inode 12".

(I noticed this problem due to an AIDE check - after this check the filesystem was shot!)

The question now is how a simple "ls -l" can shoot the whole file system?
(It must be because of the Inode 12!)
I helped myself by simply reinstalling cups using "--reinstall".
This gave the file (and the two hardlinks) another inode!
However, if I install Cups a third time - Inode 12 is active again!
Therefore, 12 is always preferred - except for this inode is already in use!
I was also able to replicate this with other files.
For example, as soon as I copy a normal text file into this directory, this file had the inode 12!
With the command "find / -inum 12" I also found other system files!

Now my questions:
Why is it that Inode 12 is awarded?
Apparently, this is only intended for system-related files!
Also, this behavior occurs in others or I am the only one

g4sra · Yesterday 19:16:24

find / -xdev -inum 12

stultumanto · Today 08:57:45

OK, I have no idea what this is really about, but you have me curious. I checked three different Linux installations on ext4, and none had inodes 3-10 or 12. In every case, / was inode 2, /lost+found was inode 11, and everything else was inodes 13 & up. I can't find anything about this subject with any search engine.

sjox · Today 09:50:12

As it looks, not many should have this problem!
I'm probably the only one...

Thanks to "g4sra" and "stultumanto"!

The result of "find":

find / -xdev -inum 12
/usr/lib/cups/backend-available/Hello_No12.txt

It's the only with Inode 12!

or:

find / -inum 12
/dev/console
/sys/hypervisor
/sys/fs/cgroup/memory.pressure
/usr/lib/cups/backend-available/Hello_No12.txt
/run/user/1000/at-spi/bus_0

Then I rebooted and started immediately from the "Devuan-Excalibur-Live-System" (Ventoy)!
(so it was NOT booted from the built-in SSD)

The result:

fsck.ext4 -n -f /dev/nvme0n1p3
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Orphan file inode 12 is not in use, but contains data.  Clear? no

Pass 2: Checking directory structure
Entry 'Hello_No12.txt' in /usr/lib/cups/backend-available (26756) has invalid inode #: 12.
Clear? no

Pass 3: 

and so on...

The SSD was shot down already when driving down!

The result is always the same - no matter what directory - as soon as Inode number 12 is assigned anywhere,
then the file system is shot.

That's why I've also asked the artificial intelligence (https://you.com/?chatMode default)

I have shortened the answer:

Summary:
• Inodes 1–11 are reserved for special purposes in ext4.
• Inode assignment is automatic and based on the first available inode.
• You cannot directly control inode numbers during file creation.
• Consistent problems with inode 12 suggest underlying file system corruption or hardware issues .
• Inode 12 corresponds to one specific file or directory at a time.
• The inode stores metadata, not the filename.
• Filenames are directory entries that point to inode numbers.
• Multiple filenames can share the same inode (hard links).
• When a file is deleted, its inode number (like 12) can be reused for new files.
This explains why your copied file often gets inode 12:
it is the first free inode available after the reserved ones, and inode 12 is assigned to the new
file until it is deleted or the file system changes.
Recommendation:
Consider running a thorough fsck and, if possible, reformatting the file system to ensure there is no
persistent corruption. If the problem persists, it may be a hardware issue or a bug in the file system implementation.

This sounds plausible - so I will format the SSD and reset the system!

sjox · Today 16:39:55

It works!
Due to a flash of inspiration, I have saved the root partition using fsarchiver, reformatted and played back!
Fsarchiver also secures the UUid and other attributes but apparently the inodes are reassigned!

Result:

root@pchome1:~# touch /usr/lib/cups/backend-available/Hallo_No12.txt
root@pchome1:~# 
root@pchome1:~# ls -li /usr/lib/cups/backend-available/
insgesamt 192
1088658 -rwxr--r-- 3 root root 22760  5. Nov 15:45 dnssd
1101290 -rw-r--r-- 1 root root     0 17. Nov 16:36 Hallo_No12.txt
1088659 -rwxr--r-- 2 root root 51520  5. Nov 15:45 lpd
1088657 -rwxr-xr-x 2 root root 30952  5. Nov 15:45 snmp
1088660 -rwxr-xr-x 2 root root 47424  5. Nov 15:45 socket
1088656 -rwxr--r-- 2 root root 35048  5. Nov 15:45 usb
root@pchome1:~# 
root@pchome1:~# 
root@pchome1:~# find / -xdev -inum 12
/sbin
root@pchome1:~# 
root@pchome1:~# ls -li /sbin
12 lrwxrwxrwx 1 root root 8  3. Nov 19:25 /sbin -> usr/sbin
root@pchome1:~#

There are now completely different inodes and the inode 12 is fixed to "/sbin"!
(now he can't bluff in any other way)
"fsck.ext4" does not return any errors anymore!

Unfortunately, I have no explanation why,when,who...

Thus done
Thanks again

The officially official Devuan Forum!

#1 Yesterday 19:03:07

[SOLVED] Inode No. 12

#2 Yesterday 19:16:24

Re: [SOLVED] Inode No. 12

#3 Today 08:57:45

Re: [SOLVED] Inode No. 12

#4 Today 09:50:12

Re: [SOLVED] Inode No. 12

#5 Today 16:39:55

Re: [SOLVED] Inode No. 12

Board footer