Debian Bug report logs - #538348
pkgsel/tasksel: can no longer determine free space for desktop task

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Frans Pop <[email protected]>

To: Debian BTS Submit <[email protected]>

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

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.

Message #10 received at [email protected] (full text, mbox, reply):

From: Colin Watson <[email protected]>

To: Frans Pop <[email protected]>, [email protected]

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

Date: Sat, 25 Jul 2009 11:10:24 +0100

On Sat, Jul 25, 2009 at 03:21:00AM +0200, Frans Pop wrote:
> 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.

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 protected]]

Message #15 received at [email protected] (full text, mbox, reply):

From: Frans Pop <[email protected]>

To: [email protected]

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

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.
>
> 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 ...

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

Message #20 received at [email protected] (full text, mbox, reply):

From: Colin Watson <[email protected]>

To: Frans Pop <[email protected]>, [email protected]

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

Date: Sun, 26 Jul 2009 10:59:36 +0100

On Sat, Jul 25, 2009 at 02:55:57PM +0200, Frans Pop wrote:
> On Saturday 25 July 2009, Colin Watson wrote:
> > 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 ...
> 
> 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.

-- 
Colin Watson                                       [[email protected]]

Message #25 received at [email protected] (full text, mbox, reply):

From: Frans Pop <[email protected]>

To: [email protected]

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

Date: Sun, 26 Jul 2009 20:12:41 +0200

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.

Send a report that this bug log contains spam.