System Admin Share

How to Fix a Bricked Xiaomi Mi 360 Camera (Stuck on Solid Yellow Light)

noreply@blogger.com (System Engineer) — Sat, 7 Mar 2026 17:15:24 +0530

When you spend your day orchestrating complex infrastructure and recovering cloud systems, dealing with a bricked smart home gadget feels like it should be an easy afternoon fix. Yet, seeing that dreaded solid yellow light on your Xiaomi Mi 360 Security Camera is enough to test anyone’s patience.

Usually, this happens after an interrupted Over-The-Air (OTA) firmware update or a sudden power failure. The camera becomes completely unresponsive, refuses to connect to the Mi Home app, and just stares at you with a solid orange/yellow LED.

Before you toss it in the e-waste bin, don't worry—it’s entirely recoverable. You just need to manually flash the factory firmware using a MicroSD card.

I recently put together a complete repository for this fix over on GitHub: nandlalyadav57/MJSXJ02CM-360-Degree-Security-Recovery.

Here is the step-by-step guide on how to bring your camera back to life.

⚠️ The Golden Rule: Check Your Model Number

Xiaomi manufactures dozens of identical-looking cameras with completely different internal hardware. Flashing the wrong firmware will permanently destroy your camera.

Turn your camera upside down and check the sticker on the base. You are looking for a model number like MJSXJ02CM, MJSXJ05CM, or MJSXJ09CM. Write this down.

What You Need

A MicroSD card (16GB or 32GB is ideal; Class 10 recommended).
A PC or Mac with an SD card reader.
The exact firmware file for your specific camera model.

Step 1: Format Your MicroSD Card

Smart camera bootloaders are incredibly picky. Your SD card must be formatted to FAT32. If you format it to exFAT or NTFS, the camera simply won't be able to read the recovery file, and the flash will fail silently.

Step 2: Download the Factory Firmware

Instead of hunting through sketchy forums, I’ve compiled the direct download links straight from Xiaomi’s official CDN servers. Find your exact model below:

Mi 360° Camera (1080p)

MJSXJ02CM: Download IPC009_4.0.9_0409.zip (My featured model on GitHub)
MJSXJ05CM: Download IPC019_4.0.9_0426.zip
MJSXJ08CM (Essential): Download IPC026C_4.0.9_0268.rar
MJSXJ10CM (C200 / SE+): Download IPC026C02_4.1.4_0084.rar

Mi 360° Camera (2K & 2K Pro)

MJSXJ09CM (2K): Download IPC029A_4.0.9_0267.rar
MJSXJ06CM (2K Pro): Download IPC021_4.1.6_0206.zip

Once downloaded, extract the .zip or .rar file. Inside, you will find a file usually named tf_recovery.img (on some models, it might be demo.bin).

Copy this recovery file directly to the root directory of your formatted SD card. Do not hide it inside a folder. Eject the card safely.

Step 3: Flash the Recovery Firmware

This is the moment of truth. Follow these steps precisely:

Cut the Power: Unplug the micro-USB or USB-C cable from the back of your camera so it is completely dead.
Insert the SD Card: Gently roll the black camera lens upwards with your thumb to reveal the hidden MicroSD card slot. Push the card in until it clicks.
Power it Up: Plug the camera back into the wall.
Watch the LED: The light will start solid yellow/orange. After a few seconds, it should begin blinking. This blinking means the bootloader has found the .img file and is actively rewriting the firmware.
Hands Off: Wait 5 to 10 minutes. Do not unplug the camera. Do not press the reset button. Just let it work.

If the flash is successful, the camera will automatically reboot itself. The camera head will rotate, the LED will start blinking blue, and you’ll hear the familiar voice prompt: "QR code ready to scan."

Step 4: Clean Up

Unplug the camera, pop the SD card out, and format the SD card on your computer again. If you leave the tf_recovery.img file on the card and put it back in the camera, it will trigger the flashing process all over again the next time the camera reboots.

Pop the clean SD card back in, open your Mi Home app, and set your camera up like it just came out of the box!

Application Migration to Kubernetes: A Step-by-Step Guide

noreply@blogger.com (System Engineer) — Mon, 24 Jun 2024 10:30:00 +0530

