GBase Database(GBase 8c) Pre-Installation Troubleshooting: A Field Guide to 18 Checks

When deploying GBase Database(GBase 8c), the output of gha_preinstall -i A classifies environment checks into three states: Normal, Warning, and Abnormal.

Warnings do not block installation, while Abnormal results prevent the deployment process from proceeding.

Knowing what each check means is only half the job. The real challenge is identifying where to fix the problem, which changes require a reboot, and how to verify that the environment is ready afterward.

This field guide covers common GBase Database pre-installation failures, their causes, and practical troubleshooting steps.

1. Common GBase Database Pre-Installation Abnormal Checks

The following table summarizes frequently encountered issues during GBase Database(GBase 8c) deployment.

Check	Common cause	Troubleshooting approach
A5 Swap	Cloud images enable swap by default	Run swapoff -a and update /etc/fstab
A7 System limits	ulimit -n remains at 1024	Adjust /etc/security/limits.conf or systemd limits
A10 I/O scheduler	Virtualization defaults to mq-deadline	Configure the data disk scheduler according to deployment requirements
A13 Firewall	firewalld is active	Apply the approved firewall configuration or use -i B where supported
A14 THP	Transparent Huge Pages set to always	Configure THP as never and apply the change
A15 SELinux	SELinux is in enforcing mode	Apply the required SELinux configuration
A16 Dependencies	Missing libraries such as libaio or numactl	Install the required OS packages
A17 Sudo	The gbase user lacks required passwordless sudo permissions	Configure the approved sudo policy using visudo
A18 Command permissions	Incorrect ownership, permissions, or leftover installation directories	Correct ownership and verify installation directory state

These are common field scenarios rather than an exhaustive list of every possible failure.

2. Start With System-Level Configuration: A5, A7, A10, and A14

System-level configuration issues are best addressed first because they can affect multiple database components.

A5: Swap Configuration

Some cloud images enable swap automatically.

Check the current configuration:

swapon --show

If the deployment requirements specify that swap must be disabled:

swapoff -a

Then inspect /etc/fstab and comment out the corresponding swap entry to prevent it from being re-enabled after reboot.

Disabling swap changes system memory behavior, so record the change in the deployment documentation.

A7: System Resource Limits

A common issue is an insufficient open-file limit:

ulimit -n
ulimit -u

If the values do not meet the deployment requirements, review the applicable limits in:

/etc/security/limits.conf

Also check systemd service limits if the database processes are launched through systemd.

Do not assume that changing limits.conf automatically changes the limits of an already-running service. Verify the effective limits in the actual execution context.

A10: I/O Scheduler

Virtualized environments may use a different I/O scheduler from the one expected by the deployment specification.

Check the scheduler:

cat /sys/block/sda/queue/scheduler

The available schedulers depend on the kernel and device configuration.

If the deployment requires deadline, verify that the scheduler is available and configure the correct data device accordingly. Make the setting persistent using the appropriate OS mechanism.

Do not assume that every virtual disk is named /dev/sda.

A14: Transparent Huge Pages

THP is another frequent source of pre-installation failures.

Check its current state:

cat /sys/kernel/mm/transparent_hugepage/enabled

If the deployment specification requires THP to be disabled, configure it as never and make the change persistent.

Depending on the operating system, this may require a boot parameter, system service, or reboot.

A5 and A14 deserve special attention: both are easy to fix temporarily but easy to reintroduce when replacing or rebuilding a host.

3. Handle Security Configuration: A13 and A15

Two security-related checks can be handled by the supported automatic environment adjustment stage.

A13: Firewall

Check the firewall state:

systemctl is-active firewalld

If the deployment procedure permits the use of -i B, the supported firewall adjustment can be performed through the official tool.

Alternatively, coordinate with the security and network teams to implement the approved firewall policy.

Do not disable firewall protection without confirming the deployment requirements and security approval.

A15: SELinux

Check the current SELinux status:

getenforce

If the deployment specification requires SELinux to be disabled, apply the approved configuration.

