Cannot open debian distrobox due to tzdata issue

[john-ghatas]

Might be a regression, but when tzdata needed an update it threw up [x has stale file handle] and after a reboot re entering the distrobox showed the following error in the logs.

The following packages will be upgraded:
  tzdata
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
35 not fully installed or removed.
Need to get 301 kB of archives.
After this operation, 6144 B of additional disk space will be used.
Get:1 http://http.us.debian.org/debian unstable/main amd64 tzdata all 2023c-3 [301 kB]
Preconfiguring packages ...
Fetched 301 kB in 1s (440 kB/s)
(Reading database ... 304168 files and directories currently installed.)
Preparing to unpack .../tzdata_2023c-3_all.deb ...
Unpacking tzdata (2023c-3) over (2023c-2) ...
dpkg: error processing archive /var/cache/apt/archives/tzdata_2023c-3_all.deb (--unpack):
 unable to make backup link of './usr/share/zoneinfo/Etc/UTC' before installing new version: Invalid cross-device link

[89luca89]

Hi @john-ghatas
I'm not able to reproduce this, please can you give more info on how to reproduce this issue? Thanks

[john-ghatas]

• Create a box with an older image

distrobox create -i debian:unstable-20221004 -n debian-test

• Enter the box
• Add the non-free repos etc

echo "deb http://http.us.debian.org/debian unstable main contrib non-free non-free-firmware" | sudo tee -a /etc/apt/sources.list
sudo apt update

• Run an update on tzdata

sudo apt --only-upgrade install tzdata

You should see output like this:

Without adding the extra repos the updates run just fine

[john-ghatas]

I tried the same with an ubuntu container, this issue is not there. After further testing (downgrading/upgrading the tzdata package) I have isolated it to debian with the non-free repositories enabled. Not sure what can be done here to fix it. It might be an error in the way I added the extra repos

[starquake]

I have the same issue with updating a debian distrobox. Steps to reproduce:

• distrobox create -i debian:11 -n issue-715
• distrobox enter issue-715
  inside the distrobox run:
• sudo apt-get update
• sudo apt-get upgrade

It will try to upgrade tzdata and fail.

As a temporary workaround i'm skipping updating tzdata:
sudo apt-mark hold tzdata

[frasertajima]

thank you starquake for:

sudo apt-mark hold tzdata

I can finally get back to installing pytorch, tensorflow and tensorflowRT on Fedora Silverblue 38 (by the way, distrobox was not installed on a clean re-install of FS 38).

[tazihad]

same with ubuntu 22.04.

[john-ghatas]

Not an issue here, have you enabled any third party repo that might be causing this? Also what distrobox version are you running this is fixed for ubuntu at least on the repo version.

[tazihad]

@john-ghatas distrobox: 1.4.2.1
this is the command trying to install ubuntu-22-04

distrobox create --name ubuntu-22-04 --image quay.io/toolbx-images/ubuntu-toolbox:22.04 --home /var/home/yol1/distrobox/ubuntu-22-04

that's pretty much it. I can't apt update. As it shows same error as you.

[john-ghatas]

Did you install distrobox from the repos of your distro or are you running the git version. I don't see these issues with ubuntu on the git version

[john-ghatas]

Small update, seeing the issue on the latest distrobox git version as well. For now I've held the package back

dpkg: error processing package tzdata (--remove):
 unable to securely remove '/usr/share/zoneinfo/Etc/UTC': Device or resource busy

[89luca89]

Pushed a potential fix with 1cde681

Now tzdata is added at the beginning and then mark hold it, we don't need update to this anyway as we sync with host

I'll wait feedbacks before closing this

[89luca89]

Fixed the bug, it was not in that commit but this last one finally.

Sadly you will need to recreate the container for it to be effective, as we move the localtime mount from podman to the init

[luc14n0]

I can confirm that for newly created containers the issue is gone, APT doesn't try to update it anymore. For people not willing to recreate the container, they can circumvent the issue by adding something like this in their shell profile config file:

test "${CONTAINER_ID}" = "MY_CONTAINER_NAME" && sudo apt-mark hold tzdata

[luc14n0]

Fixed the bug, it was not in that commit but this last one finally.

Sadly you will need to recreate the container for it to be effective, as we move the localtime mount from podman to the init

Just to be clear on my end. I tested the first commit - well, only the part about tzdata -, not the second. My
comment came through before I realized the existence of this one.

[89luca89]

Right now this is solved
simply the idea of using hooks to umount/remount the r-o files was ok
problem was, something mounted by podman using --volume is really going to stick
so I just moved the mounting to inside the init so it's possible do umount/remount clearly and now tzdata update works

[luc14n0]

That's good to know. Thanks for the fix 👍