• second approach

Okay, let’s refactor the provided Buildroot files (create_efi.sh and sbnb_defconfig) to permanently include the nomodeset kernel parameter for the boot process initiated by the custom EFI executable.

The main challenge here is that your create_efi.sh script builds a unified EFI executable and hardcodes the kernel command line within itself. This approach bypasses the standard Buildroot mechanism for setting the kernel command line via BR2_KERNEL_CMDLINE_* options in the configuration, which are typically used by bootloaders like GRUB or Syslinux.

Therefore, to add nomodeset, we must modify the script directly. Changes to the sbnb_defconfig file will primarily involve ensuring other settings (like the initramfs format) are consistent with the script and adding comments for clarity.

1. Refactored board/sbnb/sbnb/scripts/create_efi.sh

This version adds nomodeset to the command line string and includes a note about a potentially unused variable from the original script.

2. Refactored configs/sbnb_defconfig

This version includes comments explaining the implications of the custom script and provides guidance on CPIO and Syslinux settings.

3. Explanation of Changes and Important Considerations:

• create_efi.sh:
  • nomodeset was added to the CMDLINE variable.
  • A check was added to ensure input files exist before objcopy runs.
  • A comment was added regarding the INITRD variable path – you must verify if your script needs a compressed (e.g., .xz) or uncompressed CPIO file and adjust the INITRD variable in the script and the CPIO settings in the defconfig accordingly.
  • A note was added about the splash_offs variable, which seems calculated but unused in the objcopy command of the original script. You may want to investigate this.
  • The rm command ensures the temporary command line file is deleted.
  • The mv command ensures the final sbnb.efi is placed in output/images/.
• sbnb_defconfig:
  • CPIO Configuration: This is the most critical part to verify. The configuration is set up assuming the script needs an uncompressed CPIO named rootfs-sbnb.cpio, based on the script’s INITRD variable. If your original BR2_TARGET_ROOTFS_CPIO_XZ=y setting was intentional and the script should use a compressed initrd, you need to:
    1. Change INITRD in the script (e.g., INITRD="${BINARIES_DIR}/rootfs-sbnb.cpio.xz").
    2. Change the defconfig back to BR2_TARGET_ROOTFS_CPIO_XZ=y (and comment out BR2_TARGET_ROOTFS_CPIO_NONE=y).
    3. Ensure BR2_TARGET_ROOTFS_CPIO_FILENAME results in the correct name if needed (it might default correctly if compression is enabled).
  • Kernel Command Line: Comments explicitly state that BR2_KERNEL_CMDLINE_* options are ignored by the script but are relevant for Syslinux. You need to decide:
    • If Syslinux is used: Configure BR2_KERNEL_CMDLINE_* appropriately for it.
    • If Syslinux is NOT used: Consider disabling BR2_TARGET_SYSLINUX* options to avoid confusion.
  • Comments: Added comments to explain the hardcoded command line, the CPIO verification need, and the Syslinux interaction.

4. Next Steps:

1. Verify CPIO Requirement: Determine the exact initramfs file (compressed or uncompressed, exact name) that create_efi.sh is intended to embed.
2. Apply Changes: Replace your existing files with these refactored versions, making sure the CPIO settings in both the script (INITRD variable) and the defconfig (BR2_TARGET_ROOTFS_CPIO_*) are consistent with your verified requirement. Adjust Syslinux settings as needed.
3. Rebuild: Navigate to your Buildroot top-level directory and run make. This will rebuild the necessary components and execute the post-image script.
4. Deploy: Use the updated output/images/sbnb.efi file to boot your GMKtec G5.
5. Verify: After booting, log in and run cat /proc/cmdline to confirm that nomodeset is present in the kernel command line arguments.

5. Further Considerations / Alternatives:

• Reading Command Line from Buildroot: Instead of hardcoding the command line in create_efi.sh, a more robust approach would be to modify the script to read the command line configured via Buildroot’s BR2_KERNEL_CMDLINE_* options. This could involve reading the generated bootloader config file (like syslinux.cfg) or having Buildroot write the command line to a temporary file that the script reads. This makes configuration more centralized but requires more significant script changes.
• Script Robustness: The provided create_efi.sh could benefit from more robust error checking (e.g., verifying objcopy success).

By applying these changes and carefully verifying the CPIO configuration, you should successfully embed the nomodeset parameter into your custom EFI boot process.

---

#second approach

Okay, let’s refine the approach for adding the nomodeset kernel parameter to your Buildroot OS image, specifically addressing the interaction between your sbnb_defconfig and the custom create_efi.sh script.

Understanding the Context

Your setup uses a custom post-image script (board/sbnb/sbnb/scripts/create_efi.sh) to generate a unified EFI executable (sbnb.efi). The critical point is that, in its original form, this script hardcodes the kernel command line arguments within the script itself. This bypasses Buildroot’s standard mechanism for managing kernel parameters via the BR2_CMDLINE variable (or older BR2_KERNEL_CMDLINE_* options) in the configuration (defconfig).

