FS#57251 - [arch-install-scripts] 18-1 breaks arch-chroot
Attached to Project:
Arch Linux
Opened by Philip Soeberg (philip007) - Saturday, 27 January 2018, 20:30 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:22 GMT
Opened by Philip Soeberg (philip007) - Saturday, 27 January 2018, 20:30 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:22 GMT
|
Details
Description:
git commit 232784ec5607383feb805c60d628e7fdda9c2b0e destroys my "arch-chroot" as it does not mount / in the chroot environment. arch-install-scripts V17 works fine arch-install-scripts V18 is broken I am running Linux kodi-server 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64 GNU/Linux It is very vanilla Arch with very little customization. A pacstrabbed arch exists in /srv/kodi subfolder. It has been like this for years. Observed trouble: $arch-chroot /srv/kodi pacman -S arch-install-scripts ... error: could not determine cachedir mount point /var/cache/pacman/pkg Debugging arch-chroot: Running V17 $arch-chroot /srv mount /dev/vda1 on / type ext4 (rw,noatime,nodiratime,block_validity,delalloc,barrier,user_xattr,acl) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sys on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=500852k,nr_inodes=125213,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime) run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmp on /tmp type tmpfs (rw,nosuid,nodev) /dev/vda1 on /etc/resolv.conf type ext4 (rw,noatime,nodiratime,block_validity,delalloc,barrier,user_xattr,acl) Running V18: $arch-chroot /srv mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sys on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=500852k,nr_inodes=125213,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime) run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmp on /tmp type tmpfs (rw,nosuid,nodev) /dev/vda1 on /etc/resolv.conf type ext4 (rw,noatime,nodiratime,block_validity,delalloc,barrier,user_xattr,acl) As can be seen, / is mounted in V17 but not in V18. Patching V18 with "chroot_maybe_add_mount "! mountpoint -q '$1'" "$1" "$1" --bind &&" at line 86 solves all problems. Is it reproducible? Always. Just run arch-chroot to a pacstrabbed directory, and / is missing from mtab. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 05 January 2019, 16:22 GMT
Reason for closing: Fixed
Additional comments about closing: arch-install-scripts-20
Saturday, 05 January 2019, 16:22 GMT
Reason for closing: Fixed
Additional comments about closing: arch-install-scripts-20
Edit: Dave, see https://bugs.archlinux.org/task/46169#comment138601
I did wonder why / was a part of the V17 arch-chroot, but as pacman and arch-chroot both are part of Arch, I thought that other tools may also need / inside a arch-chroot environment and opted for creating a bugreport.
I don't think it will be easy for users to do arch-chroot and pacman in the future with the current state of Pacman having CheckSpace default on and arch-chroot not having /, so perhaps Pacman should be feature enhanced to detect chroot environments and not do CheckSpace option by default if arch-chroot continue to not mount /.
What do you recommend?
I no longer believe this ticket is valid as arch-chroot is not broken. Please close it. Pacman 5.0.2-2 has a dependency towards how arch-chroot worked, this dependency is now broken and end-user requires to change pacman.conf and outcomment "CheckSpace" to get pacman working inside a arch-chroot environment.
Thank you for pointing me in the right direction. I would have taken me awhile to locate CheckSpace.
Within a chroot on a non-mountpoint directory prepared by arch-chroot, blockdevice mounts are not visible in /proc/mounts.
You can easily reproduce this using a current archlinux-bootstrap image:
root@otherlinux ~ # curl -o - https://mirror.ubrco.de/archlinux/iso/latest/archlinux-bootstrap-2018.10.01-x86_64.tar.gz | tar xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 140M 100 140M 0 0 50.9M 0 0:00:02 0:00:02 --:--:-- 50.9M
root@otherlinux ~ # ~/root.x86_64/usr/bin/arch-chroot ~/root.x86_64/
[root@otherlinux /]# pacman -S archlinux-keyring
resolving dependencies...
looking for conflicting packages...
Packages (1) archlinux-keyring-20181003-1
Total Download Size: 0.61 MiB
Total Installed Size: 0.86 MiB
Net Upgrade Size: 0.04 MiB
:: Proceed with installation? [Y/n] y
error: could not determine cachedir mount point /var/cache/pacman/pkg
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
pacman is complaining because it is not able to resolve mount points as there is no / mount:
[root@otherlinux /]# cat /proc/mounts
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=8155460k,nr_inodes=2038865,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmp /tmp tmpfs rw,nosuid,nodev 0 0
overlay /etc/resolv.conf overlay rw,relatime,lowerdir=/nfsroot,upperdir=/ramfs/root,workdir=/ramfs/work 0 0
By manually bind mounting the directory on itself blockdevice mountpoints become visible again:
root@otherlinux ~ # mount ~/root.x86_64/ ~/root.x86_64/ --bind
root@otherlinux ~ # ~/root.x86_64/usr/bin/arch-chroot ~/root.x86_64/
[root@otherlinux /]# cat /proc/mounts
/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=8155460k,nr_inodes=2038865,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmp /tmp tmpfs rw,nosuid,nodev 0 0
overlay /etc/resolv.conf overlay rw,relatime,lowerdir=/nfsroot,upperdir=/ramfs/root,workdir=/ramfs/work 0 0
[root@otherlinux /]# pacman -S archlinux-keyring
resolving dependencies...
looking for conflicting packages...
Packages (1) archlinux-keyring-20181003-1
Total Download Size: 0.61 MiB
Total Installed Size: 0.86 MiB
Net Upgrade Size: 0.04 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
Readding the bind mount would resolve the problem again. Is there a specific reason that the bind mount got removed?
Yes, that's already been highlighted in the original bug report.
The other reason (other than what's already documented in the git commit) this was reverted is because creating a bind mount out of the user's control means that you can no longer has submounts within the chroot -- they'll be hidden away when the root is mounted on itself.
There's no functional change that needs to occur here. Perhaps some sort of warning can be logged when one uses arch-chroot on a directory that isn't a mountpoint.