Keyboard issue on boot

MNT Pocket Reform
14

Josch, I’m sorry for the confusion and for starting a new thread.

Thank you, josch and G3M, for your responses and questions. I appreciate the insights and suggestions.

To provide more precise details and address the points raised:

  • Update process: I performed a standard package upgrade using sudo apt update && sudo apt full-upgrade. I did not execute reform-flash-uboot at any point, and U-Boot was not explicitly upgraded during this process. I am using the official MNT repositories.

  • Setup screen clarification: Upon further reflection, the screen I reach when booting from the latest official image is a CLI login prompt (or possibly a rescue/emergency shell), not the expected MNT Reform Setup Wizard (GUI). My earlier description mentioning an “adduser prompt” was inaccurate; it was likely a misremembered fallback shell due to no input being possible.

    When I booted from an older image (approximately April 28, 2025), the MNT Reform Setup Wizard (GUI) displayed correctly, and the keyboard functioned normally during setup.

  • Behavior with the latest image on microSD: I used the following file for flashing:

URL:

FILE:
pocket-reform-system-a311d.img (size: 11,265,901,056 bytes ? 10.5 GB, from my local copy dated Jan 17).

However, when booted from this microSD, the system reaches a CLI prompt instead of launching the Setup Wizard. This is unexpected because a fresh official system image should trigger the GUI Setup Wizard on first boot.

The most likely cause is an incomplete or corrupted flash/write process during dd (e.g., possible issues with decompression if it was originally a .gz file, insufficient sync/eject commands, SD card errors, or write verification failure). This could result in a damaged root filesystem, causing the init process to fail and drop to a CLI fallback/resque mode instead of proceeding to the graphical wizard.

The fact that I had not run reform-flash-uboot is not the direct cause of this CLI fallback, as the official SD image should contain an up-to-date U-Boot. However, in the context of my previous eMMC setup (which was not recently updated), it may have contributed to overall firmware inconsistencies.

  • Temporary resolution with older image: Since my primary system had not been updated since around April 2025, the older microSD image likely used a U-Boot version that predates the known USB hub reset regression (reportedly fixed in U-Boot updates around May 2025). This avoided the keyboard input issue during setup. After applying recent package updates, the problem reappeared, consistent with the bug description.

  • Kernel versions: Unfortunately, exact previous logs are no longer available, but prior to the update, the system was almost certainly on an older kernel from the 5.x series (likely 5.15 or similar, based on early 2025 builds).

  • Boot setup: My main installation was previously flashed to the eMMC (including its U-Boot), but for recovery and testing, I am now booting exclusively from microSD, where the A311D module prioritizes the U-Boot from the SD card.

Next steps I plan to take:

  • Retry flashing the latest official image, ensuring proper decompression (if .gz), verifying file size/checksum if available, using dd with careful sync/eject, or alternatively using a tool like balenaEtcher for safer writing.

  • Proceed with UART serial console using my 3.3V USB-serial adapter. I will attempt to capture boot logs to identify where the failure occurs (e.g., rootfs mount issues or U-Boot USB init).

  • Test the hardware suggestions from josch (checking/reseating USB connection cables between keyboard and mainboard, trying “Reset USB” from the OLED menu).

josch: Thank you for the hardware troubleshooting advice regarding cables and the OLED USB reset.

G3M: If you have encountered a similar CLI fallback when booting fresh images, or have details on your kernel/U-Boot versions, that would be very helpful for comparison.

Thank you again for your assistance.