Why the Scare Quotes?

I say this is the "advanced" HAMMER2 installation process because it's not recommended. Like, at all. But I figured it'd be fun to take advantage of the fact that *BSD lets you run with scissors if you really feel the need to.
This is my process for a full-disk, EFI installation with HAMMER2 as the rootfs, and mimicking the basic setup of ZFS when using something like FreeBSD, HardenedBSD, or Illumos. It's important to remember, that while HAMMER2 is awesome, it is NOT ZFS! This is just me having fun with the ability to arbitrarily create pfs-es and administer them in a similar manner to ZFS. I cannot stress enough how much this shouldn't be done in production unless by the time you're reading this, HAMMER2 is considered stable and this process has been adopted to some degree. (As of this time of writing, 2017-01-30 @ 02:55 UTC, this is not the case)

Get the Install Media!

You can't install an OS without install media! Head on over to https://www.dragonflybsd.org/ to get yourself the latest install image. Ideally get the USB image (ends in ".img"), this way you boot into a live system with a rw rootfs, this gives you the ability to use it as intermediary storage, or build a DragonFly BSD install from source should you choose to do so.
NOTE: The USB images are compressed filesystems, the download should be around 200MB, but the uncompressed version will be around 2GB, this is meant to give you space to experiment with the OS prior to doing a full install. This is NOT like live Linux images.
After downloading, you'll need to decompress the image. This is done rather simply with the command

	bunzip2 dfly-x86_64-5.0.2_REL.img
(of course, replace the name with the actual path to your downloaded image, 5.0.2 is just the latest release at the time of writing). Then, use your favorite disk imaging utility, or even just a tool that's happy writing to a block device directly. dd(1), for example:
	## Replace da8 with the appropriate block device on your system
	dd if=dfly-x86_64-5.0.2_REL.img of=/dev/da8 bs=4m && sync

Set Up the Drive

So this time, I mean the drive you want to install your new DragonFly BSD system on. This should be a drive that has at least 50GB of free space for best results due to the design of HAMMER2, being both CoW and not immediately freeing space can lead to your drive filling up faster than you'd anticipate on something like UFS, EXT4, or XFS.
Of course, step one is to actually boot the install media. Log in as "installer" and set up your network connection, if necessary, change the keyboard layout to something more comfortable (like maybe Dvorak?). These options should be immediately available under the LiveCD Utilities option once the ncurses installer gets started. An important note here is that the installer UI is on ttyv2, ttyv1 initially had the login screen, and we want to switch to ttyv3 to make the best use of the screen space you have available. This is simple: hit Alt-F3 (no need for Control). Once on this tty, you'll be greeted with another login prompt. This time, log in as "root", there's no password, so you should be dropped into the interactive shell right away. Unlike many, if not most Linux distros, the interactive shell is csh, not bash. So you may want to run the following commands to make things a bit more comfortable:

	# Turn off the bell
	sysctl kern.sysbeep_enable=0
	# Remove the need to run rehash
	set autorehash
	# Show some completion options 
	set autolist
	# Offer to correct commands
	set correct = cmd
With the environment set up like that, we're ready to work on the rest of the installation. First and foremost, we need to know if this is going to be using Legacy BIOS to boot or if it's booting via (U)EFI. Most modern machines are using (U)EFI, which makes setting up the boot management incredibly simple, if a bit confusing at first. Legacy BIOS is also fairly simple, though I've run into more issues with that method than with (U)EFI booting, so I highly recommend using (U)EFI if your system supports it. Due to my experiences, I'm only going to cover the (U)EFI setup process. Legacy BIOS should be configured in much the same way, but the bootloader installation is different.

(U)EFI Steps

The steps taken here are essentially a customized, manual run of efisetup(8), using HAMMER2 instead of HAMMER, and possibly creating additional slices to house additional filesystems. This would enable you to mix HAMMER and HAMMER2 should you want to do so.
First: we need to initialize the target drive, if this is a SATA drive it should show up as da0 or some other number, depending on how many SATA drives are connected. If it's an NVMe drive it'll be nvme0 or a higher number, depending on how many NVMe drives you have. If you have multiple drives with multiple OS installs, you'll need to use the following commands to find the available devices and identify which drive you actually want to install to.

	# Get basic device info 
	# NOTE: does not report NVMe drives
	camcontrol devlist

	# If that doesn't give you enough information
	# this will display drive sizes
	camcontrol readcap -h

	# If you're using an NVMe drive, you'll need to 
	# use the following command instead
	gpt -rv show nvme0

	# If you need to check the partition labels, 
	# not just the types, use this instead
	gpt -rv show -l nvme0
