Elipsa 2E: manual software update fails with “the address or credentials are invalid”

[andreclerigo]

Behavior

Manually attempting a software update from Cobalt Settings > Software update fails with:

the address or credentials are invalid

The screen shows Installed 0.3.1 and a Try again button. The error was directly confirmed from a read-only framebuffer capture on the physical device while it remained accessible over SSH via Wi-Fi.

Steps to reproduce

1. On the Elipsa 2E running Cobalt 0.3.1, open Settings > Software update.
2. Manually attempt the offered software update.
3. Observe the error above instead of a completed update.

The owner reported the manual update failure. During inspection, the device was already displaying the error; no further installation was triggered. The intended target release was not visible in the captured error state, so it is not established here.

Expected

The update should complete, or report a specific actionable reason for failure. If the failure is unrelated to authentication or an address, the UI should not describe it as invalid credentials/address.

Device

• Kobo Elipsa 2E, N605, device code 389
• Kobo firmware 4.38.23697; kernel 4.9.77
• Cobalt installed version shown by the software-update screen: 0.3.1
• HWTCON framebuffer 1404 × 1872, rotation 1
• Wi-Fi available; SSH access remained working during inspection (this does not independently establish internet/release-server connectivity)

Observed logs

The session log records two pairs of completed Settings tasks around the owner's update attempts, followed by another screen render. Relevant excerpt:

task 1 started for settings
task 1 finished for settings: 24775 bytes
task 2 started for settings
task 2 finished for settings: 273 bytes
screen 691836526
...
task 3 started for settings
task 3 finished for settings: 24775 bytes
task 4 started for settings
task 4 finished for settings: 273 bytes
screen 691836526

These entries do not expose the underlying update error or prove successful update retrieval. Root cause is unconfirmed. The displayed wording is the generic DeviceError::InvalidInput message in kobo-protocol, so the wording alone does not establish bad credentials.

Scope/context

This occurred after the temporary rotation testing for #151: the original daemon and application binaries had been restored and byte-verified against backups before this report. Restored daemon SHA-256: 8524c3c248a167678e14e6614cdb9b30f836e0f21d43cbd0757c2c28751f5c84.

Please track this update failure separately from the rotation fix (#89 / #151). Its relationship, if any, to Wi-Fi issues #90/#91 has not been established.

[abhishek-anand]

@andreclerigo Thanks for reporting, this probably happened when we created the beta channel for developers like us to quickly merge and test apps and features on our device. I am currently checking it, though it seems to be fixed on 0.3.9 the latest beta one.

If you can, please update to 0.3.9 manually while I try to debug and fix this. Ideally this should not repeat as we should have only stable and beta channels going forward for updates.

Also, we now have a universal install script for macOS and Linux that I would love feedback on, please feel free to send a PR on it if you find any issues.

curl -fsSL https://bandarlabs.github.io/Cobalt/install.sh | sh

Also, I an trying to use Chrome and Edge's File System API to allow installation of Cobalt and apps directly from the browser. This will open this up for a lot of non-technical users who also use Kobo. The install page for that is https://bandarlabs.github.io/Cobalt/install/ (currently testing).

Also scouting for domain names for the project's Github page, if you have any idea for that which is still available to purchase, let me know!

[andreclerigo]

@abhishek-anand I followed your request and manually installed 0.3.9 on the Elipsa 2E over Wi-Fi. Cobalt launches, Settings shows 0.3.9, and Check for updates now succeeds, reporting that 0.3.9 is the newest published release and is what the reader is running. The release metadata and the device both label this version Stable, so I left it on Stable.

The universal installer worked on macOS arm64: I downloaded/inspected the Pages script and ran it with --version 0.3.9 --yes --non-interactive --no-setup --no-path and a temporary install directory. Signed-manifest verification, host CLI installation and device-package caching all succeeded. I did not test USB setup, Linux, shell-profile modification or the browser installer.

For the device migration I backed up 0.3.1, stopped Cobalt and used the released CLI's deploy --package path. One developer-path gap: deploy omits cobalt-launch.sh and does not migrate the NickelMenu entry. I separately installed that exact verified package member and migrated the managed entry, then verified all 27 release files by SHA-256. Existing owner data/store apps were retained.

A concrete clue for your debugging: the published 0.3.9 archive's first member is the regular file mnt/onboard/.adds/cobalt-launch.sh. The 0.3.1 unpacker only allows files below mnt/onboard/.adds/cobalt/, so it returns InvalidInput on that member, which becomes the credentials/address message. Current source already has the deliberate pre-bootstrap refusal regression test and documents one-time setup migration. This is consistent with my failure; the old device log did not identify the internal failing stage, so I would not infer a credentials problem from the message.

The manual recovery and update-discovery check pass. A subsequent OTA installation and Beta switching remain untested, so I am leaving the issue open for your investigation. I have also submitted PR #162 with recovery guidance and a framebuffer capture, rather than changing the intentional archive safety check.