Subject: Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task

From: Frans Pop <[email-masked]>
Date: Sat, 25 Jul 2009 03:21:00 +0200

Package: pkgsel
Version: 0.25

tasksel wants to do in the target chroot:
tasksel/tests/desktop:  disk=$(df -P /usr | tail -1 | awk '{print $4}')

But this fails with:
in-target: df:
in-target: Warning: cannot read table of mounted file systems
in-target: : No such file or directory

Probably related to the problem reported by Martin re. initramfs-tools:
an incorrect state of /etc/mtab in /target. It may also a result of the 
change Colin committed in debootstrap this week.

---

From: Colin Watson <[email-masked]>
Date: Sat, 25 Jul 2009 11:10:24 +0100

> change Colin committed in debootstrap this week.

Mm, yes, that's probable, although without that change it would
presumably have been getting garbage data from /etc/mtab anyway. (df
doesn't seem to fall back to /proc/mounts.)

Perhaps we should temporarily make /target/etc/mtab a symlink to
/proc/mounts while running tasksel? Eventually I believe the plan is to
do that in the regular system anyway, but until the rest of the world
catches up ...

-- 
Colin Watson                                       [[email-masked]]

---

From: Frans Pop <[email-masked]>
Date: Sat, 25 Jul 2009 14:55:57 +0200

On Saturday 25 July 2009, Colin Watson wrote:
> > Probably related to the problem reported by Martin re.
> > initramfs-tools: an incorrect state of /etc/mtab in /target. It may
> > also a result of the change Colin committed in debootstrap this week.
>

Won't that have the /target prefix in it for some mounts and thus be 
unusable inside a chroot?

---

From: Colin Watson <[email-masked]>
Date: Sun, 26 Jul 2009 10:59:36 +0100

> unusable inside a chroot?

/proc/mounts is sensitive to the root directory of the process reading
it.

---

From: Frans Pop <[email-masked]>
Date: Sun, 26 Jul 2009 20:12:41 +0200

> /proc/mounts is sensitive to the root directory of the process reading

Well, only to a degree. It will still show all the mounts of the host 
system besides the ones in the chroot. So you'd have to be damned careful 
when parsing it.

fjp@aragorn:~$ grep proc /proc/mounts
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
proc /srv/chroots/amd64-etch/proc proc rw,relatime 0 0
proc /srv/chroots/amd64-sid/proc proc rw,relatime 0 0
proc /srv/chroots/i386-sid/proc proc rw,relatime 0 0

fjp@aragorn:~$ sudo chroot /srv/chroots/amd64-sid

(amd64-sid)root@aragorn:/# grep proc /proc/mounts
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
proc /srv/chroots/amd64-etch/proc proc rw,relatime 0 0
proc /proc proc rw,relatime 0 0
proc /srv/chroots/i386-sid/proc proc rw,relatime 0 0

In the example above, how would you know to take the third line and not 
the first line?

You could have something like:
/dev/hda1 /home [...]
/dev/hda2 /chroot/home [...]

Which in the chroot would show up as:
/dev/hda1 /home [...]
/dev/hda2 /home [...]

Probably in the D-I case the mounts in the D-I environment are normally 
straightforward enough [1] so they can be taken into account, but it 
still seems quite tricky. We'd have to be careful about /.
Even then it seems to me that we could easily have breakage if a user 
mounts anything manually in unexpected places.

[1] Especially as we use an unusual dir for hd-media; maybe we should 
consider also using an unusual dir for the installation CD in the D-I 
environment.