Mailinglist Archive: opensuse-features (112 mails)

[fate_noreply@xxxxxxx]

Feature changed by: Robert Davies (robopensuse)
Feature #312718, revision 6
  Title: Package Installations should be chroot aware!
   
  openSUSE Distribution: Unconfirmed
  Priority
      Requester: Mandatory
   
  Requested by: Ralph Ulrich (ulenrich)
  Partner organization: openSUSE.org
   
Description:
  Debian does this already! Prove if package installation or upgrade is
  done in a chroot. Rationale: Every time I refresh my openSUSE-
  Tumbleweed installation from a chroot I get this error:
  Installing: filesystem-12.1-26.1 [error] Installation of filesystem-
  12.1-26.1 failed: (with --nodeps --force) Error: Subprocess failed.
  Error: RPM failed: error: unpacking of archive failed on file /proc:
  cpio: chown failed - Read-only file system
  Of cause I bind mount /proc read only! In a chroot doing a mount of
  /proc is recommended for many purposes. For example an installation
  attempt of gentoo stage will fail without /proc mounted. As this /proc
  mounting is a standard procedure I prioritize this feature as mandatory
  ...
   
   
  Discussion:
  #1: Robert Davies (robopensuse) (2011-08-09 07:45:18) 
  Could you clarify? Is the idea of this request to ensure zypper update
  or a package install works, when a test Tumbleweed/Factory openSUSE
  installation is "started" within a chrooted shell of a different
  install booted in normal way for daily work? So this feature would make
  maintenance of multiple openSUSE version easier, by reducing need to
  reboot into them.
  BTW /proc shows mounted "proc on /proc type proc (rw,relatime)"
  I see many tmpfs's mounted as well as /proc : devtmpfs on /dev type
  devtmpfs (rw,relatime,size=1987596k,nr_inodes=496899,mode=755) tmpfs on
  /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,
  nodev,relatime,mode=755) tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,
  relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,
  relatime,mode=755)
   
  #2: Ralph Ulrich (ulenrich) (2011-08-10 13:43:18) 
  @Robert, yes. But it is also required to do zypper works in a chrooted
  envirenment, when you have damaged your installation. Debian has a
  function like this to stop some further work when in a chroot:
  chrooted(){ if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root
  2>/dev/null)" ]; then # root, so we're *not* in a chroot return 1 fi
  echo "chroot environment " return 0 }
  So installation of udev package is able to continue when for example:
  chrooted || udevadm control --log-priority=0
   
   
+ #4: Robert Davies (robopensuse) (2011-08-16 12:51:36) (reply to #2)
+ Well damaged packages in an installation can be repaired from Live CD,
+ using rpm with the "--root DIRECTORY" option, so I did not think it was
+ the best use case.
   
  #3: Jan Engelhardt (jengelh) (2011-08-12 02:27:10) 
  The issue here seems to be not that zypper can't handle chroots (why
  would it care, it's just another directory), but that librpm cannot
  deal with updating the attributes of a directory-type inode that has
  been hidden by a new directory-type inode of another vfsmount.
   
   
   

-- 
openSUSE Feature: 
https://features.opensuse.org/312718