Migrating applications from virtual machines to Kubernetes can be challenging, but with the right approach, it can transform your deployment strategy. This comprehensive guide will walk you through each step of the migration process, sharing best practices to ensure a smooth transition.

Understanding Your Application
- Is it stateless or stateful?
- Dependencies
- Components to migrate
- Session stickiness
- Configuration methods
- Launch processes
Containerizing Your Application
- Building the image
- Choosing a base image
- Creating the final image
Preparing Environments and Migration
- Setting up Kubernetes environments
- Migration strategies
Creating Kubernetes Manifests
- Deployment vs StatefulSet
- ConfigMap and Secrets
- Services, Ingress, and Autoscaling
Executing the Migration
- Sizing and load testing
- Migration best practices
Conclusion

Understanding Your Application

Is it Stateless or Stateful?

Determine if your application is stateless or stateful. Stateless applications are easier to migrate since they don’t maintain user session data. Stateful applications, however, require more planning due to their dependency on persistent data storage.

Stateless Migration:

Simplified process
Easier to maintain

Stateful Migration:

Requires identifying and managing stateful components
May involve significant code changes or infrastructure adjustments

If your application is stateful, you have two choices:

Rework the code: Ideal but time-consuming.
Maintain current state: Quicker but requires additional infrastructure management.

Dependencies

Understand your application's architecture and dependencies. Ensure all network connections between your app and its dependencies are configured correctly in the Kubernetes environment.

Components to Migrate

Identify all components that need migration. This includes databases and other services. Determine if the migration will be within the same location or to a new one.

Session Stickiness

Evaluate if your application uses session stickiness, which ties a user to a specific instance of your app. Implementing this in Kubernetes involves managing sticky sessions to ensure a smooth user experience.

Configuration Methods

Know how your application is configured. Using environment variables is preferred in Kubernetes for easier management.

Launch Processes

Document all commands related to your service, including:

Launch commands
Build commands
Database migration commands

Containerizing Your Application

Building the Image

Optimizing the image size is crucial. Split your Dockerfile into multiple stages to reduce the final image size.

Example Dockerfile:

dockerfile

FROM node:17.6.0-slim AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:17.6.0-alpine3.15
WORKDIR /app
COPY --from=builder /app/build ./build
USER node
CMD ["npm", "start"]

Choosing a Base Image

Choose the smallest base image that supports your application's language and dependencies, like alpine or distroless.

Preparing Environments and Migration

Setting Up Kubernetes Environments

Create a Kubernetes cluster (EKS, GKE, etc.) and deploy any necessary dependencies like databases or persistent data management tools.

Migration Strategies

Depending on your setup, choose between:

Full Migration: Migrates both the application and database, involving downtime.
Partial Migration: Only the application is migrated, minimizing downtime.

Full Migration Steps:

Deploy your app in the Kubernetes cluster.
Create a Maintenance page.
Redirect traffic to the Maintenance page.
Create a database dump.
Retrieve stateful volumes.
Restore data in the new database.
Restore stateful volumes in the new app.
Redirect traffic to the new application.

Partial Migration Steps:

Deploy the new app in the cluster.
Change DNS records to redirect traffic to the new app.

Creating Kubernetes Manifests

Deployment vs StatefulSet

Use Deployment for stateless services and StatefulSet for stateful applications. Ensure proper use of probes, resource limits, and configuration management.

ConfigMap and Secrets

Store application configurations and secrets securely using ConfigMaps and Secrets. Mount these as volumes if needed.

Services, Ingress, and Autoscaling

Configure Services to manage internal traffic, Ingress for external traffic, and HorizontalPodAutoscaler (HPA) for scaling based on load.

Example Kubernetes Manifest:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:latest
        ports:
        - containerPort: 80
        envFrom:
        - configMapRef:
            name: my-app-config
        - secretRef:
            name: my-app-secrets
        livenessProbe:
          httpGet:
            path: /healthz
            port: 80
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Executing the Migration

Sizing and Load Testing

Conduct load testing using tools like Gatling or K6 to determine the optimal sizing for your Kubernetes deployment.

Migration Best Practices

Test the migration in a pre-production environment. Monitor application logs, infrastructure metrics, and traffic redirection during the migration.

Load Testing Steps:

Set up a load testing tool.
Simulate production traffic.
Adjust resource allocations based on test results.

Conclusion

Migrating applications to Kubernetes requires careful planning and execution. By following these steps, you can leverage Kubernetes' capabilities for scalable, efficient, and resilient application deployment. Happy migrating!

This comprehensive guide is designed to provide a detailed roadmap for migrating your applications to Kubernetes, ensuring a successful transition and optimizing your deployment strategy.

Critical Issue in Loki v3.0.0: Backend Crashes Due to Index Gateway Mode Setting

noreply@blogger.com (System Engineer) — Tue, 18 Jun 2024 18:07:00 +0530

Overview

A significant bug has been identified in Loki v3.0.0, which causes the backend to crash with a segmentation violation error (SIGSEGV) when the index_gateway.mode is set to ring. This issue was first reported by user @awoimbee on March 20, 2024, and has been discussed extensively with multiple users encountering similar problems.

Description of the Bug

When running the Loki backend with the configuration setting index_gateway.mode set to ring, the system crashes with a segmentation fault due to a nil pointer dereference. The error trace typically looks like this:

go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x288 pc=0x223f470]

goroutine 1 [running]:
github.com/grafana/loki/pkg/loki.(*Loki).updateConfigForShipperStore(0xc000638be0?)
	/src/loki/pkg/loki/modules.go:709 +0xb0
...

This issue affects the stability of the Loki backend, causing it to enter a CrashLoopBack state.

Reproduction

The problem has been reproduced consistently under the following conditions:

Infrastructure: Kubernetes
Deployment tool: Helm
Loki version: 3.0.0
Configuration: index_gateway.mode set to ring

Workaround

As a temporary solution, users have been advised to change the index_gateway.mode from ring to simple in the configuration file. This has been confirmed to prevent the crash:

yaml
index_gateway:
  mode: simple

Resolution and Further Developments

The Grafana Loki team has acknowledged this issue and a fix has been implemented to address the nil pointer dereference during the bloomstore initialization. The fix can be tracked and reviewed in this commit.

Key Updates:

A fix for the nil pointer dereference was merged on May 3, 2024.
The problem persists for some users even after updating to the latest patches.
Additional related issues are being tracked and addressed, such as those mentioned in issue #13208.

User Reports and Feedback

Multiple users have reported encountering this issue and have shared their experiences and configurations in the issue thread. For instance:

@Nissou31 reported the issue while deploying a scalable Loki 3.0.0 setup.
@alexandergoncharovaspecta faced a similar problem with a three-pod setup where one pod was crashing.
@sslny57 and @abh shared that changing the mode from ring to simple resolved their crash issues, but they encountered other configuration problems.

Conclusion

The Loki v3.0.0 backend crash issue due to index_gateway.mode: ring is a critical bug affecting users running Loki in Kubernetes environments. While a temporary workaround is available, a permanent fix has been implemented and is available in the latest updates. Users are encouraged to update their Loki deployments and monitor the GitHub issue tracker for further updates and resolutions.

For more details and ongoing discussions, visit the GitHub issue page.

System Admin Share

How to Fix a Bricked Xiaomi Mi 360 Camera (Stuck on Solid Yellow Light)

⚠️ The Golden Rule: Check Your Model Number

What You Need

Step 1: Format Your MicroSD Card

Step 2: Download the Factory Firmware

Step 3: Flash the Recovery Firmware

Step 4: Clean Up

Application Migration to Kubernetes: A Step-by-Step Guide

Table of Contents

Understanding Your Application

Is it Stateless or Stateful?

Dependencies

Components to Migrate

Session Stickiness

Configuration Methods

Launch Processes

Containerizing Your Application

Building the Image

Choosing a Base Image

Preparing Environments and Migration

Setting Up Kubernetes Environments

Migration Strategies

Creating Kubernetes Manifests

Deployment vs StatefulSet

ConfigMap and Secrets

Services, Ingress, and Autoscaling

Executing the Migration

Sizing and Load Testing

Migration Best Practices

Conclusion

Critical Issue in Loki v3.0.0: Backend Crashes Due to Index Gateway Mode Setting

Overview

Description of the Bug

Reproduction

Workaround

Resolution and Further Developments

Key Updates:

User Reports and Feedback

Conclusion