# Building a 10.2 system from source



## hanzer (Aug 31, 2015)

Hi, I'm preparing to build a 10.2 system from source but I'm not sure about the difference between these versions:

http://svnweb.freebsd.org/base/release/10.2.0/

http://svnweb.freebsd.org/base/releng/10.2/

http://svnweb.freebsd.org/base/stable/10/
And the ports versions:

http://svn0.us-east.freebsd.org/ports/tags/RELEASE_10_2_0/
http://svn0.us-east.freebsd.org/ports/branches/2015Q3/
http://svn0.us-east.freebsd.org/ports/head/
My goal is to have a coherent, stable base system that is roughly equivalent to the 10.2 release with patches. The ideal ports system would be a well tested recent version.

Any suggestions?


----------



## tobik@ (Sep 1, 2015)

hanzer said:


> http://svnweb.freebsd.org/base/release/10.2.0/


This is 10.2-RELEASE without patches. Do not use. AFAIK checking this out gets you the same sources as the src.txz tarballs on the FTP servers.



hanzer said:


> http://svnweb.freebsd.org/base/releng/10.2/


This is the one you want. Security patches are applied here.


hanzer said:


> http://svnweb.freebsd.org/base/stable/10/


This will become 10.3-RELEASE eventually.

These articles talk about how FreeBSD releases are created and what all these branches mean: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/ and https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html



hanzer said:


> http://svn0.us-east.freebsd.org/ports/branches/2015Q3/


The current quarterly branch of the ports tree. More stable than head. This is probably what you want. 10.2-RELEASE's binary packages updates are build from the latest quarterly branch.


----------



## hanzer (Sep 1, 2015)

tobik said:


> This is the one you want. Security patches are applied here.
> 
> These articles talk about how FreeBSD releases are created and what all these branches mean: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/ and https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html
> 
> The current quarterly branch of the ports tree. More stable than head. This is probably what you want. 10.2-RELEASE's binary packages updates are build from the latest quarterly branch.



Awesome, and thanks for the doc links! Moving forward with /base/releng/10.2/ and /ports/branches/2015Q3/


----------



## hanzer (Sep 1, 2015)

`svn checkout svn+ssh://repo.freebsd.org/base/releng/10.2 /usr/src`

```
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://repo.freebsd.org/base/releng/10.2'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly
```
`svn checkout http://svn0.us-east.freebsd.org/base/releng/10.2 /usr/src`

```
svn: E175002: Unable to connect to a repository at URL 'http://svn0.us-east.freebsd.org/base/releng/10.2'
svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/base/releng/10.2'
```
`svn checkout https://svn0.us-east.freebsd.org/base/releng/10.2 /usr/src`

```
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
 - The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svnmir.ysv.FreeBSD.org
 - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
 - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
 - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently? p
svn: E000054: Unable to connect to a repository at URL 'https://svn0.us-east.freebsd.org/base/releng/10.2'
svn: E000054: Error running context: Connection reset by peer
```
`svn checkout https://svn0.us-west.freebsd.org/base/releng/10.2 /usr/src`

```
Error validating server certificate for 'https://svn0.us-west.freebsd.org:443':
 - The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svnmir.ysv.FreeBSD.org
 - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
 - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
 - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently? p
```
*Success!* (but WTF?)


----------



## junovitch@ (Sep 1, 2015)

Please use "svn.FreeBSD.org".  The other mirrors use self signed certificates which is why those errors came up.  The SSH access at "repo.FreeBSD.org" host is only for committers.


----------



## tobik@ (Sep 1, 2015)

Use
`svn checkout https://svn.FreeBSD.org/base/releng/10.2 /usr/src`
and
`svn checkout https://svn.FreeBSD.org/ports/branches/2015Q3 /usr/ports`

svn.FreeBSD.org will automatically choose a mirror near you.


----------



## hanzer (Sep 1, 2015)

junovitch@ said:


> Please use "svn.FreeBSD.org".  The other mirrors use self signed certificates which is why those errors came up.  The SSH access at "repo.FreeBSD.org" host is only for committers.





tobik said:


> Use
> `svn checkout https://svn.freebsd.org/base/releng/10.2 /usr/src`
> and
> `svn checkout https://svn.freebsd.org/ports/branches/2015Q3 /usr/ports`
> ...



Nice, thanks. The Subversion Primer is a little misleading but the canonical(?) method *is* buried in the Using Subversion document. It's sometimes a bit difficult to sort out [within the docs] what is a working example (and/or recommended best practice), e.g.,
`# svn checkout [I][URL]https://svn.FreeBSD.org[/URL][/I]/ports/head /usr/ports`

and what is an abstract form or general hint, e.g.,
`# svn checkout [I]svn-mirror[/I]/[I]repository[/I]/[I]branch[/I] [I]lwcdir[/I]`

I'm glad there is an experienced community to help smooth out the rough spots.


----------



## junovitch@ (Sep 1, 2015)

Hello.  Yes the first link is part of the committer's guide so there is quite a bit of information that isn't helpful in this situation.  The second link from the FreeBSD Handbook is targeted at normal users.


----------



## hanzer (Sep 1, 2015)

So, what should one do if a checkout ends (presumably unfinished) with:

```
svn: E120106: ra_serf: The server sent a truncated HTTP response body.
```


----------



## hanzer (Sep 1, 2015)

And the ports checkout ended (unfinished) with:

```
svn: E120108: Error retrieving REPORT: The server unexpectedly closed the connection.
```


----------



## junovitch@ (Sep 1, 2015)