The persistent configuration is generally managed through:

/etc/selinux/config

A reboot may be necessary for the persistent setting to take effect.

Important: -i B only covers the supported automatic adjustments, including firewall and SELinux operations (B1 and B2). It does not repair all 18 checks.

Seeing two Normal results after running -i B does not mean the entire GBase Database environment is ready.

4. Resolve Dependencies, Sudo, and Directory Permissions: A16 to A18

After system and security configuration, move on to software dependencies and installation permissions.

A16: Dependency Packages

Missing system libraries can prevent installation or execution.

Common examples include:

• libaio
• numactl

Check installed packages using the operating system's package manager and install the dependencies required by the corresponding GBase Database version.

For example, on compatible RPM-based systems:

rpm -qa | grep -E 'libaio|numactl'

Package names and dependencies may differ across operating system versions.

A17: Sudo Permissions

The deployment user may lack the required passwordless sudo permissions.

Review the sudo configuration:

visudo

A commonly used configuration example is:

gbase ALL=(ALL) NOPASSWD:ALL

Apply this only when it matches the deployment security policy. In production environments, use the least privilege configuration supported by the installation procedure.

A18: Command Permissions and Installation Directories

A18 failures are frequently associated with incorrect ownership or leftover files from previous installations.

A reliable troubleshooting sequence is:

1. Stop related database processes.
2. Identify leftover installation directories.
3. Remove obsolete files only after confirming they are no longer needed.
4. Verify the configured prefix directory meets the installation requirements, including whether it must be empty.
5. Correct ownership and permissions.
6. Run the check again.

For example:

chown -R gbase:gbase /home/gbase/gbase_db

Use the actual configured installation paths rather than blindly applying recursive ownership changes to unrelated directories.

5. Do Not Overlook Network and Time Synchronization: A11 and A12

Not every pre-installation failure is caused by operating system settings.

A11 and A12 often point to network planning or time synchronization problems.

A11: Network interfaces

In dual-NIC environments, check whether host and agent_host in gbase.yml are assigned according to the intended network design.

Typically:

• host identifies the data-plane address.
• agent_host identifies the control-plane address.

An incorrect mapping can prevent the nodes from communicating through the expected interfaces.

A12: Time synchronization

Check whether all nodes use a consistent time source.

Depending on the environment, review NTP or chrony configuration and verify synchronization status.

For chrony:

chronyc tracking
chronyc sources -v

A consistent time synchronization configuration is important for reliable cluster operations.

6. Follow a Consistent Troubleshooting Order

When multiple GBase Database pre-installation checks fail, fixing them in a structured order is more efficient than jumping between unrelated issues.

A practical sequence is:

Order	Checks	Focus
1	A5, A7, A10, A14	System configuration
2	A13, A15	Security configuration
3	A16, A17, A18	Dependencies and permissions
4	A11, A12	Network and time synchronization

The exact order can be adjusted based on dependencies and the actual failure report.

After applying corrections, rerun the official check:

./gha_preinstall -i A -f /home/gbase/gbase.yml

Do not proceed directly to installation after making configuration changes.

Some changes require a service reload or system reboot. Rechecking confirms that the intended configuration has actually taken effect and that no new issues have appeared.

Archive the final -i A output as the environment baseline.

Keep Warning results in the record too. Although warnings do not block installation, they can indicate configuration differences worth reviewing before production deployment.

7. Turn Troubleshooting Results Into a Delivery Checklist

The biggest benefit of documenting these GBase Database pre-installation issues is not simply fixing the current deployment.

It is making the next deployment more predictable.

A useful delivery record should include:

• Original gha_preinstall -i A output.
• Abnormal items and their root causes.
• Configuration changes applied to each host.
• Any required service reloads or reboots.
• Final validation output.
• Remaining Warning items and their explanations.

The official 18 checks provide a consistent validation baseline. A repeatable troubleshooting process turns that baseline into an operational practice.

GBase Database deployment becomes more reliable when every Abnormal result has an identified cause, a documented correction, and a verified final state.