Really what is going on with this, I just want the paths to persist after reboot, why is /etc/installurl erased when i reboot? What possible purpose could that serve? Why doesn't the installurl man doc state the process required to force persistence?

I like so much about openbsd so far but geez every single headache i have had could have been solved by one sentence in the docs. how could someone not have seen that installurl disappearing would be an inconvenience?

or am i missing something that was there for me to read?

Sorry to hear you are having trouble but fact is my /etc/installurl does persist a reboot.

Here's my /etc/installurl

Which version of OpenBSD are you running ?

installurl(5) is "persistent" as standard. It is only changed by a script during a base system install/upgrade.

Ok I confirmed it is now persistent, some odd thing with vmware clones must have happened or I made a mistake. Thanks for the responses.

btw I am in openbsd 6 and if I had another question it would be, where are the best up to date tutorials for getting up and running with a desktop? My searches took me to old stuff that basically worked but I find that the actual steps required diverged or were not easily discernable from the documentation.

If you want to install xfce the command is

That is what I use.

Assuming you included the xorg set when you installed, it is as easy as installing your desired GUI. After that, individual GUIs may have different small steps. Since I used i3, I copy the /etc/i3/config to ~/home as .xinitrc and add my tweeks to it.

There is nothing special about the "major" number in any OpenBSD release. There are two releases per year, each release increases the release number by 0.1, and only the most recent two releases are supported. At this writing, 6.3 is the most recent release, 6.2 will continue to be supported until 6.4 is released, expected on-or-about November 1. The next "major" number in releases will be the 7.0 release in 2021, only because it is the next release number after 6.9.The OpenBSD FAQ contains the only official, accurate, and up-to-date "how to" documentation for the most recent release.

Third-party "how to" documents are generally frowned upon by Project members. They are often found in-the-wild to be incomplete, out-of-date, and unmaintained. Usually, the author has considered only one or a very limited set of use-cases, and new users who discover these guides by Googling can easily become confused.

The last semi-official "how to" I wrote was for the OpenBSD Journal. My article had a panel of editors who reviewed and critiqued, and it took a while for my "how to" to become acceptable -- perhaps 4 or 5 revisions back-and-forth. Once published, unfortunately, it was both out-of-date and obsolete within a year... that means within 2 releases.

Ok now looking over the FAQ, I see where I got lost. After the install section, I didn't find the package management in time or know that is what I needed.

I believe 'package management' should come before 'system management' and 'install' should say at the end of it simply, 'The next step is to configure repositories and start installing software' which would link to package management section.

That would have helped me, but now I understand, thanks for the background information.

The ports system is not part of the OpenBSD base system. Hence why it's treated as an optional extra. It may seem unusual to you, but there are many use cases for OpenBSD where no ports may be installed.

If you read the man page for installurl(5) you'll see that it's not specific to ports/packages.

For example, it would be used during an upgrade (using the supported method via the ramdisk kernel of the release you're upgrading to) or when installing the sets via http (rather than from installation media).

pkg_add(1) gets it's installpath from /etc/installurl. It works out the rest of the path to the package snapshot based on the architecture and release.

The PKG_PATH variable on the other hand should equal the path to the snapshot of packages. installurl first appeared in 6.1-release as a I recall, prior to this PKG_PATH was the fairly standard approach.

The "Selecting a mirror" section of faq15 has details of this.

I know that ports and packages are different, but I don't see how the necessary step for configuring a system, setting up repositories and a software installation method, would come after system management tasks like editing the passwd file. Connecting pkg_add to a mirror is a critical step in installation.

Selecting a Mirror should come before System Management in the docs, I don't see any case working for the contrary argument.

As it stands now it's bad writing, the outline is out of order.

Would it make any difference to send this insight to the maintainers? I will anyway.

Packages are just pre-compiled ports so not different at all. If you simply build a package from the ports release tarball, then end result should be identical to the pre-compiled package.

You should probably address your concerns to the project's mailing lists.

The most acceptable way to present any idea to the OpenBSD Project -- that is, to the OpenBSD developers -- is in the form of completed effort on your part. That means, in the form of a unified diff(1), sent in-line in an Email to the appropriate mailing list. This permits the developers to review and comment on work that you have performed, rather than asking the developers to do the work for you.

Luckily, the complete content of the OpenBSD Project's static website is available to all as a CVS repository, just like the source tree or the ports tree, so that you can download a working set of the current website, make revisions locally, and then create one or more diff(1) files that you can present to the Project with your complete idea for changing the website for their consideration.

I have contacted the sites mailing list. Depending on the response I will consider using CVS to make my suggestion, but in this case it is pretty straightforward what I am suggesting.

At any rate thanks to you guys I know more than I did so thanks.

I've seen the posting.

Do not be alarmed if you do not get any reply at all to your suggestion, or receive responses from other end-users instead of any of the developers. Half of the developers do not follow misc@, and, as I noted above, suggestions from us that arrive in the form of completed work (unified diffs) are given the most attention. Suggestions in the form of, "It would be great if you guys would do this thing!" are usually not well-received.