Comet (GL-RM1) requires regular manual power restart

I recently purchased a Comet (GL-RM1) and connected to my Ubuntu 25.04 machine. I setup the device and connected via the IP address. All was working, until I needed to reconnect to the Ubuntu machine, as I got a cannot find device via IP in the browser. Now, every time I need to connect the Ubuntu machine via the Comet I need to manually pull the power plug in/out to restart the Comet. The white light is flashing before re-powering. I am at the latest firmware version. See logs attached.

system_logs_20260312_191929.zip (43.5 KB)

As I understand it, this is supposed to be fixed in the next firmware release. Welcome to the glinet beta testing group.

Please try this firmware. Since we are unable to reproduce the issue ourselves, we can only ask you to try this test firmware to see if it resolves the problem.

hi, this firmware causes both of my devices to get stuck during connection at 99%. apparently the old firmware ‘V1.5.0 release1 (RM1)’ does not have the issue.

update: fixed the issue of timeout after 99%. numpy was missing for whatever reason.

Initially, I mistakenly provided an internal test firmware, which I later replaced with the correct version. The firmware currently displayed should not have any numpy-related issues.

If you cannot log in to the web page, try connecting via SSH and run this command to update the firmware to 1.8.1release1.Then upgrade to the firmware I provide

wget https://fw.gl-inet.com/kvm/rm1/release/glkvm-RM1-1.8.1-0306-1772781495.img -O /userdata/update.img  && check_image_validity /userdata/update.img && updateEngine --image_url=/userdata/update.img --misc=update --savepath=/userdata/update.img --n --keep_config --reboot

I have updated to 1.8.2 beta. I’ll let you know if the issue persists. Thanks for such a quick turn-around.

I’m having the exact same issue as stated by zanlation. This has been an issue for me on every firmware version after 1.5.0 release1 (RM1).

I have downgraded all of my GL-RM1 devices to 1.5.0 release1 (RM1) and I no longer see the issue, but as soon as I update any of them to any version beyond this one, I experience the issue.

The issue is still persisting. I cannot contact the Comet after a few hours it drops out. My router also doesn’t detect it too.

After restarting the RM1, run the following command to see if it takes effect:
ethtool -s eth0 speed 100 duplex full autoneg off

I ran this command on the KVM and it rebooted, so I assume it took effect. Will wait and see if the issue happens now. Thanks.

I ran the command yesterday afternoon and I could contact the Comet this morning. So far it has worked.

Actually, after our testing, we found that the issue is due to some users having poor-quality switches or network cables. This causes the ethernet to initially negotiate as a Gigabit Ethernet , but after a while, it should drop down to 100 Mbps. However, the KVM still recognizes it as Gigabit. Therefore, the command provided above is actually intended to forcibly configure the Ethernet port to 100 Mbps. So, theoretically, this problem can be resolved physically, such as by replacing the network cable with a better one. Additionally, we will also monitor the issue of not automatically negotiating down to 100 Mbps.

1 Like

By the way, we still recommend that users replace the network cable or switch, as KVM may experience noticeable issues when using a 100-megabit network, especially at high bit rates.

You must be kidding.

1 Like

Also – if the issue is due to poor quality switches/network cables, why does this issue not occur on version 1.5.0 release1 (RM1)?

After over 24 hours, unfortunately the command I ran (ethtool -s eth0 speed 100 duplex full autoneg off) did not resolve the issue. In just the last 15 minutes, the issue occurred again.

I don’t think its related to a poor quality switch…I have this switch here ( Switch Pro HD 24 PoE - Ubiquiti Store ) which is not poor quality. It could possibly be the ethernet cable, however I’m using different branded ethernet cables accross my 4 KVMs (RM-1s) and this issue happens on ALL of them. Therefore I find that being the cause to be unlikely.

I will try the suggestion from yesinmorse and report back. I will say though, I already gave all of my KVMs a static IP through my router (but not via the GL.iNet Admin Panel – does that make difference?). I’ll try disabling USB Autosuspend.

Thanks!

1 Like

i foudn a fix for me and i dont have the issue anymore - no manual power restarts needed. all i did is:

Device: GL.iNet GLKVM RM1 (Comet)
Firmware: V1.8.2 beta0 (glkvm-RM1-1.8.1-0206-1770368458.img)

Issue 1: GUI loads to 99% then times out

The main kvmd service crashes on startup with ModuleNotFoundError: No module named 'numpy'. The new ASR (speech recognition) feature imports numpy, but it's not included in the firmware.

Fix: Create a minimal numpy stub module:

mkdir -p /usr/lib/python3.12/site-packages/numpy
cat > /usr/lib/python3.12/site-packages/numpy/init.py << 'EOF'
"""Minimal numpy stub for kvmd asr module."""
import array as _array
import struct as _struct

int16 = "int16"

class _ndarray:
def init(self, data, dtype=None):
self._data = data
self._dtype = dtype
def reshape(self, *args):
return self
def len(self):
return len(self._data)
def iter(self):
return iter(self._data)
def getitem(self, key):
return self._data[key]

def frombuffer(buffer, dtype=None):
if dtype == int16:
count = len(buffer) // 2
values = list(_struct.unpack(f"<{count}h", buffer))
return _ndarray(values, dtype=dtype)
return _ndarray(list(buffer), dtype=dtype)

def array(obj, dtype=None):
return _ndarray(list(obj), dtype=dtype)

def zeros(shape, dtype=None):
if isinstance(shape, int):
shape = (shape,)
size = 1
for s in shape:
size *= s
return _ndarray([0] * size, dtype=dtype)
EOF

Issue 2: No HDMI signal / video stream

The streamer crashes with KeyError: 'venc_mode'. The config main.yaml uses {venc_mode} as a template variable, but the Python code doesn't define it.

Fix: Replace the template variable with the default value:

sed -i 's/{venc_mode}/smart/g' /etc/kvmd/main.yaml

After both fixes, restart kvmd:

/etc/init.d/S98kvmd stop; sleep 2; /etc/init.d/S98kvmd start

Nope. The issue is still there. I ran auto usb suspend on Ubuntu and gave the Comet a static IP.

This issue should only occur in the firmware I previously uploaded here, and I have already replaced that firmware within one or two hours.