Skip to content
Snippets Groups Projects

stage1: don't symlink /proc if in docker

Open stage1: don't symlink /proc if in docker
WolleTD/debootstrap:proc-in-docker into master
Open Eicke Herbertz requested to merge WolleTD/debootstrap:proc-in-docker into master

When commit 5a0f1666 originally introduced docker support, it symlinked /proc to the containers' /proc. In a privileged container, this will result in stage1 unmounting the containers' /proc through the symlink, which is obviously not good.

Then, commit 87cdebbc finally provided a fix for this by deleting the symlink and recreating the /proc directory. Related merge requests are !26 and !27 (closed) (which would both be closed by this).

This broke reproducibility in debuerreotype when changing from debootstrap 1.0.123 to 1.0.126, because /proc has a different timestamp. Previously, the symlink got replaced when extracting base-files (which makes the whole symlink thing questionable), now it just already exists.

Anyway, we got a special case for docker that works around a special case for docker. We can just remove both.

Edited by Eicke Herbertz

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Eicke Herbertz changed the description

    changed the description

  • Eicke Herbertz added 1 commit

    added 1 commit

    • 85971f3e - stage1: don't symlink /proc if in docker

    Compare with previous version

  • Eicke Herbertz added 1 commit

    added 1 commit

    • 84ed7434 - stage1: don't symlink /proc if in docker

    Compare with previous version

  • Eicke Herbertz
    Eicke Herbertz @WolleTD ·
    Author

    Removed the manual changelog entry.

  • Dimitri Ledkov
    Dimitri Ledkov @xnox ·
    Developer

    how can i test this to ensure we don't break this?

    Should we run a test that one can do debootstrap inside docker containers? Any examples of existing users of this / their dockerfiles?

    How to check for reproducibility? Should one do download stage; debootstrap twice; and the two chroots should be the same? how is this performed / detected?

  • Tianon Gravi
    Tianon Gravi @tianon ·
    Contributor

    I'm guessing there's a better way to validate this specific bug, but here's a simple example/reproducer at least:

    $ debootstrap --variant=minbase unstable /tmp/rootfs http://snapshot.debian.org/archive/debian/20220930T000000Z

    Before the changes in this MR:

    $ ls -ld /tmp/rootfs/proc
drwxr-xr-x 2 root root 40 Oct 14 22:27 /tmp/rootfs/proc

    After the changes in this MR:

    $ ls -ld /tmp/rootfs/proc 
drwxr-xr-x 2 root root 40 Jan 19  2022 /tmp/rootfs/proc

    If you want to do full reproducibility testing with just debootstrap though, I think @holger has done some recent work in that area and might be willing to offer some good pointers faster than I could reinvent/extract them from debuerreotype. :sweat_smile: :bow:

    Edit: probably something like https://salsa.debian.org/qa/jenkins.debian.net/-/blob/0d75fe0efc254ab652068abe3acd681f7675db25/bin/reproducible_debstrap.sh :smile:

    Edited by Tianon Gravi
  • Tianon Gravi
    Tianon Gravi @tianon ·
    Contributor

    @xnox we get a little bit of this indirectly thanks to debuerreotype's autopkgtests:

    There's apparently another reproducibility issue with the latest uploads:

    + diffoscope /tmp/tmp.9C9tZANVvF/expected.tar /tmp/tmp.9C9tZANVvF/actual.tar
--- /tmp/tmp.9C9tZANVvF/expected.tar
+++ /tmp/tmp.9C9tZANVvF/actual.tar
├── file list
│ @@ -1779,15 +1779,15 @@
│  -rw-r--r--   0        0        0      286 2016-11-27 18:29:38.000000 usr/share/base-files/motd
│  -rw-r--r--   0        0        0      767 2016-03-04 11:00:00.000000 usr/share/base-files/profile
│  -rw-r--r--   0        0        0      607 2016-03-04 11:00:00.000000 usr/share/base-files/profile.md5sums
│  -rw-r--r--   0        0        0      771 2012-06-09 10:00:00.000000 usr/share/base-files/staff-group-for-usr-local
│  drwxr-xr-x   0        0        0        0 2017-01-01 00:00:00.000000 usr/share/base-passwd/
│  -rw-r--r--   0        0        0      446 2016-12-02 20:47:28.000000 usr/share/base-passwd/group.master
│  -rw-r--r--   0        0        0      877 2016-12-02 20:47:28.000000 usr/share/base-passwd/passwd.master
│ -drwxr-xr-x   0        0        0        0 2016-03-11 11:32:47.000000 usr/share/bash-completion/
│ +drwxr-xr-x   0        0        0        0 2016-11-08 12:29:50.000000 usr/share/bash-completion/
│  drwxr-xr-x   0        0        0        0 2017-01-01 00:00:00.000000 usr/share/bash-completion/completions/
│  -rw-r--r--   0        0        0      447 2016-11-08 12:29:50.000000 usr/share/bash-completion/completions/addpart
│  -rw-r--r--   0        0        0     7035 2016-12-08 14:21:16.000000 usr/share/bash-completion/completions/apt
│  -rw-r--r--   0        0        0      571 2016-11-08 12:29:50.000000 usr/share/bash-completion/completions/blkdiscard
│  -rw-r--r--   0        0        0     1395 2016-11-08 12:29:50.000000 usr/share/bash-completion/completions/blkid
│  -rw-r--r--   0        0        0      726 2016-11-08 12:29:50.000000 usr/share/bash-completion/completions/blockdev
│  -rw-r--r--   0        0        0      546 2016-11-08 12:29:50.000000 usr/share/bash-completion/completions/cfdisk

    Best I can figure is that we've changed the order in which packages get extracted, so /usr/share/bash-completion is now getting extracted at a different time and created for the first time via a different package than it was before?

Please register or sign in to reply