Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task
On Sunday 26 July 2009, Colin Watson wrote:
> On Sat, Jul 25, 2009 at 02:55:57PM +0200, Frans Pop wrote:
> > Won't that have the /target prefix in it for some mounts and thus be
> > unusable inside a chroot?
>
> /proc/mounts is sensitive to the root directory of the process reading
> it.
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.
Reply to: