Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 751421 - bootstrap-prefix.sh: ln: failed to create symbolic link '${ROOT}/tmp//var/db/repos/gentoo': No such file or directory
Summary: bootstrap-prefix.sh: ln: failed to create symbolic link '${ROOT}/tmp//var/db/...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: AMD64 OS X
: Low minor
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2020-10-27 04:53 UTC by Alexander Bezrukov
Modified: 2020-10-28 07:13 UTC (History)
1 user (show)

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


Attachments
Fix for tmp portage tree linking (tmp-portage-tree-link.patch,825 bytes, patch)
2020-10-27 04:53 UTC, Alexander Bezrukov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bezrukov 2020-10-27 04:53:50 UTC
Created attachment 668768 [details, diff]
Fix for tmp portage tree linking

I am trying to bootstrap prefix on MacOS 10.14 and 10.15. The script produces a bunch of errors and I am trying to fix these errors one by one. This bug report deals with the error in the summary. The previous bug reports in the series are these: bug 751037, bug 751067, bug 751406, bug 751412.

The error is produced by the function bootstrap_portage(). The failing code tries to symlink portage tree from its default location (var/db/repos/gentoo) to its tmp "mirror" (all paths are relative to the prefix $ROOT). The problem is that the $PORTDIR is a deep hierarchical path and thus the link destination directory does not exist.

I am attaching the patch which fixes this issue by first creating the directory with the path of tmp portage tree, then rmdir'ing it (thus preserving the rest of hierarchy) and only then symlinking. While there, also removed a redundant slash from tmpportdir variable. I do not know whether this link is actually necessary for bootstrap, maybe simply removing the offending command is a better solution.

After fixing this issue (and all the previously reported in this series), stage1 bootstrap passes cleanly in my setup and stage 2 begins to compile (previously this was not the case).
Comment 1 Fabian Groffen gentoo-dev 2020-10-27 07:27:52 UTC
I'm not saying this is wrong or anything, but what bothers me is that this particular bit of code hasn't changed for years, and it certainly did work in the past, so I really wonder why it suddenly stopped working.  New versions of portage are rolled out sparingly, and always tested...
Comment 2 Larry the Git Cow gentoo-dev 2020-10-27 07:44:40 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=6c17f821de91c518556ea345a1a88abbe8706bc3

commit 6c17f821de91c518556ea345a1a88abbe8706bc3
Author:     Fabian Groffen <grobian@gentoo.org>
AuthorDate: 2020-10-27 07:42:40 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-10-27 07:42:40 +0000

    scripts/bootstrap-prefix: pre-create portroot
    
    For some reason linking the portage tree in the tmp image fails, so
    ensure whilst setting up all other dirs in /tmp that also the portroot
    is created.
    
    Bug: https://bugs.gentoo.org/751421
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 scripts/bootstrap-prefix.sh | 2 ++
 1 file changed, 2 insertions(+)
Comment 3 Fabian Groffen gentoo-dev 2020-10-27 07:45:02 UTC
I'm curious if this helps
Comment 4 Alexander Bezrukov 2020-10-27 13:53:34 UTC
(In reply to Fabian Groffen from comment #1)
> I'm not saying this is wrong or anything, but what bothers me is that this
> particular bit of code hasn't changed for years, and it certainly did work
> in the past, so I really wonder why it suddenly stopped working.

I guess this has happened because the default location of portage tree directory (${PORTDIR}) changed from usr/portage to var/db/cache/repos/, that is depth of this path increased. Update of portage per se does not change the location, clean install does.
Comment 5 Fabian Groffen gentoo-dev 2020-10-27 13:57:00 UTC
yes, that would be the first thing, but there have been successful bootstraps since that change

Ok, seems that e.g. https://bootstrap.prefix.bitzolder.nl/results/x86_64-pc-solaris2.11/20200607 shows this in stage1.log:

ln: failed to create symbolic link '/gentoo/bootstrap64-20200607/tmp//var/db/repos/gentoo': No such file or directory

So the thing failed, but it never bothered anything for some reason.
Comment 6 Alexander Bezrukov 2020-10-27 15:15:57 UTC
(In reply to Fabian Groffen from comment #5)

> So the thing failed, but it never bothered anything for some reason.

That's why I wrote that

> I do not know whether this link is actually necessary for bootstrap,
> maybe simply removing the offending command is a better solution.

I could not spot where this link is used further in the bootstrapping. But I have had no previous experience with gentoo prefix so I consider myself an ignorant dummy at the moment.
Comment 7 Fabian Groffen gentoo-dev 2020-10-28 07:13:05 UTC
Ok, let's close it then, thanks :)