Therefore, simply setting BR2_CMDLINE in your sbnb_defconfig will not affect the sbnb.efi file generated by the original script.

We need to modify the system so that nomodeset is included in the command line embedded within sbnb.efi. There are two main ways to achieve this:

1. Solution A (Quick Fix): Modify the script to include nomodeset in its hardcoded command line string. This is simpler but less maintainable.
2. Solution B (Recommended): Modify the script to read the command line from the Buildroot environment variable BR2_CMDLINE and define BR2_CMDLINE in your sbnb_defconfig. This aligns with standard Buildroot practices and centralizes configuration.

We will also ensure the Buildroot configuration correctly generates the CPIO root filesystem expected by the script.

Rationale Recap: The nomodeset parameter is being added as a troubleshooting step. It tells the kernel not to load video drivers and attempt display mode changes during initialization. This can prevent hangs or slowdowns caused by graphics driver issues on certain hardware, like the slow console output you observed.

---

Solution A: Modify Hardcoded Command Line in Script (Quick Fix)

This approach directly edits the CMDLINE variable within create_efi.sh.

1. Modify board/sbnb/sbnb/scripts/create_efi.sh:

• Change: Added nomodeset to the end of the CMDLINE variable string.
• Added: Cleanup for the temporary file (rm -f "${CMDLINE_TMP}").
• Added: mv "${OUTPUT}" "${BINARIES_DIR}/" to place the final artifact in the correct Buildroot output directory (output/images). Buildroot provides BINARIES_DIR in the environment when running post-image scripts.

2. Modify configs/sbnb_defconfig (CPIO Settings & Comments):

Ensure the CPIO settings match what the script expects (rootfs-sbnb.cpio, likely uncompressed). Add comments clarifying the hardcoded nature.

• Changes: Added comments about the hardcoded command line. Explicitly set BR2_TARGET_ROOTFS_CPIO_NONE=y and BR2_TARGET_ROOTFS_CPIO_FILENAME="rootfs-sbnb.cpio" to ensure the correct, uncompressed CPIO file is generated for the script. Removed BR2_LINUX_KERNEL_GZIP=y as the script uses bzImage, implying bzip2 compression (which is the default for x86/x86_64 bzImage anyway, Buildroot handles this).

Drawbacks of Solution A:

• Kernel command line configuration is hidden within a script, not in the central Buildroot configuration.
• Harder to maintain and modify parameters later.

---

Solution B: Integrate Script with Buildroot BR2_CMDLINE (Recommended)

This approach modifies the script to use the standard BR2_CMDLINE variable defined in the defconfig. This is the preferred method for better integration and maintainability.

1. Modify board/sbnb/sbnb/scripts/create_efi.sh:

• Change: Replaced the hardcoded CMDLINE variable with CMDLINE="${BR2_CMDLINE:?...}". This reads the command line string from the BR2_CMDLINE environment variable, which Buildroot sets based on the defconfig. The :?Error... part ensures the script fails if BR2_CMDLINE isn’t properly set in the configuration, preventing silent errors.
• Added: Cleanup and mv command as in Solution A.

2. Modify configs/sbnb_defconfig:

Define BR2_CMDLINE with all required parameters, including nomodeset. Also ensure CPIO settings are correct.

• Changes: Added the BR2_CMDLINE definition containing the full command string including nomodeset. Adjusted comments. Ensured CPIO settings are correct (same as Solution A). Removed BR2_LINUX_KERNEL_GZIP=y (same reason as Solution A).

Benefits of Solution B:

• Centralizes kernel command line configuration in the standard Buildroot defconfig.
• Easier to manage and modify parameters using make menuconfig (under Kernel -> Kernel command line string).
• Aligns with standard Buildroot practices.

---

Next Steps (Apply either Solution A or B):

1. Apply Changes: Replace the content of your existing board/sbnb/sbnb/scripts/create_efi.sh and configs/sbnb_defconfig with the versions from your chosen solution (Solution B is recommended).
2. Rebuild: Navigate to your Buildroot top-level directory in the terminal and run:
   make

   Buildroot will rebuild the necessary components and execute the post-image script, generating a new output/images/sbnb.efi.

3. Deploy: Copy the updated output/images/sbnb.efi to your target system’s EFI System Partition (ESP).
4. Boot: Boot your GMKtec G5 from the updated EFI file.
5. Verify: Once the system has booted (even if slowly), log in to a console and run the following command to check if nomodeset was actually passed to the kernel:
   cat /proc/cmdline

   Look for nomodeset within the output string.

Long-Term Alternative:

While outside the scope of simply adding nomodeset, you might eventually consider whether the custom create_efi.sh script is strictly necessary. Buildroot has built-in support for generating bootable images using standard bootloaders like GRUB2 or syslinux, which handle kernel parameters through their own configuration files managed by Buildroot based on BR2_CMDLINE. Migrating to a standard bootloader setup could simplify your build process further, but would require more significant changes.