Home_greyopenFATE - openSUSE feature tracking > #312718
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Package Installations should be chroot aware!

Feature state

openSUSE Distribution
Unconfirmed

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


icons/user_comment.png R. D. wrote: (5 years ago)

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)

icons/user_comment.png R. U. wrote: (5 years ago)

@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

icons/user_comment.png R. D. wrote: (5 years ago)

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.

icons/user_comment.png J. E. wrote: (5 years ago)

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.

icons/user_comment.png R. D. wrote: (5 years ago)

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.

Last change: 5 years ago
Voting
Score: 3
  • Negative: 1
  • Neutral: 1
  • Positive: 4
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint