Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task
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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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. f...@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 f...@aragorn:~$ sudo chroot /srv/chroots/amd64-sid (amd64-sid)r...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task
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 [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task
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? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538348: pkgsel/tasksel: can no longer determine free space for desktop task
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.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
