Root partition and usrland on one slice, /usr/local ports and srcon another

[Cy Schubert]

Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

---
Sent using a tiny phone keyboard. Apologies for any typos and autocorrect.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>

-----Original Message-----
From: Eugene Grosbein
Sent: 11/11/2017 12:37
To: ***@charter.net; 'freebsd-***@freebsd.org'
Subject: Re: Root partition and usrland on one slice, /usr/local ports and srcon another

It's been quite a while since I've tried a rebuild, but I think the
problems appeared early when gcc and gas and dependencies were being
built. I tried just symlinks, then different settings of the build
variables, and (IIRC) enabling clang. Perhaps I could start fresh with
11.1, but then perhaps placing everything on one slice is the most
straightforward solution.

I still don't get what specific problems did you have
but I'm sure they were not due to symlinking as such links work just fine
for me with gcc, and with clang too.



_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"

[Jamie Landeg-Jones]

Post by Cy Schubert
Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

I encountered a problem a few years ago with ports, when WRKDIRPREFIX was set, and there was a symbolic link in the destination. It didn't happen for every port, but I tracked the culprit down to one of the /usr/ports/Mk scripts. It's at this point I switched to nullfs instead.

I can't remember any more details on it, and the problem may not even occur anymore

[Jamie Landeg-Jones]

Post by Cy Schubert
I still don't get what specific problems did you have
but I'm sure they were not due to symlinking as such links work just fine
for me with gcc, and with clang too.
Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

I just came across one with multimedia/ffmpeg4:

Debugging the install stage gives this, though the cpio error messages are sent to null by default:

| + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
| + /usr/bin/cpio -dumpl /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/Changelog
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/CREDITS
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/INSTALL.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/LICENSE.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/MAINTAINERS
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/README.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/RELEASE_NOTES
| 0 blocks
| + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES '(' -type d -exec /bin/sh -xc 'cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg && chmod 755 "$@"' . {} + -o -type f -exec /bin/sh -xc 'cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg && chmod 0644 "$@"' . {} + ')'
| + cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
| + chmod 0644 Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
| chmod: Changelog: No such file or directory
| chmod: CREDITS: No such file or directory
| chmod: INSTALL.md: No such file or directory
| chmod: LICENSE.md: No such file or directory
| chmod: MAINTAINERS: No such file or directory
| chmod: README.md: No such file or directory
| chmod: RELEASE_NOTES: No such file or directory

cheers, Jamie

[Eugene Grosbein]

Post by Jamie Landeg-Jones

Post by Cy Schubert
I still don't get what specific problems did you have
but I'm sure they were not due to symlinking as such links work just fine
for me with gcc, and with clang too.
Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

| + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
| + /usr/bin/cpio -dumpl /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/Changelog

Well, I known this. Some time ago our cpio got "broken" in a way:
it now demands "--insecure" option to work with symlinks same way it worked long before without this option.

While I may understand motivation, this change still broke previously working scripts
like /usr/src/tools/tools/nanobsd/nanobsd.sh (generates NanoBSD images)
using cpio without "--insecure" when some parts of the building system are symlinked to other locations.