You can capture the output sent to STDOUT to a file via redirection. As an example:

$ dmesg > dmesg_output.txt

Cut-and-paste the file's contents into a response to this thread. Not knowing anything about your configuration, you may need to copy the file to a flash drive, & mount it in a new environment which has a browser & Internet connection before you are finished.

Quote:

I am testing in virtualbox.

The problem with virtualization software is that like any other piece of software, it will likely have bugs. Although there has been a resurgence in the virtualization market in the last few years, companies & projects building virtualization software target the largest markets -- Windows, OS/X, Linux, & perhaps Solaris. Few virtualization environments support OpenBSD, & most don't do a very good job. The OpenBSD project is also not thrilled with virtualized environments because of their bugs which adversely affects stability, security, & support.

Likewise, I don't use any virtualized software solutions, so I will not be able to help you further. Perhaps someone else with experience in using VirtualBox with OpenBSD will join this thread to help you.

Thank you dgiorgio for the dmesg(8) output. If someone feels they have sufficient knowledge of VirtualBox to help you separate swap to another partition, they will respond at their convenience.

Recognize that DaemonForums has no official connection to the OpenBSD Project, and those that answer questions here are not project developers. This site is maintained by enthusiasts not affiliated with the OpenBSD project.

Repeating again, discussions found on OpenBSD's official mailing lists show that many project developers are not fans of the current virtualization software solutions available today for the reasons previously stated -- bugs exist in the virtualization code which prevents OpenBSD from either running or security holes are introduced by the virtualization software. I do not know whether this is the situation you are running into or not as I don't use VirtualBox or any other virtualization software.

The Master Boot Record (MBR) is the first sector on the boot device recognized by the i386 BIOS. Once the BIOS has probed all peripherals of the system, it will transfer execution to the MBR which does minimal sanity checking to ensure that one MBR partition (The MBR supports four...) has been set as active before executing code to boot the operating system found in the active partition. There are a number of resources which describe the intricacies of the MBR throughout the Internet. One is the following:

Note that there is a difference between MBR partitions and partitions defined within disklabel(8). OpenBSD will be installed into a single MBR partition, & it will always boot from a kernel found in the disklabel(8)'s "a" partition.

OpenBSD can be configured to boot from a different hard drive, & this is configured in boot.conf(8) as previously discussed. You may find the discussion in the disklabel(8) manpage helpful as well.

On architectures that require a 2 stage bootloader, such as i386, the second stage boot loader can use the boot.conf(5) configuration file to boot a kernel from any FFS filesystem in the OpenBSD disklabel from any drive.

But the bootload can only find that /etc/boot.conf file on the FFS filesystem in partition "a" of the booting drive.

The kernel also sets the root partition, needed for finding /etc/rc and starting normal execution. If this is not "a" from the booting drive, this requires either a custom kernel or manual setting during boot via the "boot -a" second stage bootloader command.

If editing the disklabel to swap partition letters is not an option, re-install certainly is. It is not clear to me how the kernel ended up on "e", but it should not be there.