The previous version implies that statically linked Linux binaries work after enabling linux in rc.conf. This version says that it is possible to run such binaries outright without any preparations. Not sure if this is true.
The Linux rc service/rc script, maybe?
IIRC, service linux start loads these modules automatically.
I doubt this is ever will be needed for some user.
My take on this. Thanks for the work!
I don't have an example now, but having a look at the code I think in general statically linked Linux binaries won't work.
The original doc has that text but after starting the linux service.
I don't know if phabricator is doing something funky here, but it looks like too many spaces in To enable
If all wanted --> If all that is wanted
also pkg --> pkg(8)
To install CentOS userland --> To install the CentOS userland
from CentOS 7 at --> from CentOS 7 into
Avoid "verify" repetition. Replace second one ... to verify... --> ... to check...
...due to possible clash... --> ...due to possible clashes...
Yes, the linux rc script already does this:
# Explicitly load the filesystem modules; they are usually required, # even with linux_mounts_enable="NO". load_kld fdescfs load_kld linprocfs load_kld linsysfs
Shouldn't be necessary. linux_enable="YES" will take care of that.
To access to the system... --> To access the system...
I would rephrase this. Here is an attempt:
Once inside the chroot, the system behaves as in a normal Ubuntu installation.
"But" normally connects two sentences:
...by the [.filename]#/etc/rc.d/linux# script.
I would remove this last section completely and link to the article on Linux emulation.
This line sounds awkward to me; directories have no desires, and I wouldn't say that nullfs should be mounted, but rather home and tmp. Perhaps something like this.
I thought some of these were handled by the linux script?
I don't understand what this sentence means, in either new or old versions. But it should probably still say "on 64-bit hosts" or "on 64-bit amd64 and arm64 hosts".
Not necessary /compat/linux, other examples are used above.
I'm not sure this is correct in all cases. The FreeBSD csh looks for an initial '#", and if not found, invokes /bin/sh. Maybe this is an uncommon case. Also, if the first two bytes are "#!", the rest of the line is used to identify the interpreter and arguments, and that is implemented by execve.
can you please provide a new paragraph?
hahaha, good point, but remember, Skynet will come :)
No, in this case no, the linux script mount the files in "/compat/linux"
Sorry, don't get the point :)
@fernape can you please help me here too hehe
I prefer to keep the path, because can be "/compat/ubuntu" or "/compat/debian"
Just moving the sentence This is enough for statically linked Linux binaries to work. after the part where we say //Once enabled, it can be started without rebooting executing the following command://.
So activating the Linux emulation service is enough to run most statically linked Linux binaries.
Wrong character 'º'
The sentences still reads weird to me, but I'm not an English native speaker.
Sorry I didn't explain better. I think we should join the two sentences using but like this:
This is normally handled by the [.filename]#/etc/rc.d/linux# script but can be disabled at boot executing the following command:
32-bit kernels can only execute 32-bit executables. 64-bit kernels can execute 32- and 64-bit executables. However, what can't be done is to statically link "different bit sized" parts into one single kernel. The kernel (or any other executable for that matter) is either 64 or 32-bit.
To my taste, this sentence has too many "install" words. How about
If all that is wanted is to run some software already included in the Ports tree, it can be installed via package manager and man:pkg will automatically setup the required Linux userland.
I also suggest to remove the "like Sublime Text 4" part since you're talking about it in the next sentence.
This part: They can be started in the same way native FreeBSD binaries can; they behave almost exactly like native processes and can be traced and debugged the usual way.
I would use the proposed one Once inside the chroot, the system behaves as in a normal Ubuntu installation.. I think it conveys the idea and is somehow clearer.
On re-reading this chapter, I think I understand the usage of /compat/linux, /compat/ubuntu, etc. But I don't think that it's very clear how they interact. It may be worth a paragraph near the beginning to say /compat/linux is meant for Centos, /compat/ubuntu for Debian/Ubuntu, etc. They are treated differently, in that the rc script does things automagically for /compat/linux.
No, the existing file and man page is /etc/hosts, the sentence refers to /etc/host.conf. If the sentence means to refer to compatibility of /etc/hosts, it is not well formed.
No, /etc/hosts is a host address database, not a config file. Linux (at least Ubuntu) has both /etc/hosts and /etc/host.conf. /etc/hosts appears to have a compatible format.
Yes, they are different things. What I wanted to say is that there is no /etc/host.conf in FreeBSD, the closest is /etc/hosts which, as you pointed out, has a different goal.
The thing with the Linuxolator, if I'm reading the code properly is that Linux binaries prefer files under /compat/linux and if they are not found, they are looked for in the normal namespace starting at /. This is done in the kern_alternate_path function.
I think the original paragraph is misleading. I think it is meant to say:
When [.filename]#/compat/linux/etc/host.conf# does not exist, Linux applications use [.filename]#/etc/host.conf# in the host system but they complain since that file does not exist in FreeBSD.