/usr/lib64/portage/pym/portage/dbapi/vartree.py incorrectly tells me that my ch-root filesystem is readonly when it isn't. On my gentoo build machine the real root is mounted read-only but this is only used for the OS and run's fedora. I have a few partitions that are writable and these are mounted somewhere. These are mounted read-write and portage (or ebuild) is run thereunder. When the final installation phase is about to begin the merge fails because this incorrectly detects the real-root being read only, as opposed to the ch-root which is the root, relatively speaking. Reproducible: Always Steps to Reproduce: 1. mount your root read only. 2. untar a stage3 onto a writeable partition 3. try emerging something.
This is because /proc/mounts contains both the real root mount information, as well as the chroot mount information. As a result, a forward search of /proc/mounts results in it picking the real root mount first, as /proc/mounts is in order of mount. One fix is to reverse the order of the /proc/mounts search, so that it usually finds the chroot mount first. This has its own edge cases, but will work better in most regular cases. I've suggested this to creffett on IRC already.
I've also run into this problem. I'd vote to push out the aforementioned fix even if it's just temporary. After upgrading portage in a chroot with a read-only host system, it's impossible to install anything else, including older versions of portage.
Hang on. I might have a simple edit to fix it for your chroots.
> Hang on. I might have a simple edit to fix it for your chroots. After the line 3842 rofilesystems = ro_checker(dirlist) in /usr/lib64/portage/pym/portage/dbapi/vartree.py you can just add 384X rofilesystems = False and problem gone. This isn't the point. I mean don't you get an error if the root file system is mounted read-only? And what is this abstraction with filesystems when all that you care about is if you can write files to somewhere? I mean one could even mount snapshots of say /usr /sbin and whatever on a tmpfs root via init and that check wouldn't really help either. And back in the olden days when hard disks were only 10Mb or so you would never have everything mounted on root. And what what about the case when the filesystem contains errors, is mounted with the option to go read only on error and the first write goes awry. What will the poor user do then? So really what is the point? I believe that failing to write something is more correct rather that some piecemeal hodge podge filesystem is writeable, everything is ok approach.
*** Bug 506446 has been marked as a duplicate of this bug. ***
Created attachment 374070 [details, diff] reverse search order mounts Can you test this patch to see if it works? I haven't a system that I can test this properly on at the moment.
Created attachment 374072 [details, diff] fixed reverse order patch
(In reply to Brian Dolbec from comment #7) list.reverse() reverses a list in place and returns None. Use __builtins__.reversed(). I recommend a more readable list comprehension instead of map().
OK, this is fixed in git commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ad1d3b4d4c8061285cc53b1b99105182a4acafec The "fixed reverse order patch" was also incorrect. Instead there was a different file that could be parsed which only contained the relavent mounts for the chroot.
+1 to dropping this logic and just relying on the result of open()/write()/etc. to determine success (and not caring if that results in a partial install). FYI, the reverse-order method won't work if the chroot isn't at the root of a filesystem since there won't be a second "/" entry to override the readonly root, e.g.: $ mount /dev/sdx99 /mnt $ mkdir /mnt/newroot $ cd /mnt/newroot $ tar xfp /tmp/newroot.tar.gz $ mount --rbind /proc ./proc # and /dev and whatever else $ chroot . /bin/bash $ emerge -e world # fails because it thinks / is mounted read-only
Never mind, I didn't notice that the commit used a different method. I withdraw my suggestion as I don't see a way that the committed version would break.
released in portage-2.2.11
