1. Not sure I understand the question.
1A. If the "poster" downloaded the packages, would subsequent updates download all of the packages?
No, no restriction on that.
1B. If the "poster" downloaded the packages, would it download the packages if I performed those steps manually?
Yes.
2. Download bsd.rd for current and boot from it (i.e. pub/OpenBSD/snapshots/$arch/bsd.rd)
3. Download bsd.rd for the version you wish to upgrade to, then boot from it. It will run you through the installer (with minor exception...it asks if you want to update or perform a fresh install). Once you go through that, reboot and login as root, then sysmerge to get /etc/* up to date, then update your packages (I use pkg_add -uF update,updatedepends...others may have more appropriate advice on that).

That FTP command will copy ALL amd64 packages to your local system. This is unnecessary. You will only install a small fraction of these packages on your system. Instead, set the $PKG_PATH environment variable, and use pkg_add(1). It will transfer and install the package you request and its dependent packages automatically. Please see FAQ 15.

As for bsd.rd, this is the RAMDISK kernel. It is used for install, upgrade, maintenance of the root directory, and disaster recovery. When you install OpenBSD for the first time, you are using a RAMDISK kernel. On amd64, the boot loader produces a "boot>" prompt and waits for five seconds. If you begin typing, you can select an alternate kernel to boot from. (See the boot(8) man page.) So, to upgrade to -current, all you need to do is download the bsd.rd from the most recent -current snapshot, and select that kernel to load at the boot> prompt, then upgrade over the network.

Let me expand on that comment. For 5.3-release, there are 7634 packages for amd64, and they consume 22 GB of disk space. You would waste valuable bandwidth to copy many thousands of files you would never use.

I am still trying to grasp the reason why that guy suggested d/ling all those packages. Either unskilled or a troll... Sadly the first I guess. His video didn't help me much either, I used other sources to finish what I started.

To be listed on this page we require mirrors to be fast, up-to-date, capable, and well-connected to networks in the region in which they serve. Our policy requires mirrors to carry at least the last two releases in binary form (currently 5.2 and 5.3), snapshots, as well as the other associated directories (including OpenSSH/, OpenNTPD/, OpenBGPD/, patches/ and tools/), and keep them current; snapshots should not be older than a week. Note that in the above, "release" means all files under the specific directory (e.g. 5.3/). This includes all architecture subdirectories and the complete packages subdirectory, with packages for all application architectures. As of 5.3, the minimum space required is approximately 400GB. Depending on the disk space available, mirrors may provide more contents, such as older releases, current source tree, etc.

I am still trying to grasp the reason why that guy suggested d/ling all those packages. Either unskilled or a troll... Sadly the first I guess. His video didn't help me much either, I used other sources to finish what I started.

Culturally, the OpenBSD Project members and many OpenBSD users recommend avoiding all third-party "howto" documents, which would of course include Youtube videos -- at least, those which are not recordings of OpenBSD developer presentations.

Most "howto" documents you find on the Internet are made by new or relatively new users who have accomplished something and want to share it, being justifiably proud of their accomplishments. If you keep this in mind when you read them (or, on youtube, watch them), you may glean elements of value. But always, always be mindful that what you have was likely written by a relative newcomer. Commonly, this means the information presented is often out-of-date, incomplete, inaccurate, misleading, incorrect, or wrong.

I include this website in the list of third-party knowledge bearers which may provide misleading, incorrect, incomplete, or inaccurate information. We're users. We provide advice based only on our own experience and knowledge, which may be limited, and we make our recommendations on the limited information presented by another user. Yes, there are a few developers who visit from time to time, and we have a World Famous Technology Author (two books listed!) who stops by. But the active members here are almost entirely just a small community of users, not developers, and we're just trying to help each other by sharing what we consider best practices. They may not be.

The official "howto" documents are the chapters of the OpenBSD FAQ. Spending time with the FAQ will usually be very informative, and often faster than posting a question here and waiting for a reply.

Yes, however many there might be quality documents out there that helped me through the years since I first wandered into the world of *nix, there also exist poorly written plain garbage. I cannot cross out ALL the user-contributed documents, but one gets more and more experience everyday helping picking out the rubbish. And never forget this is the world wide web, where everyone speaks their mind!

I cannot cross out ALL the user-contributed documents, but one gets more and more experience everyday helping picking out the rubbish.

You may be overlooking cultural differences. The OpenBSD developers put significant importance on the quality of its manpages as being the definitive source of truth next to the source code itself. Hence, these pages are what users should search through first to find out the intentions, usage, & shortcomings of the various utilities & functions provided in a base installation. The OpenBSD community discourages how-to's for exactly the reasons jggimi outlined above. Because long time users understand the project's philosophy about documentation, most will shy away from creating documentation unless there is a specific reason for doing so.

This will also indicate who it is that is writing non-sanctioned OpenBSD documentation -- those who don't understand the project, its goals, nor the need to keep the documentation centralized. No one is guaranteeing its veracity, so it is anyone's guess as to whether it is correct, up to date, & inclusive enough to address the differences readers will have in their own configurations.

Maybe you are coming from the Linux tradition where the kernel is created by one group, & userland utilities and user applications come from elsewhere. Who owns the documentation is not entirely clear to that community, & the result shows. The "how-to" culture is a bandage which does not address the fundamental problem & need of that community. "How-to" documents promote sloppy thinking, short-cutting real understanding, & general problem-solving. "If I only look a little longer, someone will have fixed my problem without knowing my situation, & I don't have to bother figuring it out for myself".

Then something will eventually break where you will need to troubleshoot the whole mess. Good luck.

Save yourself some time & aggravation by studying what documentation the project provides first. The discipline will serve you well in the future, & you may very well find a better solution faster.

I wrote a "howto" in 2011. I didn't self-publish. Instead, I submitted it to the OpenBSD Journal, where a team of developer/editors worked to improve its clarity, and they helped me to make it more general and less specific.

The editorial review and approval process took several weeks. But it really helped.

----

It's been less than two years since publication, but that "howto" is already out of of date. Changes to the second-stage bootloader used in i386 and amd64 have made the process even easier, and a simplified procedure is now a part of FAQ 14.21.

Location: hot,dry,dusty,rainy,windy,straight winds, puts the fear of God in you-Texas

Posts: 58

Thanked 0 Times in 0 Posts

I am a new user, been using OpenBSD since 5.0.
My advice is stick to the "man pages" and specific OpenBSD forums.
It will save you much grief.
One of the important goals of the project is quality documentation.