[pkg-fso-maint] /proc required in chroots

Luca Capello luca at pca.it
Fri Mar 20 11:13:20 UTC 2009


Hi Steffen!

On Fri, 20 Mar 2009 08:17:21 +0100, Steffen Moeller wrote:
> Luca Capello wrote:
>> On Thu, 19 Mar 2009 17:32:34 +0100, Steffen Moeller wrote:
>>> The following commit has been merged in the master branch:
>>> commit 50c870bd1e33805ce150177e3256c7c4d65f5b88
>>> Author: Steffen Moeller <moeller at debian.org>
>>> Date:   Wed Mar 18 13:36:13 2009 +0100
>>>
>>>     Added APT_OPTIONS to install of wicd
>>>     
>>>     Responing "n" to the question if wicd should be installed
>>>     will stop the installation process.
>> [...]
>>> diff --git a/install.sh b/install.sh
>>> index a013290..3129466 100755
>>> --- a/install.sh
>>> +++ b/install.sh
>>> @@ -119,6 +119,30 @@ TAR_PACKAGE=$INST_MIRROR/pool/main/t/tar/tar_1.20-1_armel.deb
>>>  # FUNCTIONS
>>>  #
>>>  
>>> +# for the installation of packages, /proc is sometimes required to be
>>> +# installed. cdebootstrap is installing it itself.
>> 
>> Again, please perform two commits in such a case:
>
> I did. I only did not push twice. I'll do some more "man git".

I think there is a misunderstanding on the terminology here:

  `git commit` -> recording your changes

  `git push` -> sending your commits to another repository

If you push twice and with the first push you have already sent every
(new) commit, then the second push does not add anything more.

What you need is two different commits, with `git add -i $FILE` as
Philipp suggested in another mail or working on single issues (as I
do).  I agree this is boring...

>> Going back to the subject of this mail: why /proc must be mounted at
>> all? 
>
> I spotted a few apt-get installs to have failed because of a missing
> /proc. So I felt, that since cdebootstrap also mounts it, that it
> would be the right thing to do.

As Philipp said in another post, I have also seen apt-get/dpkg emitting
"strange warnings about not being able to log when /proc is not
mounted", but AFAIK I have never seen them failing.

>> I cannot see how this affect installation of wicd:
>
> I did not care if some subtask would be affected or not, I just wanted
> to be sure that (except for the task debian that runs cdebootstrap,
> which in turn will fail if /proc is attempted to be mounted a second
> time) we have /proc available when apt-get is executed, since a few
> packages are expecting that. If that is a bug of those packages, then
> I am happily submitting bug reports to those packages, instead.

This is what I should have written, thank you for having spotted it.

> There is a danger that the installation kills processes that run on
> the host, presuming they were of their own. But this would be but of
> that respective post-inst script and we should fix that, right? Are
> there other reasons why /proc should not be available?

I think the question is the other way around: why should /proc be
available at *installation* time?

> Ah, I just found your question about failing packages below ... I'll
> produce a list. There are plenty of checks for /proc in *.postinst,
> that is for sure, which can be observed by
> 	$ grep "/proc/" /var/lib/dpkg/info/*.postinst
> but admittedly I need to find those that fail, still.

On my Debian sid, which I must admit is a very minimal one ATM (no X.Org
yet), so it is not a good example:
=====
luca at gismo:~$ grep -l "/proc" /var/lib/dpkg/info/*.postinst
/var/lib/dpkg/info/acpid.postinst
/var/lib/dpkg/info/ifupdown.postinst
/var/lib/dpkg/info/initscripts.postinst
/var/lib/dpkg/info/libc6.postinst
/var/lib/dpkg/info/libselinux1.postinst
/var/lib/dpkg/info/libsepol1.postinst
/var/lib/dpkg/info/module-init-tools.postinst
/var/lib/dpkg/info/postfix.postinst
/var/lib/dpkg/info/procps.postinst
/var/lib/dpkg/info/resolvconf.postinst
/var/lib/dpkg/info/udev.postinst
luca at gismo:~$
=====

I quickly looked at the udev case, which check if it is in a chroot and
in that case it does not need /proc.

On my FR, a default installation with minimal add-ons (mostly for WiFi):
=====
debian-gta02:~# grep -l "/proc" /var/lib/dpkg/info/*.postinst
/var/lib/dpkg/info/ifupdown.postinst
/var/lib/dpkg/info/initscripts.postinst
/var/lib/dpkg/info/libc6.postinst
/var/lib/dpkg/info/libselinux1.postinst
/var/lib/dpkg/info/libsepol1.postinst
/var/lib/dpkg/info/module-init-tools.postinst
/var/lib/dpkg/info/procps.postinst
/var/lib/dpkg/info/udev.postinst
/var/lib/dpkg/info/xserver-xorg.postinst
debian-gta02:~#
======

Looking in details at xserver-xorg:


1) line 1526

--8<---------------cut here---------------start------------->8---
  # SGI Indigo2 XLs require a special hack, per Guido Guenther (see Debian
  # #249614).
  if [ -e /proc/cpuinfo ]; then
    if grep -q "system type.*:.*SGI Indigo2" /proc/cpuinfo; then
--8<---------------cut here---------------end--------------->8---

   Is there any other way to check the CPU type than /proc?


2) line 1559

--8<---------------cut here---------------start------------->8---
  if [ -e /proc/fb ]; then
    FB_TYPE="$(grep '^0 ' /proc/fb | sed 's/[^[:space:]] //')"
    # did we actually get back anything?
    if [ -n "$FB_TYPE" ]; then
--8<---------------cut here---------------end--------------->8---

   As I reported at bug #459457 [1], the fact that /proc/fb exists does
   not mean that a fb is available, and indeed this is why there is the
   second test.

[1] http://bugs.debian.org/459457

   If we directly test for /dev/fb0, well, this means that we need /dev
   mounted in a chroot (which IMHO is not a win WRT /proc).  I am wonder
   if there is no other way to be sure a fb is present.  However,
   strictly speaking this is a configuration problem, not an
   installation one.


3) line 1749

--8<---------------cut here---------------start------------->8---
    if [ "$ARCH" = "powerpc" ] && \
        [ -e /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes ] && \
        [ "$(cat /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes)" = "0" ]; then
      XKBMODEL=macintosh_old
--8<---------------cut here---------------end--------------->8---

   Again, a configuration problem.


Given the above, I would say that requiring /proc at installation time
could be, in most of the cases, a bug in the package.  Obviously, I am
far from being an expert on this matter, that is why I asked for more
discussion before applying any patch.

Thx, bye,
Gismo / Luca

PS, it is clear that I always try to require the strictly minimum
environment for everything :-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20090320/dd706b82/attachment.pgp 


More information about the pkg-fso-maint mailing list