Get of rid of the VirtualPrefix

[bugaevc]

This is my work on building the new layout of the "Darling container" (see #197).

• Deprecate the old 'darling' script and always build the new executable.
  • One notable maybe-missing thing is OpenSSL certificates -- please look into this.
• Get rid of Darling's chroot-emulation-in-syscall-emulation (known as VirtualPrefix). Instead, we mount $DPREFIX directly onto / inside the container.
  • Mount a new procfs (for our PID namespace) onto /proc inside.
  • This means that native executables (accessible through /Volumes/SystemRoot/...) see the new layout, too. You can use e.g. /Volumes/SystemRoot/bin/ps.
  • The complicated part here is loading shared libraries.
    • Set up /etc/ld.so.conf.d and run ldconfig at installation time.
    • Pass LD_LIBRARY_PATH for /usr/local/lib/darling.
      • This is because I couldn't get it to work with /etc/ld.so.conf.d/darling.conf; this won't be hopefully needed after the Great Mach-O Bringup (see Using Mach-O's for Darling itself #221).
    • Symlink /lib -> /Volumes/SystemRoot/lib and lib64 -> /Volumes/SystemRoot/lib64.
      • This is because most ELFs have /lib64/ld-linux-x86-64.so.2 (or 32bit version) hard-coded as their interpreter.
• Create most of the prefix filesystem layout inside /usr/local/libexec/darling at installation time.
• On /Volumes (see New /Volumes design #220):
  • Move /system-root to /Volumes/SystemRoot.
  • Turn off user namespaces for now -- they were not really useful anyway.
  • hdiutil works if launched like DPREFIX=/ PATH=/Volumes/SystemRoot/bin /usr/bin/hdiutil. It should be fairly easy to make it support the new layout.
• Misc changes that are better described by their commit messages and diffs.

Please do review and test!

[LubosD]

There is one little problem (but it can be solved after I review the changes and merge the code) - in some cases, a little bit of VirtualPrefix code (or simply new code) are still needed:

HFS+ is case insensitive and apps depend on this. I've seen software explicitly checking whether the filesystem where it's installed is case sensitive (usually HFSX on macOS) and then refusing to run.

So we will need to have a special resolution algorithm, which on the other hand only needs to be triggered in case the given system call returns -LINUX_ENOENT.

[bugaevc]

@LubosD good catch!

OTOH, I've heard that iOS version of HFS+ is case-sensitive, and so is APFS, so this may be less relevant in the future.

[LubosD]

One more question before I merge (and I may be a little confused, possibly): where do we chroot?

[bugaevc]

One more question before I merge (and I may be a little confused, possibly): where do we chroot?

We don't actually use chroot(), instead, we pivot_root right after mounting overlayfs onto the prefix.

[LubosD]

Clever! Never actually though about using this outside of initrd.