All was going well and everything was happening exactly like expected in the instructions. I was at the point of running ./flash.sh and even that output looked pretty much exactly like on the screen, right down to finishing up with
...
finished. total time: 3.558s
rebooting...
finished. total time: 0.005s
However, after the reboot:
At this point, run sudo dmesg |tail to check for the following output:
[ 1033.836166] option 1-1.3:1.2: GSM modem (1-port) converter detected
[ 1033.836636] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
[ 1033.837179] option 1-1.3:1.3: GSM modem (1-port) converter detected
[ 1033.837597] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
[ 1033.838125] option 1-1.3:1.4: GSM modem (1-port) converter detected
[ 1033.838575] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
[ 1033.839506] option 1-1.3:1.5: GSM modem (1-port) converter detected
[ 1033.840027] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
[ 1033.840560] option 1-1.3:1.6: GSM modem (1-port) converter detected
[ 1033.840949] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
If you see this output, it means that the firmware has been successfully flashed and the module is not bricked.
The problem is that I did not see that output. I also got no output from sudo dmesg | grep 'GSM' and I can no longer find any evidence that the device exists. So it looks like even though everything was going along swimmingly, the attempt to update the firmware somehow bricked my 4G Modem.
WTF do I do now? Is there a way to recover from this? What the hell happened?
Any assistance is very much so appreciated. I just got my uConsole yesterday after a 11 month wait, and this sucks.
Maybe dmesg isn’t the most reliable way to confirm this… try lsusb or ls /sys/bus/usb/1-1.3/ possibly to see if the device is still attached to the bus or not
I had already tried both of your suggestions, which is what I meant when I said there was no longer any evidence the device exists. All indications are that it is no longer there.
âžś drivers lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 1eaf:0024 Leaflabs uConsole
I don’t have the 4G modem so in its absence I have 3 USB devices, do you have the same list of devices?
EDIT-- reason I ask is the device seems to work similarly to other qualcomm platforms where the USB device can function as a serial TTY for DFU and as a modem (even uses fastboot to switch to DFU)
This is just a guess but maybe what’s happened is your device switched to DFU/Download mode (where it will wait until its power cycled) and the firmware update never completed because you didn’t have permissions for the device node (possibly /dev/ttyUSB0.) Qualcomm is typically pretty good about flashes and the only risk here is that it just didn’t follow through and it never reset from download mode back to it’s normal operational mode–should be a piece of cake to fix that but I’ll have to see what you have on the USB bus before I can give you a more definitive assessment
each block should have had a description; the log you provided just says:
...
finished. total time: 3.558s
rebooting...
finished. total time: 0.005s
are those the first two messages that it actually printed out? Because based on the documentation at least it should have provided a name for the chunk it was writing and it might be helpful to understand, at what point it stopped writing the chunks, try to also gather some version information about the toolchain you used in particular as well as the flash version.
In fact if you look at flash.sh, the script literally just uses the fastboot utility which should be familiar if you’ve ever done any Android hacking:
I would say you can run the command directly fastboot/bin/fastboot -l and perhaps gather some information about it but it seems like you’re not even seeing it connected to the USB bus so I’m not sure that will do you any good. In any case it would be interesting to know at which point the script failed and this script doesn’t even have a hashbang for the interpreter #!/usr/bin/env bash and for a script like this it should probably also have set -e to ensure that the first command that fails causes the whole script to stop executing. That said, even if this is somehow your fault (which I don’t believe it is) this script for flashing the modem should be revisited by whoever wrote it.
I wouldn’t call that recommendation as an “upgrade”. You should only replace the preloaded firmware if you are absolutely sure you are not able to connect to the network with the firmware. Replacing runs the risk of losing certain features.
I own a 4G module myself. I didn’t bother with replacing because the firmware out of the box already serves me well.
For another note, you need to give the module about 30 seconds to respond. At least that’s how mine worked.
Yes, it came with an SD Card, the included card is what I am using, with the image that came on the card.
If I cat out the /etc/os-release file it says that it is Debian GNU/Linux 11 (bullseye). So it is the official image, unmodified, as it came pre-flashed on the included card.
I took it as a recommendation based on the following:
Wi-Fi stopped working after the first update and I had to turn off NetworkManager and enable DHCP to get it to function again.
This page https://github.com/clockworkpi/uConsole/blob/master/wiki/How-to-use-the-4G-extension.md stated under the “Connect to 4G network” section - “Create 4g net connection and bring it up” via sudo nmcli c add type gsm ifname ttyUSB2 con-name 4gnet apn [yourapn] gsm.username [gsmusername] gsm.password [gsmpassword] which as a Mint Mobile user I did as sudo nmcli c add type gsm ifname ttyUSB2 con-name 4gnet apn Wholesale but I got an error that NetworkManager was not running (See the first point)
Being now stuck I remember seeing that the extension allowed it to just work, without needing NetworkManger or even to manually create the connection. I can’t remember if it that was a forum post or what as I had several tabs open at this point, but I saw it multiple times and got to https://github.com/clockworkpi/uConsole/blob/master/wiki/How-to-upgrade-4G-extension-firmware.md by clicking a link. The fact the the extension update page on the Github Wiki, and the How to use 4G page on the same Github Wiki were adjacent tabs with the extension update to the immediate right of the How To is probably why I assumed the link I clicked was in the How To page. Regardless, I found more than one post on the net that basically stated to upgrade the firmware and extension in order to get the 4G connection working, at least 2 of those where on these forums.
In fact the How To Upgrade page proceeds the How to Use page in the Wiki navigation (although in hind sight they could just be in alphabetical order)
I know that the flash.sh script is not going to work for me now as among the various ways the device no longer exists is that sudo ./fastboot/bin/fastboot devices returns nothing.
the script literally just uses the fastboot utility which should be familiar if you’ve ever done any Android hacking:
I have not done any Android hacking and I am not familiar with fastboot. While Android technically uses a Linux kernel, I am not that kind of a Linux Sysadmin. That is why I wanted one of these devices and not an Android tablet for my use case. I must admit that the line that stated “and the module is not bricked” was a bit ominous, but I figured that is the chances were better than minuscule that could actually happen, there would have been some type of warning to that affect and next steps if it did happen, and maybe a warning it was not fixable if that was the case.
Just a friendly advice. Frankly, you shouldn’t ever update the official image unless you’re prepared to jump down the rabbit hole of frustration. The image becomes a blazing royal dumpster fire of glitches, bugs, and incompatibilities. Since you’re quite experienced with Linux, you should consider moving to any one of the community images. Try searching for the following in the forums:
I’d like to echo what @mterencelao said. This is true for all ClockworkPi devices, by the way, including the Gameshell and Devterm. The official OS image is a good way to power on the hardware, and make sure most everything works (although in some cases that’s not even true), but it’s not really “supported” and never tested for upgrades, etc. In fact, I believe it’s still true that using official images for any of these devices (and I guess the uConsole too) and then upgrading will either make the device unusable, or break critical features. While it’s possible for someone to try to figure out and fix the problems themselves, or go digging in the forums as an archaeologist to try to piece together people’s work toward a solution, it seems rather silly since community OS builds which are more recent and are usually maintained (at the very least available in github so the are documented and can be fixed later by others if need be) are available. Unfortunately information about all of this tends to be scattered across the forums here (and buried over time), and perhaps mentioned on the discord. The official documentation never really gets updated for these devices either, and sometimes has mistakes or missing parts.
While I personally like the hardware ClockworkPi creates, their software is not useful long term, and should only really be used as an initial test. All of these devices are meant to be hobby projects for people anyway, with the expectation that you might be rolling your own OS, etc. But we’re lucky that there are people in the community who debug problems, fix driver issues, and create stable, more reliable OS versions to run on these devices. This almost always requires including the specific hardware drivers in real, maintained OS builds, and perhaps replacing some of the weird scripts and other configuration hacks that were in place in the official image to do a similar thing in the way the target OS expects, and that won’t break on each new revision of the OS.
Since you’re quite experienced with Linux, you should consider moving to any one of the community images.
This was my plan, once I was sure 4G was working properly. I had not yet decided which one though. I would probably rule out Parrot and Kali as I am not really looking for a Sec based install, and RetroPie as I am not looking to game on the device. However, postmarketOS is an interesting option as it would allow me to brush up my Alpine Linux skills and stretch my comfort zone by using the alternatives in init system, doas rather than sudo, a different package manager, etc.
Do you have any suggestions? I will be primary in the terminal using SSH, and in Firefox or Chrome using WebUIs (including remote desktop on occasion via Guacamole) - I also prefer zsh and I have a lot of zsh functions and shell scripts that I use for administration. It is all extremely basic, but making the best of this tiny screen with my old eyes will probably mean the best experience for me.
I have tried NixOS once or twice but it felt like I was very quickly getting over my head as I am not a developer and a OS that is essentially designed for coders doesn’t fit me well. That said I like the idea of it having atomic updates, easy system rollback, and immutable. As simple as the my working environment can be on this device, it might be an opportunity to push through and learn it.
So I don’t know what changed and why suddenly the device is showing up again, but it is and I am not going to look a gift horse in the mouth.
I was able to run through the full update procedure again, after running uconsole-4g-cm4 enable I still got nothing with mmcli -L but lsusb showed the device.
Surprised I did a cd back into the directory I decompressed earlier then tried echo -en "AT+BOOTLDR\r\n" |sudo socat - /dev/ttyUSB3,crnl followed by sudo ./fastboot/bin/fastboot devices and it actually responded with the device.
So what the hell, try again right? Can’t be worse than before. I ran ./flash.sh and I have been waiting at this screen for the last 30 minutes waiting for the uConsole to reboot.
This is where it got stuck last time. Last time I got stuck here I only waited about 5 minutes, then decided it probably was not going to reboot on its own, and I ran sudo shutdown -r now and when it came back up the modem was gone. Now I am afraid to do anything. Do I reboot again? I know it is necessary to continue, but I am gunshy at this point. Should I just shut down, and then grab another SD Card and go straight on to a different community image?
I went ahead and shut it down after about 3 hours of sitting here. I am in the process of picking a new image to go with, of course if things don’t work out I can always change it. As long as the hardware is good, then it is just an SD Card swap.
