Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reproducibility: timestamp of /proc changes when using bookworm? #134

Open
WolleTD opened this issue Jun 11, 2022 · 5 comments · May be fixed by #146
Open

Reproducibility: timestamp of /proc changes when using bookworm? #134

WolleTD opened this issue Jun 11, 2022 · 5 comments · May be fixed by #146

Comments

@WolleTD
Copy link
Contributor

WolleTD commented Jun 11, 2022 •
edited

I changed the image to bookworm to be able to build Ubuntu 22.04 images.
It seems that this host change breaks the reproduciblity of the images in a stupid-as-usual way: /proc gets a different mtime (from a buster-image):

 drwxr-xr-x   0        0        0        0 2022-06-11 20:18:32.000000 media/
 drwxr-xr-x   0        0        0        0 2022-06-11 20:18:32.000000 mnt/
 drwxr-xr-x   0        0        0        0 2022-06-11 20:18:32.000000 opt/
-drwxr-xr-x   0        0        0        0 2022-03-19 13:46:00.000000 proc/
+drwxr-xr-x   0        0        0        0 2022-06-11 20:18:32.000000 proc/
 drwx------   0        0        0        0 2022-06-11 20:18:32.000000 root/
 -rw-r--r--   0        0        0      571 2021-04-10 20:00:00.000000 root/.bashrc

Where the green line is from the image built on bullseye. The mtime of the bookworm image corresponds to the InRelease timestamp (I build debian from live repos with --non-debian), so this is done by debuerreotype-fixup. The older time is from the data.tar.xz in the base-files package.

I don't see why bookworm would modify /proc, but bullseye would not. If bullseye would modify /proc, I'd expect it to be moved back to $epoch as well. Any ideas?
@WolleTD
Copy link
Contributor Author

WolleTD commented Jun 12, 2022 •
edited

Ah, well, it's this coming back around, it seems.

I had a quick patch in my internal Dockerfile for that (which was focal-based for different reasons and had this issue the last two years already). Copying it into the debuerreotype Dockerfile fixes the issue:
WolleTD@470c450

@WolleTD
Copy link
Contributor Author

WolleTD commented Jun 12, 2022 •
edited

It's not the whole story though. debootstrap versions are:

  • bullseye: 1.0.123
  • bookworm 1.0.126
  • focal: 1.0.118

So apparently the issue skipped bullseye and/or version 1.0.123, but is present in both older and newer versions, but from what I see in the Git history (and trusting my past self to link the relevant commits in the MR-comment, glad there are any links at all), this behaviour should be unchanged since 1.0.107.

@tianon
Copy link
Collaborator

tianon commented Jun 13, 2022

😩

Is it possible something changed in base-files, which technically owns /proc? Maybe the debootstrap change interacting with base-files owning /proc in a strange way?

@WolleTD
Copy link
Contributor Author

WolleTD commented Jun 13, 2022

First, I probably have to run a dedicated test with focal, because that patch is two years old. I knew the symptoms and it obviously fits together, but I have to be sure. Probably will be confirmed, though.

Then we got debootstrap 1.0.126 in bullseye-backports, so I will try that as well. I really don't know what to expect.
If it fails in bullseye as well, Ubuntu probably has a patch in debootstrap that landed in Debian between .123 and .126.
If it still works, we have to look at the rest of the system. 😦

@WolleTD
Copy link
Contributor Author

WolleTD commented Jun 14, 2022

Some relief:

  1. focal is working unpatched (now?), probably that patch was required for my CI setup back then (privileged containers?). Doesn't matter, it's working.
  2. bullseye with backported debootstrap 1.0.126 is not working without the patch (but fine with)

So it's between debootsrap 1.0.123 and 1.0.126. Precisely, here: https://salsa.debian.org/installer-team/debootstrap/-/commit/87cdebbcad6f4e16ba711227cbbbd70039f88752
Yet another workaround adding code to debootstrap trying to handle /proc in docker. Instead of keeping debootstrap from creating the link in the first place (what the patch does), it's now removed and recreated.
Guess I have to figure out how to (successfully) contribute to debootstrap myself 😃

@tianon tianon linked a pull request Oct 14, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add "unstable"-based test to validate recent debootstrap uploads tianon/debuerreotype-pr-fork
2 participants
@tianon @WolleTD