Hello all....
Loading up the latest GhostBSD 25.01-R14.2p1 on a Late Intel 2012 Mac Mini, it runs with no issues on the live session, and installs perfectly too.
On booting from the harddrive (external ssd) it goes no further than the GhostBSD logo.
Booting via Single User shows the error in the screenshot.

FreeBSD 14.2 installs and boot with no issues and that's including desktop etc...

    To suggest a new feature, please submit a feature request at ghostbsd/issuesissues/new?assignees=&labels=feature&template=feature_request.yaml. Thanks in advance.

    N.B. The feature request will take some time to complete, as it involves updates to ghostbsd-build, gbi, and pc-sysinstall. As da devices are assigned dynamically, we will need to implement glabel support to ensure persistent, static device naming across reboots. However, ongoing work to remove legacy code from pc-sysinstall will delay progress on this task.

    vimanuelt
    Thank you for the link & download.
    Unfortunately it didn't progress further.

      Forget to say that this was the install USB and not installed on the SSD.

        6 days later

        ericbsd No... it's weird as the live desktop session works perfectly, but once installed it gets stuck at the GhostBSD splash screen....

        It's no biggie, and considering the niche hardware I was installing on not being a PC, I don't want to waste anyone's time....but it would have been nice.

            RoboNuggie

            The USB connected external drive may be the issue more than the hardware.

            Any interest in opening up the MacMini and swapping the harddrive to allow you to install directly to a system attached drive? or was that the year they started soldering the drives to the mainboard?

            I have a Late 2011 MacMini as my garage PC, that is about ready to move over to GhostBSD.. Chrome is EOL, Firefox still works, but...

            Ultimately, installing to external hard drives is an edge case in the GhostBSD world that is community explored, experimented, and not thoroughly documented.

            One more experiment before opening that MacMini is to:

            • boot the livecd all the way to desktop
            • remove livecd usb
            • attach usb harddrive
            • start livecd installer, use custom install to select da0 external harddrive

            The most common issue is that if the livecd usb is connected as da0, when attaching another usb device (external hd) becomes da1. The system is installed and write boot information referencing da1. Then when the system reboots and only has the external hd attached, it's identified as da0 while it's boot information has been written to reference da1!

            This occurs due to incremental numbering of usb attached devices. By removing the livecd usb, da0 becomes available for the external harddrive. Assuming the equipment only has the usb harddrive attached, the boot information (now written for da0) will match the drive and things will work.

            Definitely not a waste. I personally feel like older Mac hardware is a potentially huge market to be explored/adopted/supported. 🙂

              I followed your excellent suggestion, but no joy... and after some hassle, swapped the HDD - but still sticks at the splash screen.
              Thank you for your help regardless, and the da0 / da1 issue wasn't a thing I thought was a thing.... I learn something everyday :-)

              What Happened Here?

              • Problem:
                On a Late 2012 Intel Mac Mini, GhostBSD installed to an external USB SSD won't boot as it gets stuck at the splash screen.

              • Why?
                Because during install, the external SSD was seen as /dev/da1, but after reboot, it became /dev/da0.
                The system's boot information (ZFS, loader configs, etc.) expects da1, but now the real device is da0.
                This mismatch breaks the boot.

              • Live USB was /dev/da0, external SSD was /dev/da1.
                After unplugging the USB stick (livecd), the SSD becomes /dev/da0, confusing the bootloader and kernel.


              The Real Root Cause

              GhostBSD currently does not use glabels or disk IDs reliably in its installer (gbi and pc-sysinstall),
              so everything binds to dynamic device names like /dev/da0, /dev/da1, etc., which can change between boots.

              In contrast, FreeBSD installs use gptid/xxxx-xxxx labels or ZFS pool names, making them immune to this problem.

              Solution (Future direction)

              Vimanuelt in the forum reply said:

              "we will need to implement glabel support to ensure persistent, static device naming across reboots."

              Meaning:

              • Use permanent disk labels (glabel) or UUIDs (gptid) during install.

              • So even if a disk goes from /dev/da1 âž” /dev/da0, the system still finds it based on label, not device number.

              SUGGESTED: Permanent Fix for GhostBSD Install Stack

              1. pc-sysinstall (Installer Backend)

              • After partitioning, create labels: gpart modify -i $PARTNUM -l ghostbsdroot $DISK

              • When writing /etc/fstab, use: /dev/gpt/ghostbsdroot

              • When writing /boot/loader.conf, set: vfs.root.mountfrom="ufs:/dev/gpt/ghostbsdroot"

              • Add boot delay to loader.conf for USB drives: kern.cam.boot_delay="5000"


              2. gbi (Graphical Installer)

              • Detect GPT labels and display them in device selection.

              • Pass /dev/gpt/<label> or /dev/gptid/<uuid> to the backend, not /dev/da*.

              3. ghostbsd-build (ISO Builder)

              • Auto-import ZFS pools by name, not device node:
                zpool import -aN
                zfs mount -a

              Results:

              BEFORE device names (/dev/da0); AFTER persistent labels (/dev/gpt/ghostbsdroot)
              BEFORE boot breaks on device reorder; AFTER boot succeeds consistently
              BEFORE manual rescue needed; AFTER no rescue needed

              Summary:

              GhostBSD needs to replace all device-node assumptions (/dev/da*) with GPT labels or GPTIDs during install, configuration, and boot setup to make installs stable across reboots and hardware changes.

                vimanuelt It is probably worth implementing something like that. The only part that might not work correctly is vfs.root.mountfrom="ufs:/dev/gpt/ghostbsdroot" in /boot/loader.conf.

                  Good catch. Thanks. From what I'm seeing, I think this might be the correct cases for FreeBSD and GhostBSD.

                  (1) For UFS root: use /dev/gptid/<uuid> in vfs.root.mountfrom.
                  (2) For ZFS root: use zfs:<pool>/<dataset>.
                  (3) Do not use /dev/gpt/<label> in loader.conf as it's unreliable at early boot.

                  Note: I only mention FreeBSD and UFS as I am certain someone would ask. :-)

                  Proposal: Implement Enhanced ZFS Boot Environment Handling in GhostBSD Installer

                  1. Update pc-sysinstall to enhance the set up ZFS boot environments
                  Repository: https://github.com/ghostbsd/pc-sysinstall

                  A. Modify src/pc-sysinstall/backend/functions-zfsrestore.sh to:

                  1. Create the root dataset as zroot/ROOT/<bootenv> instead of using zroot directly.

                  2. Set the ZFS pool's boot dataset explicitly: zpool set bootfs=zroot/ROOT/<bootenv> zroot

                  3. Prevent accidental mounting of the top-level dataset by marking it with: zfs set mountpoint=legacy zroot


                  B. Modify src/pc-sysinstall/backend/functions-boot.sh to:

                  1. Stop hardcoding values like: vfs.root.mountfrom="zfs:zroot/ROOT/default"

                  2. Instead, dynamically insert the correct dataset using: vfs.root.mountfrom="zfs:$(zpool get -H -o value bootfs zroot)"

                  3. This ensures that the bootloader always targets the correct ZFS root dataset, even when using snapshot-based or versioned boot environments.


                  2. Ensure gbi integrates properly with ZFS layout
                  Repository: https://github.com/ghostbsd/gbi

                  A. Modify src/gbi/zfsinstall.py to:

                  1. Create the system root inside zroot/ROOT/<bootenv> following ZFS best practices.

                  2. Set zroot to mountpoint=legacy to avoid conflict with the actual root mount.

                  3. Pass the full path of the boot dataset (e.g., zroot/ROOT/25.01-2025-04) to pc-sysinstall, so it can be correctly configured in the loader and bootfs.


                  3. Summary of required changes

                  A. The installer must always configure zroot with mountpoint=legacy
                  This prevents it from interfering with the boot environment mounted at /.

                  B. The boot environment must be created in zroot/ROOT/<bootenv>
                  This layout supports snapshotting, boot environments, and versioned rollbacks.

                  C. The bootfs property must be set and referenced in /boot/loader.conf
                  Avoids hardcoding assumptions and ensures correct dataset is used at boot time.

                  D. The graphical installer (gbi) must reflect and enforce this structure
                  Dataset naming and boot configuration must be consistent across frontend and backend.


                    I can add the suggestion as a feature request if it makes sense to proceed.

                    vimanuelt Instead, dynamically insert the correct dataset using: vfs.root.mountfrom="zfs:$(zpool get -H -o value bootfs zroot)"

                    That could work, but I am not 100% sure.

                      I can try to see if it works. Fell free to fill a ticket.