Bug 252734

Summary:

FreeBSD virtual machine disk images should have greater virtual hard disk capacities

Product:

Base System

Reporter:

Graham Perrin <grahamperrin>

Component:

misc

Assignee:

freebsd-bugs (Nobody) <bugs>

Status:

Closed Not A Bug

Severity:

Affects Some People

Priority:

---

Version:

12.2-STABLE

Hardware:

Any

OS:

Any

URL:

https://www.freebsd.org/where.html#download-rel122

Attachments:

Description	Flags
Screenshot of the Virtual Media Manager in VirtualBox	none
Not enough space …	none
Preparing to attempt to grow the file system	none
Fixing the GPT to use all of the space of the maximised virtual hard disk	none
Retrying following an I/O error	none
Wishing to resize rootfs	none
Apparently impossible to grow the file system with GParted	none
Problems with `growfs /dev/ada0p4` and `gpart recover ada0`	none

Description Graham Perrin freebsd_committer

2021-01-16 05:25:16 UTC

Created attachment 221617 [details]
Screenshot of the Virtual Media Manager in VirtualBox

I added FreeBSD-provided `FreeBSD-12.2-RELEASE-amd64.vhd` to a VirtualBox (on a FreeBSD-CURRENT host). 

<https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html#x11-wm-kde> suggests: 

pkg install x11/kde5

This can not be done; there's insufficient space. 

### Enhancement request

Please give the virtual hard disks for virtual machines (not just FreeBSD-12.2-RELEASE-amd64) as much virtual capacity as possible. 

Doing so need not significantly increase the download sizes. A virtual 2 TB disk for FreeBSD can have an initial actual size, non-compressed, of less than 3.5 GB on the host.

Comment 1 Graham Perrin freebsd_committer

2021-01-16 05:29:32 UTC

Created attachment 221618 [details]
Not enough space …

Failure to install x11/kde5

Comment 2 Graham Perrin freebsd_committer

2021-01-16 05:32:39 UTC

Created attachment 221619 [details]
Preparing to attempt to grow the file system

After using the Virtual Media Manager in VirtualBox to maximise the virtual disk. 

Using Gparted in SystemRescue <https://www.system-rescue.org/>. Fixing the backup GPT.

Comment 3 Graham Perrin freebsd_committer

2021-01-16 05:33:33 UTC

Created attachment 221620 [details]
Fixing the GPT to use all of the space of the maximised virtual hard disk

Comment 4 Graham Perrin freebsd_committer

2021-01-16 05:34:37 UTC

Created attachment 221621 [details]
Retrying following an I/O error

Comment 5 Graham Perrin freebsd_committer

2021-01-16 05:36:12 UTC

Created attachment 221622 [details]
Wishing to resize rootfs

Comment 6 Graham Perrin freebsd_committer

2021-01-16 05:42:09 UTC

Created attachment 221623 [details]
Apparently impossible to grow the file system with GParted

Now I see <https://www.freebsd.org/doc/handbook/disks-growing.html>, which might be slightly outdated (the order of partitions differs from what I found) but I guess that I can use growfs(8).

Comment 7 Graham Perrin freebsd_committer

2021-01-16 05:59:47 UTC

Created attachment 221624 [details]
Problems with `growfs /dev/ada0p4` and `gpart recover ada0`

Comment 8 Graham Perrin freebsd_committer

2021-01-16 07:06:26 UTC

(In reply to Graham Perrin from comment #7)> 

> Problems with `growfs /dev/ada0p4` and `gpart recover ada0`

I have abandoned, deleted the affected .vhd

Comment 9 Conrad Meyer freebsd_committer

2021-01-16 17:20:48 UTC

The correct solution is to grow the provided image.  Otherwise we could not provide one image that would be installable in tiny environments as well as your huge 2TB environment.  Growing VM images is common and widely supported.

Comment 10 Graham Perrin freebsd_committer

2021-01-17 17:44:35 UTC

Thank you, of course you're correct, I didn't think this through completely. 

Part of the confusion is that gpart recover fails to recover the GPT (not only as outlined above); I'll take this problem to the freebsd-current list.