dpkg failed: Value too large for defined data type

I recently ran into this cryptic dpkg error after trying to install a package with apt. On top of telling me nothing, it also triggered when dpkg would try to stat the path "/.". WAT?

Now, for some context: I am running this in a SBC (OrangePi) with an SSD card that's quite large (64GB).

After a little digging I found out that this is usually a response from a syscall, when some unusual thing tries to stat the root folder. If this system call runs on a 32-bit system with up to 2GB of disk, that's okay. But since my root partition is quite big, it will fail.

This is rather unusual and it's not really because of the 64GB card per se... I did a full system upgrade prior to installing a new package, and dpkg was just fine.

So what gives?

Debugging

I'm using apt from a terminal, which in turn uses dpkg to manage system packages.

dpkg has a --debug option, which is an octal number with a mask. When apt failed to install, the output told me there was an issue with unpacking a file from /var/cache/apt/archives/xxx.deb.

Some more research, and I find this thread with some interesting clues. Although it does mention the 2GB limit, tt was not quite the problem.

I tried to reproduce the issue by creating a new environment from scratch with a smaller partition type, which worked well, then resize it to 8GB on a new sdcard. That actually does trigger the error again.

Next, I tried to run dpkg directly, with the .deb file that failed, and a debug flag to give more tidbits:

dpkg -D77777 -i /var/cache/apt/archives/xxx.deb

Lots of text later...

D000001: root= admindir=/var/lib/dpkg
...
D000010: tarobject ti->name='.' mode=40755 owner=0:0 type=53(d) ti->linkname='' namenode='/.' flags=2 instead='<none>'
D000100: setupvnamevbs main='/.' tmp='/..dpkg-tmp' new='/..dpkg-new'

One weird thing that caught my attention here: root=. Note that there's no value for root. This means dpkg does not know what the root folder is, and keeps walking upwards in the file system and testing directories.

OK... We are getting somewhere... So the solution is actually rather simple, and does not involve complicated partition resizes and painful system fixes: we go to /etc/dpkg/dpkg.cfg and add one line there:

root=/

I know right? So silly! But that fixed the error! After that change, I could run apt install again and get on with my work.

Now, I don't know when that started, but surely it's a pattern. I had the same issue in two different boards, starting with Debian Stretch and doing a full upgrade all the way to bookworm.

Fast-forward a few days and the error is back! This time, I knew it was not due to a partion size, so I tried an even sillier thing: touch /. and run my install command again.

Armbian is messed up somewhere, but I don't have the time to dig that up. Now everytime my dpkg fails, I create the empty /. file again.

So there you go! Thank me later!