Install problems for DragonFlyBSD 6.4.1

[Nelson H. F. Beebe]

I have now made several attempts at installing the new DragonFlyBSD
6.4.1 in a virtual machine under virt-manager on a physical host that
runs Ubuntu 24.04.  None has yet been satisfactory.

The installation proceeds normally, the system reboots, and 6.4.1
always comes up with a filesystem that has a completely unusable small
disk of 5GB or 6GB.

I have tried Hammer2 multiple times, Hammer1 once, and UFS once, with
newly created QEMU disk images files of size 80GB and 160GB.

Until the last attempt, I could not get usble inbound or outbound
networking, having tried virtio, rtl8139, and e1000 network
interfaces.

After the latest attempt, I can ssh into the system after a boot with
the rtl8139 (virtual) card, and now I can produce this report on the
new virtual machine:

	# uname -v
	DragonFly v6.4.1-RELEASE #9: Tue Apr 29 16:25:51 EDT 2025 \
	root at www.shiningsilence.com:/usr/obj/home/justin/release/6_4/sys/X86_64_GENERIC

	% cat /etc/fstab
	# Device                Mountpoint      FStype  Options         Dump    Pass#
	/dev/vbd0s1a            /boot           ufs     rw              2       2
	/dev/vbd0s1b            none            swap    sw              0       0
	/dev/vbd0s1d            /               hammer2 rw              1       1
	/build/usr.obj  /usr/obj                null    rw              0       0
	/build/var.crash        /var/crash              null    rw              0      0
	/build/var.cache        /var/cache              null    rw              0      0
	/build/var.spool        /var/spool              null    rw              0      0
	/build/var.log  /var/log                null    rw              0       0
	/build/var.tmp  /var/tmp                null    rw              0       0
	tmpfs   /tmp            tmpfs   rw              0       0
	proc                    /proc           procfs  rw              0       0

	% df -h
	Filesystem         Size   Used  Avail Capacity  Mounted on
	vbd0s1d           5582M   418M  5164M     7%    /
	devfs             1024B  1024B     0B   100%    /dev
	/dev/vbd0s1a      1022M   181M   759M    19%    /boot
	/build/usr.obj    5582M   418M  5164M     7%    /usr/obj
	/build/var.crash  5582M   418M  5164M     7%    /var/crash
	/build/var.cache  5582M   418M  5164M     7%    /var/cache
	/build/var.spool  5582M   418M  5164M     7%    /var/spool
	/build/var.log    5582M   418M  5164M     7%    /var/log
	/build/var.tmp    5582M   418M  5164M     7%    /var/tmp
	tmpfs             1967M     0B  1967M     0%    /tmp
	procfs            4096B  4096B     0B   100%    /proc
	tmpfs             1967M     0B  1967M     0%    /var/run/shm

	# camcontrol devlist
	<QEMU QEMU DVD-ROM 2.5+>           at scbus0 target 1 lun 0 (sg0,pass0,cd0)

	# mount
	vbd0s1d on / (hammer2, local)
	devfs on /dev (devfs, nosymfollow, local)
	/dev/vbd0s1a on /boot (ufs, local)
	/build/usr.obj on /usr/obj (null)
	/build/var.crash on /var/crash (null)
	/build/var.cache on /var/cache (null)
	/build/var.spool on /var/spool (null)
	/build/var.log on /var/log (null)
	/build/var.tmp on /var/tmp (null)
	tmpfs on /tmp (tmpfs, local)
	procfs on /proc (procfs, local)
	tmpfs on /var/run/shm (tmpfs, local)

I have photographed various installer screens, and they all show that
an 80GB or 160GB disk has been found, but the final filesystem seems
stuck at 5GB or 6GB, depending on the filesystem type.

One of the installer screens that has shown up frequently is the one
that says

	WARNING: Small HAMMER filesystems can
	fill up very quickly!		
	...

I do not have a spare physical machine to try an installation there:
VMs are my only possibility.

I've been running more than 30 DragonFlyBSD systems from version 3.6
(November 2013) forward to 6.4.0 (January 2023) in virtual machines,
and a home physical machine has been running version 5.8 stably for
the last 5 years, so today's frustrations have been a surprise.

Does anyone have any idea why the full disk is inaccessible with all
three filesystem types in DragonFlyBSD 6.4.1?

Has anyone seen similar experience with the new release?

Is there a "file extend" command that could expose the rest of the
disk for use?


-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                                                          -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: https://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------