Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 505428 - sys-apps/portage-2.2.8-r1 incorrectly detects root mount read-only in chroot when it isn't
Summary: sys-apps/portage-2.2.8-r1 incorrectly detects root mount read-only in chroot ...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Keywords: InVCS
: 506446 (view as bug list)
Depends on:
Blocks: 378869 484436
  Show dependency tree
Reported: 2014-03-23 13:04 UTC by cjanderson
Modified: 2014-08-04 02:11 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

reverse search order mounts (,1.42 KB, patch)
2014-04-02 04:45 UTC, Brian Dolbec
Details | Diff
fixed reverse order patch (,1.72 KB, patch)
2014-04-02 07:45 UTC, Brian Dolbec
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description cjanderson 2014-03-23 13:04:18 UTC
/usr/lib64/portage/pym/portage/dbapi/ 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.
Comment 1 dwfreed 2014-03-26 20:40:43 UTC
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.
Comment 2 leonbaum2 2014-04-02 02:17:24 UTC
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.
Comment 3 Brian Dolbec gentoo-dev 2014-04-02 03:45:23 UTC
Hang on. I might have a simple edit to fix it for your chroots.
Comment 4 cjanderson 2014-04-02 04:21:37 UTC
> 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/ 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.
Comment 5 Brian Dolbec gentoo-dev 2014-04-02 04:38:09 UTC
*** Bug 506446 has been marked as a duplicate of this bug. ***
Comment 6 Brian Dolbec gentoo-dev 2014-04-02 04:45:59 UTC
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.
Comment 7 Brian Dolbec gentoo-dev 2014-04-02 07:45:39 UTC
Created attachment 374072 [details, diff]
fixed reverse order patch
Comment 8 Arfrever Frehtes Taifersar Arahesis 2014-04-03 10:28:19 UTC
(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().
Comment 9 Brian Dolbec gentoo-dev 2014-04-04 23:07:02 UTC
OK, this is fixed in git commit:;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.
Comment 10 Andrew Church 2014-05-18 14:13:18 UTC
+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
Comment 11 Andrew Church 2014-05-19 13:26:16 UTC
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.
Comment 12 Brian Dolbec gentoo-dev 2014-08-04 02:11:43 UTC
released in portage-2.2.11