[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: