Install problems for DragonFlyBSD 6.4.1

[Antonio Huete Jimenez]

Hey Nelson,

Yeah, there is a bug somewhere when running under a KVM guest where the 
disk won't report the correct size or dfly won't pick it up correctly. 
In the installer, if you go back and forth a couple times to wipe out 
the disk, it will eventually pick up the correct size. Or at least 
that's how I've been able to bypass it.

HTH
Antonio Huete

On 4/30/25 19:41, Nelson H. F. Beebe wrote:
> 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 -
> -------------------------------------------------------------------------------