Feature changed by: Robert Davies (robopensuse) Feature #312718, revision 3 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) -- openSUSE Feature: https://features.opensuse.org/312718

Feature changed by: Jan Engelhardt (jengelh) Feature #312718, revision 5 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 + #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

Feature changed by: Robert Davies (robopensuse) Feature #312718, revision 7 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. + #5: Robert Davies (robopensuse) (2011-08-16 13:33:13) (reply to #3) + filesystem contains the mountpoint "/proc", and update fails similarly + if "/boot" is a read-only filesystem, because cpio is unpacking + archived directories rather than creating the structure if it doesn't + already exist. rpm/cpio must catch such an error, or it becomes + possible to have partial kernel updates where /lib & /boot become + inconsistent leading to boot difficulties. -- openSUSE Feature: https://features.opensuse.org/312718