Is Gparted needed in GhostBSD?

vimanuelt

If GhostBSD is installed exclusively using ZFS, then gparted is typically not needed for regular use, and here is why:

Role of GParted

gparted is a graphical partition editor for managing MBR and GPT partition tables, primarily useful for:

Creating partitions (e.g., for ext4, ntfs, fat32, etc.)
Resizing, deleting, or formatting them
Visualising disk layout

However, ZFS does not require or benefit from gparted for its management.

ZFS Partitioning Philosophy

When using ZFS:

ZFS often uses entire disks (e.g., /dev/ada0) or dedicated GPT slices for redundancy, performance, and recovery alignment.
Partitioning for ZFS setups is usually done via:
- gpart (the FreeBSD partitioning tool)
- gbi during GhostBSD installation
- Manual scripting (e.g., gpart create, gpart add, followed by zpool create)

GParted does not understand ZFS partitions well and may mislabel or misinterpret them, which could cause accidental data loss.

vimanuelt

grahamperrin

vimanuelt why is GParted misrepresented negatively with a blunt "No" for ZFS Awareness?

GParted does have ZFS awareness. The same is true for KDE Partition Manager:

vimanuelt

GhostBSD Partitioning & Formatting Guide (CLI)

View Disk Layout

gpart show

Create a GPT Scheme on a New Disk

gpart create -s GPT /dev/da0

Replace /dev/da0 with the target device.

Creating and Formatting Partitions

FAT32 (for USB drives, UEFI, etc.)

gpart add -t msdosfs -l USBFAT /dev/da0
newfs_msdos -F 32 -L "MYUSB" /dev/da0p1

-F 32 sets FAT32. Use msdosfs type for FreeBSD-compatible FAT.

ext4 (for Linux compatibility)

Requires sysutils/e2fsprogs from pkg.

pkg install e2fsprogs
gpart add -t linux-data -l USBEXT4 /dev/da0
mkfs.ext4 -L MYEXT4 /dev/da0p1

To mount ext4 in GhostBSD:

kldload ext2fs
mount -t ext2fs /dev/da0p1 /mnt

ext4 write support is limited and should be used with caution.

NTFS (for Windows sharing)

Requires fusefs-ntfs.

pkg install fusefs-ntfs
gpart add -t ntfs -l USBNTFS /dev/da0
ntfs-3g /dev/da0p1 /mnt

To format:

mkntfs -f -L MYNTFS /dev/da0p1

Erasing a Partition

gpart delete -i 1 /dev/da0
gpart destroy -F /dev/da0

Resize Caveats

gpart can resize partitions with gpart resize -i 1, but not the file system inside.
For ext4, use resize2fs.
NTFS and FAT32 resizing is not recommended on FreeBSD. Use Linux or Windows for this purpose.

Useful Notes

/dev/da0p1 refers to GPT partition 1.
/dev/da0s1 refers to MBR slice 1 (less common on modern disks).
Use -l LABEL to assign a friendly name to a partition.

vimanuelt

grahamperrin
Try it.

vimanuelt

GParted and KDE Partition Manager both can see ZFS partitions but cannot safely interpret, resize, or modify them. Both tools correctly show ZFS partitions with no mount information or usage details. This is expected as they are not ZFS-aware. These tools are helpful for seeing partition structure, but not suitable for managing ZFS data.

grahamperrin

vimanuelt ZFS partitions with no mount information

Because the partition is not mounted.

grahamperrin

vimanuelt GParted and KDE Partition Manager both can see ZFS partitions but cannot safely interpret, resize, …

If resizing is correctly prevented, then how is the interpretation unsafe?

Healthy following a move, according to documentation:

{Screenshot: a pool with multiple file systems, healthy, following a move of the pool's partition by GParted}

vimanuelt

If you are seeking a graphical tool specifically designed to manage ZFS partitions, then using a ZFS-aware GUI utility may offer a more appropriate and reliable solution.

grahamperrin

vimanuelt If you are seeking a graphical tool specifically designed to manage ZFS partitions, …

I'm not.

The wish was concise, simple: GParted.

I know its capabilities.

vimanuelt

Developing a GhostBSD-specific ZFS-aware graphical utility similar in purpose to GParted could be accomplished within a few months. The primary reason it has not yet been created is simply that the idea has not received focused attention.

vimanuelt

grahamperrin
Thanks for the clarification.

If the request is specifically for GParted to support ZFS, then it is worth noting that GParted does not currently support ZFS due to its complexity and licensing differences. That is why ZFS datasets do not appear as mountable partitions in the way other filesystems do.

That said, you do have a few options:

Wait for someone to port or extend GParted to support ZFS, though that is unlikely in the near term unless upstream developers choose to prioritize it.
Initiate or contribute to a port. Since GhostBSD and FreeBSD are open-source, you or anyone interested could create a graphical front-end for ZFS management. This has been discussed before, and a dedicated tool built on ZFS’s native tools might even be better suited than retrofitting GParted.
Use existing ZFS-native tools, such as zfs list, zpool status, and graphical wrappers available that could theoretically be adapted or recreated for BSD environments.

If your interest is more about having any graphical tool for ZFS partitioning rather than GParted specifically, it might be worth exploring or advocating for a BSD-native alternative purpose-built for ZFS.

Let us know which direction you would like to pursue. If others are interested in the same, it might be worth opening a discussion or feature proposal. :-)

grahamperrin

vimanuelt … Initiate or contribute to a port. … you or anyone interested could create a graphical front-end for ZFS management. …

I'm not a developer, and I'm not seeking a graphical utility for ZFS.

vimanuelt

grahamperrin
I suggest asking the maintainer of the application.

grahamperrin

vimanuelt I suggest asking the maintainer of the application.

Asking the maintainer why you describe something as unsafe?

vimanuelt

grahamperrin
Thank you for the clarification.

If you are not seeking a graphical utility for ZFS, and not planning to contribute to a port, then the best available option remains to use tools that are known to handle ZFS safely. While GParted may be able to display ZFS partitions, it does not fully understand the structure or metadata of ZFS datasets. That is what makes interpretation risky, not necessarily in terms of mounting or reading, but in actions that might affect alignment, partition boundaries, or metadata integrity if used beyond display.

Even a healthy status after a move does not guarantee long-term stability, especially if ZFS warnings or performance issues emerge later. This is why upstream tools such as zpool and zfs are still the recommended way to manage pools and datasets.

If there is interest in improving graphical support for ZFS, that would likely need to come from the FreeBSD or GhostBSD community through a native solution that respects ZFS's unique layout and behavior.

Let us keep documenting use cases and limitations. That is still a valuable contribution for others who may be navigating the same space.

vimanuelt

grahamperrin
I understand your concern. My use of the term "unsafe" refers to the general caution expressed by the ZFS community and upstream documentation regarding third-party tools like GParted. These tools do not have native support for ZFS structures, and while they may display partitions, they do not interpret ZFS metadata reliably. This can lead to unintended consequences if users attempt operations beyond viewing.

If you are confident in your specific use case and outcomes, that is your choice. However, when offering guidance in a public forum, I prefer to err on the side of caution for readers who may not have deep familiarity with ZFS internals.

As for the maintainer, I only suggested that route if further clarification is needed about how GParted handles ZFS under the hood. My remarks are based on observed behavior and widely accepted best practices, not on an internal claim from the developer.

Let us try to keep the conversation helpful for others who may be less technically experienced.

grahamperrin

vimanuelt I understand your concern.

With respect: I think not.

For example: if something specific is safe, please do not describe it as unsafe.

vimanuelt

Hopefully, this helps.

ZFS layouts and metadata are complex and fragile under non-native tools

ZFS maintains internal metadata and checksumming that are tightly coupled with block alignment and sector layout. Using third-party partition editors that do not understand these constraints can result in:

Block misalignment
Invalid disk labels
Loss of redundancy or bootability in EFI or mirrored root pools
Silent corruption not immediately visible to tools like zpool status

OpenZFS documentation warns against modifying underlying partitions without using ZFS-native tools:

“ZFS is designed to manage whole disks or partitions given to it. Resizing, moving, or altering those partitions outside of ZFS may result in unpredictable behavior.”

Source:
OpenZFS GitHub Issues and Discussions (e.g., zfs#12262, community mailing list discussions)

In my understanding:
Displaying ZFS partitions is generally safe.
Modifying ZFS partitions with GParted is not recommended and can be unsafe.
ZFS expects complete control of its devices and does not tolerate manipulation outside its tooling.

grahamperrin

vimanuelt ZFS expects complete control of its devices and does not tolerate manipulation outside its tooling.

As expected: all four labels were good following the move of the partition by GParted.

vimanuelt

grahamperrin
openzfs/zfs12262

grahamperrin

vimanuelt what's the relevance to GParted?

GParted is not mentioned in the issue.

zpool-upgrade(8) is not a feature of GParted. No interaction.