Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 831075 - 'user' or 'group' missing during prefix bootstrap stage3
Summary: 'user' or 'group' missing during prefix bootstrap stage3
Status: UNCONFIRMED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: AMD64 OS X
: Normal normal with 1 vote (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-12 16:07 UTC by slondr
Modified: 2022-01-27 16:01 UTC (History)
2 users (show)

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


Attachments
full stage3 log, compressed using xz (stage3.log.tar.xz,977.56 KB, application/x-xz)
2022-01-12 16:12 UTC, slondr
Details
full stage3 log, compressed using xz (stage3.log.xz,976.92 KB, application/x-xz)
2022-01-12 16:15 UTC, slondr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description slondr 2022-01-12 16:07:40 UTC
I'm seeing several permissions-related errors during stage3 of bootstrap-prefix; they start with a message saying my user does not seem to exist.

Furthermore (and I'm not sure if this is related): I can't actually do the stages in sequence. Trying to run stage2 or stage3 gives me an error saying emerge was not found ("did you boogstrap stage1?"), even if I run it right after a successful stage1. It gets to stage3 if I run the script without an action, though...

Reproducible: Always

Steps to Reproduce:
1. ./bootstrap-prefix.sh
2. Accept all default prompts
3. Wait for error to appear.
Actual Results:  
multiple errors:
portage: 'elondres' user or 'ADDomain Users' group missing.
         In Prefix Portage this is quite dramatic
         since it means you have thrown away yourself.
         Re-add yourself or re-bootstrap Gentoo Prefix.
*** WARNING ***  For security reasons, only system administrators should be
*** WARNING ***  allowed in the portage group.  Untrusted users or processes
*** WARNING ***  can potentially exploit the portage group for attacks such as
*** WARNING ***  local privilege escalation.

!!! Directory initialization failed: '/Users/elondres/Gentoo/var/lib/portage'
!!! chown('/Users/elondres/Gentoo/var/lib/portage', -1, 0)
!!! Directory initialization failed: '/Users/elondres/Gentoo/var/cache/edb'
!!! chown('/Users/elondres/Gentoo/var/cache/edb', -1, 0)
[Errno 1] Operation not permitted: b'/Users/elondres/Gentoo/var/lib/gentoo/news/.news-gentoo_prefix.unread.portage_lockfile': chown('/Users/elondres/Gentoo/var/lib/gentoo/news/.news-gentoo_prefix.unread.portage_lockfile', -1, 0)
Cannot chown a lockfile: '/Users/elondres/Gentoo/var/lib/gentoo/news/.news-gentoo_prefix.unread.portage_lockfile'

then later on:


Traceback (most recent call last):
  File "/Users/elondres/Gentoo/usr/lib/python3.9/site-packages/portage/util/__init__.py", line 1072, in apply_permissions
    os.chown(filename, uid, gid)
  File "/Users/elondres/Gentoo/usr/lib/python3.9/site-packages/portage/__init__.py", line 244, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
PermissionError: [Errno 1] Operation not permitted: b'/Users/elondres/Gentoo/var/lib/portage'

Expected Results:  
Successful prefix bootstrapping

CHOST=x86_64-apple-darwin-20

logs attached

I don't think this is the same as #822936; I'm seeing the same error messages as them, but in that bug the cause was domain information appended to USER, which is not the case on my system. Also, they reported seeing their user present in $EPREFIX/etc/passwd; on my system, $EPREFIX/etc/passwd does not exist.
Comment 1 slondr 2022-01-12 16:12:10 UTC
Created attachment 761976 [details]
full stage3 log, compressed using xz
Comment 2 slondr 2022-01-12 16:15:11 UTC
Created attachment 761977 [details]
full stage3 log, compressed using xz
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-01-13 04:25:58 UTC
(Note that running stages manully tends to be a bit fragile (it's usually best to just run the script and it'll pick up at the right point by itself).)

I've never seen this kind of issue on macOS before. Is your Mac part of AD/somehow managed with corporate authentication/LDAP/???

I know somebody bootstrapped successfully on macOS 11 or macOS 12 within the last few days, so I don't think it's general breakage (not that this helps you, just an interesting observation).
Comment 4 slondr 2022-01-13 11:34:13 UTC
> Is your Mac part of AD/somehow managed with corporate authentication/LDAP/???

Yes. Could that be causing this issue?

> (Note that running stages manully tends to be a bit fragile (it's usually best to just run the script and it'll pick up at the right point by itself).)

Ah, that’s reassuring. I was worried I had broken something else to cause that.