Once the target drive is located, the process is rather simple, if potentially a bit confusing. I'll continue using shell style comments to explain the process as we go.
NOTE: HAMMER2 is still under development at the time of this writing, and not considered stable. Things may change making this guide incorrect. Not BTRFS unstable, but still, don't say you weren't warned.
	## Create a GPT partition table
	gpt create -f da0 
	# NVMe
	gpt create -f nvme0

	## Create the ESP 
	gpt add -s 524288 -i 0 -t "EFI System" da0
	# NVMe 
	gpt add -s 524288 -i 0 -t "EFI System" nvme0

	## Create the partition to install DragonFly on
	gpt add -i 1 -t dfly da0
	# NVMe 
	gpt add -i 1 -t dfly nvme0

	## Make the ESP bootable 
	mkdir -pv /efimnt
	newfs_msdos da0s0
	mount_msdos da0s0 /efimnt
	mkdir -pv /efimnt/efi/boot
	cpdup -vIm /boot/boot1.efi /efimnt/boot/bootx64.efi && sync
	umount /efimnt
	# NVMe 
	mkdir -pv /efimnt
	newfs_msdos nvme0s0
	mount_msdos nvme0s0 /efimnt
	mkdir -pv /efimnt/efi/boot
	cpdup -vIm /boot/boot1.efi /efimnt/boot/bootx64.efi && sync
	umount /efimnt

	## Create a disklabel
	## This is effectively the same as the partitioning step in other systems
	disklabel -r -w da0s1 auto
	# NVMe
	disklabel -r -w nvme0s1 auto

	## Edit the disklabel
	## As a heads-up, this will launch vi(1) by default
	## if you're not familiar with vi(1), you can also use ee(1)
	## which is similar to nano on Linux distros.
	disklabel -r -e da0s1
	# with ee(1) instead of vi(1)
	setenv EDITOR ee 
	disklabel -r -e da0s1

	# NVMe
	disklabel -e nvme0s1
	# with ee(1) instead of vi(1)
	setenv EDITOR ee
	disklabel -e nvme0s1

	## The disklabel utility has a pretty simple format 
	## slice  :  size  :  offset  :  fstype  
	## now another thing to remember is that by convention,
	## the a slice is /boot partition
	## the b slice is the swap partition (1-2x RAM size is usually a good size)
	## the d slice is the root filesystem
	## You can add as many slices as you like, though I recommend not making
	## any slice holding a HAMMER or HAMMER2 filessytem smaller than 50GB
	## the below is an example 1TB drive partition that I've set up
	## an asterisk in the size column is using all remaining space on the drive
	## an asterisk in the offset column allows the offset to be automatically calculated

	a: 1g  0  4.2BSD # boot partition, 1G mandatory
	b: 16g *  swap   # swap space
	c: 256g * hammer2 # used for jails
	d: 512g * hammer2 # root filesystem
	e: *    * hammer2 # home filesystem

	## After this has been modified to suit your needs, you'll need to format the partitions
	newfs da0s1a # create the /boot filesystem
	newfs_hammer2 da0s1c # jail partition
	newfs_hammer2 da0s1d # rootfs partition
	newfs_hammer2 da0s1e # home partition

	# NVMe
	newfs nvme0s1a # create the /boot filesystem
	newfs_hammer2 nvme0s1c # jail partition
	newfs_hammer2 nvme0s1d # rootfs partition
	newfs_hammer2 nvme0s1e # home partition

	## Now we need to get the necessary filesystems mounted 
	mount_hammer2 da0s1d@LOCAL /mnt
	mkdir -pv /mnt/boot
	mount da0s1a /mnt/boot

	# NVMe 
	mount_hammer2 nvme0s1d@LOCAL /mnt
	mkdir -pv /mnt/boot
	monut nvme0s1a /mnt/boot

	## Now we just create the additional pseudo filesystems
	## these will serve a similar role as ZFS datasets
	## Update: As of 2018.04.18, I cannot recommend putting /usr and /usr/lib on their own PFS
	## this may only be due to me running on MASTER, but /bin/sh requires libssp.so.8, which 
	## is in /usr/lib/gcc50. Do what you like, but you've been warned.
	hammer2 -s /mnt pfs-create usr
	hammer2 -s /mnt pfs-create usr.dports
	hammer2 -s /mnt pfs-create usr.include
	hammer2 -s /mnt pfs-create usr.lib
	hammer2 -s /mnt pfs-create usr.local
	hammer2 -s /mnt pfs-create usr.obj
	hammer2 -s /mnt pfs-create usr.share
	hammer2 -s /mnt pfs-create usr.src
	hammer2 -s /mnt pfs-create usr.local.include
	hammer2 -s /mnt pfs-create usr.local.lib
	hammer2 -s /mnt pfs-create usr.local.share
	hammer2 -s /mnt pfs-create usr.local.var

	## So naturally, the next step is to create the required mountpoints
	## and mount these HAMMER2 PFS-es, this process can be much more flexible
	## once the clustering code is added, but for now, think of them as simply
	## logical separations on your drive, so you can more easily manage single 
	## portions of the OS
	mkdir -pv /mnt/usr
	mount_hammer2 -o local,noatime da0s1d@usr /mnt/usr
	mkdir -pv /mnt/usr/dports
	mount_hammer2 -o local,noatime da0s1d@usr.dports /mnt/usr/dports
	mkdir -pv /mnt/usr/include
	mount_hammer2 -o local,noatime da0s1d@usr.include /mnt/usr/include
	mkdir -pv /mnt/usr/lib
	mount_hammer2 -o local,noatime da0s1d@usr.lib /mnt/usr/lib
	mkdir -pv /mnt/usr/local
	mount_hammer2 -o local,noatime da0s1d@usr.local /mnt/usr/local
	mkdir -pv /mnt/usr/obj
	mount_hammer2 -o local,noatime da0s1d@usr.obj /mnt/usr/obj
	mkdir -pv /mnt/usr/share
	mount_hammer2 -o local,noatime da0s1d@usr.share /mnt/usr/share
	mkdir -pv /mnt/usr/src
	mount_hammer2 -o local,noatime da0s1d@usr.src /mnt/usr/src
	mkdir -pv /mnt/usr/local/include
	mount_hammer2 -o local,noatime da0s1d@usr.local.include /mnt/usr/local/include
	mkdir -pv /mnt/usr/local/lib
	mount_hammer2 -o local,noatime da0s1d@usr.local.lib /mnt/usr/local/lib
	mkdir -pv /mnt/usr/local/share
	mount_hammer2 -o local,noatime da0s1d@usr.local.share /mnt/usr/local/share
	mkdir -pv /mnt/usr/local/var
	mount_hammer2 -o local,noatime da0s1d@usr.local.var /mnt/usr/local/var

	# NVMe
	mkdir -pv /mnt/usr
	mount_hammer2 -o local,noatime nvme0s1d@usr /mnt/usr
	mkdir -pv /mnt/usr/dports
	mount_hammer2 -o local,noatime nvme0s1d@usr.dports /mnt/usr/dports
	mkdir -pv /mnt/usr/include
	mount_hammer2 -o local,noatime nvme0s1d@usr.include /mnt/usr/include
	mkdir -pv /mnt/usr/lib
	mount_hammer2 -o local,noatime nvme0s1d@usr.lib /mnt/usr/lib
	mkdir -pv /mnt/usr/local
	mount_hammer2 -o local,noatime nvme0s1d@usr.local /mnt/usr/local
	mkdir -pv /mnt/usr/obj
	mount_hammer2 -o local,noatime nvme0s1d@usr.obj /mnt/usr/obj
	mkdir -pv /mnt/usr/share
	mount_hammer2 -o local,noatime nvme0s1d@usr.share /mnt/usr/share
	mkdir -pv /mnt/usr/src
	mount_hammer2 -o local,noatime nvme0s1d@usr.src /mnt/usr/src
	mkdir -pv /mnt/usr/local/include
	mount_hammer2 -o local,noatime nvme0s1d@usr.local.include /mnt/usr/local/include
	mkdir -pv /mnt/usr/local/lib
	mount_hammer2 -o local,noatime nvme0s1d@usr.local.lib /mnt/usr/local/lib
	mkdir -pv /mnt/usr/local/share
	mount_hammer2 -o local,noatime nvme0s1d@usr.local.share /mnt/usr/local/share
	mkdir -pv /mnt/usr/local/var
	mount_hammer2 -o local,noatime nvme0s1d@usr.local.var /mnt/usr/local/var

	## Now we have a decision to make, you can either 
	## clone the live image, or build a new installation from source
	# Source method
	## With this method, you may want to make some changes to /etc/make.conf
	## the defaults are perfectly fine, sane, and result in a pretty fantastic system,
	## however, if you're reading this, you may be like me in that you have a compulsion to
	## stick your ${EDITOR} where it doesn't belong and see if you can't make things better
	## Below is how I generally try to build my DragonFly systems:
		CFLAGS += -march=native -mtune=native -O2 -pipe -fPIC -fpic -fstack-protector-strong
		# While kept the same as CFLAGS, setting CXXFLAGS += ${CFLAGS} can break C++ 
		# software being built, by passing something like `-std=c99` to a C++ build, 
		# which throws errors, causing builds to fail
		CXXFLAGS += -march=native -mtune=native -O2 -pipe -fPIC -fpic -fstack-protector-strong
		LDFLAGS += -z combreloc
		# These are boolean, so just defining them is sufficient
		# but I like to be explicit in my configs so they're easier
		# to understand when I need to come back to them

	cd /usr/src
	make -j `sysctl -n hw.ncpu` buildworld
	make -j `sysctl -n hw.ncpu` installworld DESTDIR=/mnt
	make -j `sysctl -n hw.ncpu` buildkernel
	make -j `sysctl -n hw.ncpu` installkernel DESTDIR=/mnt
	cd etc
	make distribution DESTDIR=/mnt

	# Cloning method
	# alternatively, use: cpdup -dIm ${source} ${destination} 
	# to reduce the output
	cpdup -vvvIm /boot /mnt/boot
	cpdup -vvvIm / /mnt
	cpdup -vvvIm /usr /mnt/usr
	cpdup -vvvIm /usr/include /mnt/usr/include
	cpdup -vvvIm /usr/lib /mnt/usr/lib
	cpdup -vvvIm /usr/local /mnt/usr/local
	cpdup -vvvIm /usr/share /mnt/usr/share
	cpdup -vvvIm /usr/local/include /mnt/usr/local/include
	cpdup -vvvIm /usr/local/lib /mnt/usr/local/lib
	cpdup -vvvIm /usr/local/var /mnt/usr/local/var
	cpdup -vvvIm /var /mnt/var

	## At this point, you should have all the necessary tools to 
	## boot into a new DragonFly BSD installation, 
	## but first, we should really configure some things

	# Generate a baseline fstab
	mount | grep hammer2 | awk '{print $1;}' >> /mnt/etc/fstab

	# Edit that fstab to actually work
		## Of course, change the devices to suit your drive, like 
		## using nvme0s1 to address your NVMe drive
		da0s1a /boot ufs noatime 0 0
		da0s1b none swap sw 0 0
		da0s1d@LOCAL / hammer2 local,noatime 0 1
		da0s1d@usr /usr hammer2 local,noatime 0 0 
		da0s1d@usr.dports /usr/dports hammer2 local,noatime 0 0 
		da0s1d@usr.include /usr/include hammer2 local,noatime 0 0
		da0s1d@usr.lib /usr/lib hammer2 local,noatime 0 0
		da0s1d@usr.local /usr/local hammer2 local,noatime 0 0
		da0s1d@usr.obj /usr/obj hammer2 local,noatime 0 0 
		da0s1d@usr.share /usr/share hammer2 local,noatime 0 0 
		da0s1d@usr.src /usr/src hammer2 local,noatime 0 0 
		da0s1d@usr.local.include /usr/local/include hammer2 local,noatime 0 0 
		da0s1d@usr.local.lib /usr/local/lib hammer2 local,noatime 0 0 
		da0s1d@usr.local.share /usr/local/share hammer2 local,noatime 0 0 
		da0s1d@usr.local.var /usr/local/var hammer2 local,noatime 0 0 
		# The size argument should be relative to both your total RAM and
		# how much data you expect each tmpfs directory to hold. 512MB should 
		# be more than enough for most desktop/workstation use cases, but may not 
		# be enough for a production server
		# Of course, this is not at all necessary, but it can help speed up 
		# certain programs by writing volitile files to RAM instead of writing to
		# disk. If you can't spare the RAM due to other constraints, feel free 
		# to omit these lines.
		dummy /tmp tmpfs size=512m,mode=0777,owner=root,group=wheel 0 0
		dummy /var/run tmpfs size=512m,mode=0777,owner=root,group=wheel 0 0 
		dummy /var/tmp tmpfs size=512m,mode=1777,owner=root,group=wheel 0 0

	# Tell the bootloader where root is 
	# Set some options in sysctl.conf(5)
		# Disable the bell
		# Needed for chromium to work correctly
		# Prevent unprivileged users from seeing all processes & threads
		# Prevent hardlink abuse
		# Take advantage of the ASLR code
		# Randomize your PIDs

	# Get the basics set in rc.conf
		# Set the hostname
		hostname="DragonFly.bsd.loc" # this is the FQDN of the host
		# Enable sshd
		# Enable dbus
		# Enable udevd
		# Ensure the mouse is usable
		# Disable sendmail
This should leave you with a mostly functional system, though you'll need to configure your network settings as well, setting the DNS servers in resolv.conf(5) and potentially using wpa_supplicant to connect to a wifi network. The exact methodology of which will depend on your wireless chipset, so check the documentation to see what you need for your hardware to work best for you.