Tell us how we could make the product more useful to you.
Goal is to implement the most approachable launcher for local auto-update (scripted auto-update). This way ggRock and it's companion (presumably ggLeap) should be able to update a game, apply writeback and reboot itself. Initial research:
Jonatan RuedaThe goal of this feature is to provide a comprehensive Disk management section, including following features: Introduce RAID 1, 10, 5, 6-like arrays Introduce more interface indication of the Disk's drives contents, size, volume, size occupied Allow users to limit the space used by ggRock to facilitate leaving 10-20% free space for optimal operations at all times Other features to be described
Jonatan RuedaImprove ggRock server stability so diskless PCs can continue starting reliably during repeated boots and extended server uptime. This work addresses intermittent iSCSI target teardown stalls that can prevent new clients from booting. It also improves stalled-operation handling and boot-failure diagnostics, including validation of the writeback safety checks. The changes are in quality assurance for ggRock 1.7.
MVP of Arcade is complete, but the depth of the program is fairly limited. We could continue to iterate with more engaging ideas such as: Player profiles Player history Badges Hall of Fame etc
Jonatan RuedaUser Story: As a player I want to add optional comments to my order So that I can be more specific on my request, like I'm vegan, no mayo, etc... Acceptance Criteria: Scenario 1: Given that I am a player When I place an order Then I see an optional comments field that I can fill with additional notes for the stuff. Figma: @Joshua Specs: NA
Jonatan RuedaAs a Superadmin user, I want to manage both system and game images in the same interface with the ability to filter by image type, So that I can seamlessly upload, view, and allow ggRock centers to import game images in addition to system images. Acceptance Criteria 1. Unified Image Table with Filter The existing System Images table is reused to display both system and game images. A new dropdown filter labeled Image Type is added above the table with options: System Game Selecting a filter updates the table contents accordingly without reloading the page. 2. Enhanced “Add Image” Modal The current “Add System Image” modal is reused with one addition: A new dropdown labeled “Image Type” with the following options: System (default) Game The value selected determines how the image is categorized and shown in the main image table and in the ggRock import list. 3. Updated Import Image Modal in ggRock The current Import Image modal includes three buttons: Windows System (unchanged) Subscription (unchanged) New: Games Image Clicking “Games Image” shows a list of uploaded game images with columns: Name BIOS (optional or N/A) Version Build (optional) Size Update Date The import functionality behaves the same as for system images. 4. Access Control and Validation Only authorized Superadmin users can add/edit game images. Centers can view and import game images but not modify or delete them. All form validations from system image uploads apply to game images. 5. Audit and Logs Actions involving game images (add, edit, delete, import) are included in existing audit logs.
Jonatan RuedaUser Story: As a network administrator using ggRock in an educational environment, I want a graphical boot selection menu using rEFInd so that I can easily choose between multiple boot paths, including network PXE boot, local boot, and EFI shell, for efficient device management and troubleshooting. Acceptance Criteria: Graphical Boot Menu Display: Upon powering on, the system should display the rEFInd graphical boot menu as the first screen. The boot menu should include at least three options: Network PXE boot (default option) Local boot (from internal drive or primary disk) EFI shell for diagnostics and troubleshooting. The menu should display with clear ggRock and University of Chichester branding, including logos for ggRock and ggC. Boot Selection Functionality: Default Boot: If no user selection is made within a configurable timeout period (e.g., 5 seconds), the system should proceed with the Network PXE boot option by default. Local Boot Path: Selecting the local boot option should redirect the system to boot from the internal drive or designated local storage. EFI Shell Access: Selecting the EFI shell option should open the EFI shell interface, allowing administrators to perform diagnostics and troubleshooting. Persistent Configuration: The rEFInd menu configuration should be stored on the ggRock server. Configuration updates should be possible from the server side, allowing modifications without requiring updates on individual clients. Error Handling: If the network PXE boot path fails, the user should receive an error message and be returned to the boot menu. Any failed attempts to load local boot or the EFI shell should return the user to the menu with an error prompt. Compatibility: The rEFInd menu should be compatible with existing ggRock configurations, allowing seamless integration without requiring changes to the ipxe.efi or existing network boot setups. The solution should operate across UEFI-based devices used within the University of Chichester’s infrastructure. Diagnostics and Troubleshooting: The EFI shell should provide access to EFI-based troubleshooting tools, enabling quick diagnostics for boot-related issues. Administrators should be able to add additional EFI executables (e.g., keytool.efi, lockdown.efi) to the boot menu for specific troubleshooting needs.
Jonatan RuedaUser Story: As a system administrator , I want to see which machines are actively using a specific snapshot in ggRock so that I can avoid accidentally deleting a snapshot that is still in use by machines. Acceptance Criteria: Snapshot Management - Machine List Visibility : In the Snapshot Management view, there will be a new column called "Machines Running" which lists all machines currently running a specific snapshot. The list will display the machine names in a comma-separated format (e.g., PC-1, PC-2, PC-33).
Jonatan RuedaAs a system administrator using ggRock in environments where PXE booting is required, I want the system to supply the MAC address as the DHCP client identifier during PXE boot, so that the DHCP server assigns a single IP address for both the PXE booted Linux kernel and the iSCSI-booted Windows OS, preventing resource consumption issues caused by multiple IP leases. Acceptance Criteria: PXE Boot Process : During the PXE boot process, the MAC address of the system must be sent as the DHCP client identifier. iSCSI Boot Process : When booting into the iSCSI-initiated Windows OS, the system should continue using the same IP address assigned during the PXE boot process. DHCP Server Behavior : The DHCP server must only assign one IP address per machine during the entire PXE and iSCSI boot processes. Logging : The system must log both the PXE and iSCSI boot processes, confirming that only one IP address is assigned and no secondary leases are created. Error Handling : If the DHCP server attempts to assign a second IP address, the system should flag the issue and revert to using the MAC-address-based lease. Testing : Successful tests must be conducted in environments where DHCP reservations are not possible to ensure the seamless allocation of a single IP address.
Jonatan RuedaUser Story As a system administrator, I want to use the ENGL Driver Manager for adding new hardware drivers So that the process is automated and aligned with specific machine models and operating systems. Acceptance Criteria Driver Pack Creation: When support for a new hardware platform is required, a driver pack must be created. Integration Task Execution: The Integration task must run successfully, allowing the administrator to select the required machine models and operating systems. Driver Deployment: Once created, the driver pack will need to be stored somewhere so that it may be delivered to the client PC. Driver Installation: Critical INF drivers must be installed using the DriverInstaller.exe during the WinPE phase (we can actually move ahead without it here since dmscanner.exe can just be run from windows installed to the local drive of the computer for example). Post-Windows installation, all INF and software package drivers should be installed using the same tool. (2 runs ~~ once from a VM in localdrives mode to get the “critical” drivers in place ~~ this is the NIC driver ~~ then once again after add hardware is run when we’re actually booted on the real hardware ~~ this installs the graphics driver, sound driver, etc.) Verification and Testing: After driver installation, the system should verify that all devices function correctly with the new drivers without requiring manual intervention. Documentation: Each step in the driver installation process must be documented clearly in the system operations manual. Steps to Add New Drivers Using ENGL Driver Manager Prepare the Driver Pack: Identify the driver needed based on the hardware and OS requirements. Create a driver pack folder structured as <target_path>\DriverManager\Driverpacks\<manufacturer>\<model>\<os>\<platform> . Run the Integration Task: Launch the ENGL Drivers Manager and select the 'Integration Task'. Choose the necessary machine models and operating systems, then proceed through the configuration steps. Deploy the Driver Pack: Copy the driver pack folder to the local drive on the target image. During the before-first-boot-on-real-hardware phase, run DriverInstaller.exe from the driver pack folder to install critical INF drivers while the image is booted to a VM in localdrives mode. Complete the Installation: After Windows installation, run DriverInstaller.exe again to install all remaining INF and software package drivers. Verify Installation: Ensure all drivers are correctly installed and functioning. Document the installation process for future reference and troubleshooting. Saving Snapshot: After the drivers installation a new snapshot should be saved.
Jonatan RuedaI would like to be able to assign 802.1X configurations to managed endpoints, including the provisioning of certificates for client authentication. This would help me dynamically provision the required access controls and prevent unauthorized devices from connecting to my ESports environment.
Jonatan RuedaAs a ggRock administrator managing multiple servers on the same subnet, I want the ggRock Boot toggle functionality to also stop dnasmasq service, So that client PCs connected to the network can boot from the appropriate server without issues. Acceptance Criteria Client PC Boot Behavior: Client PCs configured to boot from the network (PXE boot) should detect and prioritize servers with ggRock Boot enabled (Server A) for booting over servers with ggRock Boot disabled (Server B). Upon booting, client PCs should not attempt to boot from servers where ggRock Boot is disabled, minimizing boot failures. dnsmasq Service Control: If ggRock Boot is disabled on a server (e.g., Server B), the dnsmasq service on that server should automatically stop to prevent client PCs from attempting to boot from it.
Jonatan RuedaAs a system administrator using ggRock, I want the ability to restart TFTP, iSCSI, ZFS, and dnsmasq services from the ggRock General Settings page, So that I can manage and troubleshoot these services without needing to perform a full server reboot or manually restart these services via the command line. Acceptance Criteria Restart TFTP Service Given the user is on the ggRock General Settings page, When the user selects the option to restart the TFTP service, Then the system should execute the necessary commands to restart the TFTP service, And a confirmation message should be displayed indicating the TFTP service has been successfully restarted. Restart iSCSI Service Given the user is on the ggRock General Settings page, When the user selects the option to restart the iSCSI service, Then the system should execute the necessary commands to restart the iSCSI service, And a confirmation message should be displayed indicating the iSCSI service has been successfully restarted. Restart ZFS Service Given the user is on the ggRock General Settings page, When the user selects the option to restart the ZFS service, Then the system should execute the necessary commands to restart the ZFS service, And a confirmation message should be displayed indicating the ZFS service has been successfully restarted. Restart dnsmasq Service Given the user is on the ggRock General Settings page, When the user selects the option to restart the dnsmasq service, Then the system should execute the necessary commands to restart the dnsmasq service, And a confirmation message should be displayed indicating the dnsmasq service has been successfully restarted. General Requirements The interface for restarting these services should be user-friendly and consistent with the existing design of the ggRock General Settings page. Appropriate error messages should be displayed if the restart of any service fails. Logging should be implemented to record each service restart action for audit purposes. Additional Notes Ensure that the addition of these features does not disrupt the current functionality of the ggRock General Settings page. Validate that the new options are correctly integrated with the existing restart service options: Entire server reboot, ggRock service, Nginx, and Networking. Include thorough testing for each new feature to ensure reliability and stability of the system.
Jonatan RuedaProblem Loughborough University reported that PCs following the naming convention GG-xx-DLC101 all display as “101” on the ggLeap dashboard, rather than the individual PC number in the middle. The customer suspects the final numeric group is used; the parsing behavior has not yet been verified. Impact Different PCs receive the same visible label, making them difficult to distinguish. The university worked around this by changing its naming convention. Requested behavior Allow each center to configure which part of the device name is used as its dashboard PC label. For example, GG-01-DLC101 and GG-02-DLC101 should be configurable to display 01 and 02, without renaming the devices. Proposed acceptance criteria A center can select the part of the PC name used for its dashboard label. Labels distinguish individual PCs when names also contain room or location numbers. No device renaming is required. Existing centers retain their current display behavior unless they change the setting. Source Reported by Jacob Pitcher on behalf of Loughborough University (Managed Services), 9 September 2026. Jonatan Rueda confirmed it would be logged as a feature request. https://esportsentertainment.slack.com/archives/C04S3GM4KL4/p1788960289428499