Interesting.  Is this repeatable?  I just checked out one of the directories without an error.  What does `svn info` and `svn status` inside the directory say?


----------



## hanzer (Sep 1, 2015)

junovitch@ said:


> Interesting.  Is this repeatable?  I just checked out one of the directories without an error.  What does `svn info` and `svn status` inside the directory say?


`svn info`

```
Path: .
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/branches/2015Q3
Relative URL: ^/branches/2015Q3
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 395736
Node Kind: directory
Schedule: normal
```
`svn status` plows through the files, each printed like this (the last one):

```
L  vietnamese/x-unikey
```
I don't like the idea of putting load on the servers and network but I might delete /usr/src, /usr/ports, and /usr/doc and initiate a new checkout with
*svn.FreeBSD.org* rather than *svn0.us-west.freebsd.org* (unless there is a more elegant solution).


----------



## junovitch@ (Sep 1, 2015)

All the files are locked.  How about a `svn cleanup` to remove the locks and try just a `svn up`.


----------



## junovitch@ (Sep 1, 2015)

hanzer said:


> ...
> and initiate a new checkout with
> *svn.FreeBSD.org* rather than *svn0.us-west.freebsd.org* (unless there is a more elegant solution).


You can use `svn switch --relocate https://svn0.us-west.FreeBSD.org https://svn.FreeBSD.org/` however I would try to ensure the checkout is clean before doing so.

Additional reference:
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.switch.html


----------



## hanzer (Sep 1, 2015)

junovitch@ said:


> All the files are locked.  How about a `svn cleanup` to remove the locks and try just a `svn up`.



Oops, just did a `rm -rf src ports doc` and launched new checkouts with the proper address. *But*, if any of these checkouts face-plant, I'll happily pursue the `svn cleanup` `svn up` approach. (Too much coffee today).


----------



## wblock@ (Sep 1, 2015)

hanzer said:


> sometimes a bit difficult to sort out [within the docs] what is a working example (and/or recommended best practice)


In the HTML documents, user input is shown in bold.  Replaceable portions (things that are not literal, that the user is supposed to replace with a real value) are shown in italics.


----------



## hanzer (Sep 3, 2015)

Hi, I'm preparing for a more custom build of the system source for my hardware and use case. Where might I find a list of module names & descriptions for the make.conf(5) variable "_WITHOUT_MODULES_"?


----------



## hanzer (Sep 3, 2015)

Is there any advantage to compiling drivers into the kernel? There seems to be more flexibility if they are kept as modules that can be loaded and unloaded.


----------



## wblock@ (Sep 3, 2015)

Source modules that can be turned on and off are documented in src.conf(5).

There is not much advantage to building drivers into the kernel, except that they are there from boot without being loaded manually or in /boot/loader.conf.  Drivers built into the kernel can be a disadvantage if they recognize hardware that the user might want to ignore, like motherboard RAID controllers.


----------



## hanzer (Sep 3, 2015)

wblock@ said:


> Source modules that can be turned on and off are documented in src.conf(5).


My /etc/make.conf looks like this:

```
CPUTYPE?=k8
MAKE_SHELL?=sh
INSTALL+= -C
#WITHOUT_MODULES=  bktr plip
NO_PROFILE=true  # Avoid compiling profiled libraries
PRINTERDEVICE=ascii
TOP_TABLE_SIZE=101
DOC_LANG=en_US.ISO8859-1
```
It was derived from /usr/share/examples/etc/make.conf which has lines like:

```
# The list of modules to build instead of all of them.
#MODULES_OVERRIDE=  linux ipfw
#
# The list of modules to never build, applied *after* MODULES_OVERRIDE.
#WITHOUT_MODULES=  bktr plip
```
Some of those module names, "linux ipfw bktr plip", don't seem to have obvious correlatives in src.conf(5) variables.

For completeness, my /etc/src.conf file looks like this:

```
WITHOUT_ATM=true
WITHOUT_ZFS=true
WITHOUT_PROFILE=true
```



> There is not much advantage to building drivers into the kernel, except that they are there from boot without being loaded manually or in /boot/loader.conf.  Drivers built into the kernel can be a disadvantage if they recognize hardware that the user might want to ignore, like motherboard RAID controllers.


Groovy, that's what I suspected. Thanks for the confirmation.


----------



## wblock@ (Sep 3, 2015)

Don't duplicate settings in both files.  Put everything related to source modules in src.conf.  There are some universal settings that have to go in make.conf but other than that, try to keep it minimal.


----------



## hanzer (Sep 3, 2015)

I found that a careful reading of section 23.6.2. Configuration Files is helpful. In summary:

[FONT=Times New Roman]Any options which are added to /etc/make.conf will control the how make(1) runs and builds programs. These options take effect every time make(1) is used, including compiling applications from the Ports Collection, compiling custom C programs, or building the FreeBSD operating system. [snip] Unlike  /etc/make.conf, the contents of /etc/src.conf only take effect when the FreeBSD operating system itself is being built.[/FONT]​
Given that, I suppose in my current setup: [FONT=Courier New]TOP_TABLE_SIZE=101,[/FONT] could be moved to /etc/src.conf  but, in this case, I think it would be simpler to remain consistent with the examples and the man pages.

*Update*


hanzer said:


> Some of those module names, "linux ipfw bktr plip", don't seem to have obvious correlatives in src.conf(5) variables.


After some grep(1)'ing and exploring in the source tree, I suspect the kernel module names that can be used with the make.conf(5) variable: _WITHOUT_MODULES_, might be equivalent to the names of the subdirectories under /usr/src/sys/modules/.


----------

