2025/11/29

ComfyUI Stable Diffusion Service Setup

   This guide assumes you have Python 3.8+ and NVIDIA GPU drivers (CUDA 13.0 or compatible) installed on your system.


   1. Navigate to your desired project directory:

      Open your terminal and change to the directory where you want to install ComfyUI. If the directory doesn't exist, create it.


   1     cd /path/to/your/comfyui_project

   2     # If the directory is empty or you want a fresh start, ensure it is empty

   3     # If .venv exists, remove it: rm -rf .venv


   2. Clone the ComfyUI repository:

      This will download all the necessary ComfyUI files into your current directory.

   1     git clone https://github.com/comfyanonymous/ComfyUI.git .


   3. Create a Python Virtual Environment:

      We'll use uv to create an isolated environment for ComfyUI's dependencies.

   1     uv venv


   4. Install PyTorch with CUDA Support:

      This step is crucial for GPU acceleration. We'll use the specific PyTorch build that is compatible with your DGX Spark's CUDA environment (cu129 index).


   1     uv pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu129


   5. Install ComfyUI's remaining dependencies:

   1     uv pip install -r requirements.txt


   6. Download the Stable Diffusion Model:

      You need a Stable Diffusion model checkpoint. We'll download the v1-5-pruned-emaonly.safetensors model, which is a standard choice.

      First, ensure the target directory exists:


   1     mkdir -p models/checkpoints

      Then, download the model:


   1     wget -O models/checkpoints/v1-5-pruned-emaonly.safetensors https://huggingface.co/runwayml/stable-diffusion-v1-5/resolve/main/v1-5-pruned-emaonly.safetensors


   7. Launch the ComfyUI Server:

      To make ComfyUI accessible over your network (for tools like Open-WebUI), launch it with the --listen flag. You can run it in the foreground to see output or in the background:


       * To run in foreground (for debugging/monitoring):

   1         .venv/bin/python main.py --listen

          (You'll need to press Ctrl+C to stop it.)


       * To run in background (recommended for service):

   1         nohup .venv/bin/python main.py --listen > comfyui.log 2>&1 &

          This command runs ComfyUI in the background, redirects its output to comfyui.log, and detaches it from your terminal. You can check tail -f comfyui.log for logs or use fg to

  bring it back to foreground if launched using &.


   8. Verify ComfyUI is Running:

      Open your web browser and go to http://<YOUR_SPARK_IP>:8188. Replace <YOUR_SPARK_IP> with the actual IP address of your machine. If you see the ComfyUI interface, the server is

  running.


   9. Test Image Generation:

      Inside the ComfyUI web UI, try to generate a simple image using the default workflow. If it successfully generates an image, your Stable Diffusion service is fully operational.


   10. Connect to Open-WebUI:

      You can now configure Open-WebUI to use this ComfyUI instance by pointing its "API URL" setting to http://<YOUR_SPARK_IP>:8188.


2025/11/25

在 Ubuntu 用 Miniforge 建立 PyTorch CUDA 環境

Ubuntu 24.04 上,利用 Miniforge 建立 Python 環境,安裝支援 CUDAPyTorch

特別注意,從 PyTorch 2.6 開始,官方已不再發布 CondaGPU 套件,因此必須改用 pip 搭配 PyTorch 官方提供的 CUDA 套件。


一 安裝 Miniforge

下載最新版 Miniforge 安裝腳本。

wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh

安裝執行檔。

bash Miniforge3-Linux-x86_64.sh

當安裝程式詢問是否要執行 conda init 時,選擇 no,避免修改 .bashrc 或 .profile。

二 啟用 Miniforge 基底環境

要使用 Miniforge 時,在當前 shell 手動載入即可。

source ~/miniforge3/bin/activate

出現 (base) 前綴代表 Miniforge 已啟用。

三 建立獨立的 PyTorch 環境

Python 3.10 建立名為 torch 的環境。

conda create -n torch python=3.10

啟用環境。

conda activate torch

四 移除可能已存在的 CPU 版 PyTorch

由於 Conda 預設可能從 conda-forge 安裝 CPU 版 PyTorch,先將其移除。

conda remove -y pytorch pytorch-cuda torchvision torchaudio

pip uninstall -y torch torchvision torchaudio

五 安裝支援 CUDA 的 PyTorch

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126

六 驗證 CUDA 是否可用

python - <<'EOF'

import torch

print("PyTorch:", torch.__version__)

print("CUDA version:", torch.version.cuda)

print("CUDA available:", torch.cuda.is_available())

if torch.cuda.is_available():

    print("GPU name:", torch.cuda.get_device_name(0))

EOF

若 CUDA available 顯示 True,且顯示 GPU 名稱,代表 GPU 加速已正常啟用。




2025/11/1

 gitdaemon 不支援 lfs,如果要的話,要另外 install 一個 lfs server。    

2025/10/23

MediaWiki 1.44 使用者帳號管理指令

 注意:MediaWiki 1.40 之後,維護腳本需使用 maintenance/run.php 執行,不再直接執行腳本檔案。


以 https://github.com/checko/mediawiki144 啟動/restore 的 mediawiki container 為例:

方法一:建立新的管理員帳號

建立一個具有管理員和行政員權限的新帳號:

docker compose exec mediawiki php maintenance/run.php createAndPromote \
  --bureaucrat --sysop --force \
  使用者名稱 密碼

範例:

docker compose exec mediawiki php maintenance/run.php createAndPromote \
  --bureaucrat --sysop --force \
  admin AdminPassword123!

方法二:重設現有使用者密碼

變更現有使用者的密碼:

docker compose exec mediawiki php maintenance/run.php changePassword \
  --user=使用者名稱 \
  --password=新密碼

範例:

docker compose exec mediawiki php maintenance/run.php changePassword \
  --user=Ken.Lin \
  --password=kenlinpassword123!

方法三:提升現有使用者為管理員

將現有使用者提升為管理員和行政員:

docker compose exec mediawiki php maintenance/run.php createAndPromote \
  --bureaucrat --sysop --force \
  使用者名稱

範例:

docker compose exec mediawiki php maintenance/run.php createAndPromote \
  --bureaucrat --sysop --force \
  ExistingUser

方法四:使用 SQL 指令直接操作(不建議)

直接在資料庫中授予使用者管理員權限:

docker compose exec mysql mysql -u root -proot_password mediawiki -e "
  INSERT INTO user_groups (ug_user, ug_group)
  SELECT user_id, 'sysop' FROM user WHERE user_name = '使用者名稱'
  ON DUPLICATE KEY UPDATE ug_group = ug_group;

  INSERT INTO user_groups (ug_user, ug_group)
  SELECT user_id, 'bureaucrat' FROM user WHERE user_name = '使用者名稱'
  ON DUPLICATE KEY UPDATE ug_group = ug_group;
"

權限說明

  • sysop:管理員權限,可以刪除頁面、封鎖使用者、保護頁面等
  • bureaucrat:行政員權限,可以授予其他使用者權限、重新命名使用者等

注意事項

  • 使用 maintenance/run.php 是 MediaWiki 1.40 之後的標準做法
  • 舊的直接執行方式(maintenance/scriptName.php)雖仍可用但已過時
  • 建議使用維護腳本而非直接操作 SQL 資料庫
  • 密碼中如有特殊字元,需注意 shell 跳脫字元處理

2025/10/22

ESP32-DevKitC V4 與 ESP32 系列產品的關係


產品分層架構

ESP32 的產品線可以分為三個層級:晶片(SoC)、模組(Module)、開發板(Development Board)。這三層形成了從矽晶片到最終使用者產品的完整架構。

第一層:晶片(SoC - System on Chip)

這是最底層的矽晶片元件,是所有後續產品的核心。常見的 ESP32 晶片包括:

第二層:模組(Module)

模組是將晶片與必要的周邊元件(如 Flash 記憶體、晶振、天線等)整合在小型 PCB 上的產品。這些模組已通過必要的認證,可以直接用於產品設計。常見的 ESP32 模組包括:

第三層:開發板(Development Board / EVB)

開發板是將模組焊接在一個完整的電路板上,並提供 USB 連接、電源管理、GPIO 引腳等便利開發的功能。開發板適合開發者和創客使用。常見的 ESP32 開發板包括:

ESP32-DevKitC V4 在產品線中的位置

所屬系列

ESP32-DevKitC V4 屬於 ESP32 原始系列(第一代 ESP32,使用 Xtensa LX6 雙核或單核處理器)。它不是以下變體系列:

與 ESP32 系列的技術關係

ESP32-DevKitC V4 使用的是標準的 ESP32 晶片,因此它在技術規格上與原始的 ESP32 系列完全相同。具體來說:

硬體構成

  • 預設搭載 ESP32-WROOM-32E 模組
  • 該模組內部採用 ESP32-D0WD-V3 晶片

核心技術規格

  • 處理器:Xtensa 雙核 32 位元 LX6,最高時脈 240 MHz
  • 指令集架構:Xtensa ISA
  • 記憶體:520 KB SRAM(快速記憶體),448 KB ROM(唯讀記憶體)
  • GPIO 引腳:34 個
  • 類比轉換器(ADC):2 個,各 12 位元
  • 數位轉換器(DAC):2 個,各 8 位元
  • SPI 介面:4 個
  • I2C 介面:2 個
  • UART 介面:3 個

差異

雖然核心規格相同,但使用方式有所不同:

  • 晶片或模組:需要設計客製 PCB、處理電源管理、連接 USB 轉換晶片等,適合產品設計工程師
  • 開發板:已整合所有必要電路,可直接透過 USB 連接電腦進行開發,適合開發者和創客使用

產品線對照

ESP32 原始系列的各層級產品及其適用對象:

產品層級產品名稱說明適用對象
晶片(SoC)ESP32-D0WD-V3雙核 Xtensa LX6 裸晶片晶片設計廠商
模組(Module)ESP32-WROOM-32E晶片 + Flash + 天線整合模組產品設計工程師
模組(Module)ESP32-WROVER-E晶片 + Flash + PSRAM + 天線產品設計工程師
模組(Module)ESP32-SOLO-1單核版本模組產品設計工程師
開發板(EVB)ESP32-DevKitC V4模組 + USB + 電源 + GPIO 引腳開發者、創客、學生
開發板(EVB)ESP32-DevKitM-1搭載 ESP32-MINI-1 小型模組開發者
開發板(EVB)ESP32-PICO-KIT-1搭載 ESP32-PICO-D4 模組開發者

實際應用情境

開發者和創客

選擇使用 ESP32-DevKitC V4 這類開發板的主要優點:

  • 開箱即用,透過 USB 直接連接電腦
  • 已整合電源管理和 USB 轉 UART 晶片
  • 所有 GPIO 引腳引出到排針,方便連接其他元件
  • 價格低廉,約 5 到 10 美元

產品設計工程師

選擇使用 ESP32-WROOM-32E 這類模組的主要優點:

  • 已通過 FCCCESRRC 等國際認證
  • 只需設計簡單的底板 PCB
  • 降低產品認證成本
  • 享受穩定可靠的供應鏈

大量生產廠商

直接使用 ESP32 晶片的主要優點:

  • 成本最低
  • 產品設計完全客製化
  • 可將產品體積最小化

總結

ESP32-DevKitC V4 與最初列出的 ESP32 系列的關係可以總結如下:

  • 核心架構相同:DevKitC V4 搭載的模組使用的正是最初列出的 ESP32 系列晶片(ESP32-D0WD-V3)
  • 技術規格一致:處理器、指令集架構、時脈、記憶體、周邊介面等技術規格與最初列出的 ESP32 系列完全相同
  • 產品形式不同:最初列出的是晶片和模組層級的技術規格,而 ESP32-DevKitC V4 是開發板層級的最終產品,但核心都是同一顆 ESP32 晶片
  • 官方開發板:ESP32-DevKitC V4 就是 Espressif 公司推出的官方開發板,代表了最受歡迎的通用 ESP32 開發解決方案

因此,ESP32-DevKitC V4 是 ESP32 原始系列的官方開發板實現,讓開發者能夠方便地使用和學習 ESP32 晶片的所有功能特性。

2025/10/14

GNOME Terminal 啟動延遲問題再次發生

 

問題描述

在執行 apt update 和 apt upgrade 之後,gnome-terminal 啟動延遲的問題再次出現。終端機在系統開機後需要 20-30 秒才能啟動,儘管先前的修正(停用 im-config 自動啟動 fcitx5 並建立 systemd 使用者服務)仍然有效。

症狀

  • GNOME Terminal 在系統開機後首次啟動時會有明顯延遲(約 26 秒)
  • 問題只發生在開機後的第一次啟動
  • 後續的啟動正常,沒有延遲
  • 先前的設定(im-config 設為 "none" 及自訂的 fcitx5.service)仍然完整

診斷過程

步驟 1:驗證先前的設定

確認先前的修正仍然有效:

$ im-config -l
 ibus fcitx5 xim

$ cat ~/.xinputrc
# im-config(8) generated on Fri, 10 Oct 2025 13:01:31 +0800
run_im none
# im-config signature: 0a0fbfefedad5558a9e9e2919b262f89  -

$ systemctl --user status fcitx5.service
● fcitx5.service - Fcitx5 Input Method
     Loaded: loaded (/home/charles-chang/.config/systemd/user/fcitx5.service; enabled; preset: enabled)
     Active: inactive (dead) since Tue 2025-10-14 08:32:41 CST

設定完整保留

步驟 2:檢查開機日誌的時序問題

$ journalctl --user -b 0 --no-pager | grep -E "(fcitx5|gnome-terminal|graphical-session)"

從開機序列中發現的關鍵資訊:

08:31:46 - graphical-session.target 尚未就緒
08:31:49 - 達到目標 graphical-session.target
08:31:49 - fcitx5.service 啟動
08:31:55 - 請求啟動 gnome-terminal
08:31:59 - fcitx5: DBus call error: org.freedesktop.DBus.Error.NoReply Method call timed out
08:32:04 - fcitx5: DBus call error: org.freedesktop.DBus.Error.NoReply Method call timed out
08:32:09 - fcitx5: DBus call error: org.freedesktop.DBus.Error.NoReply Method call timed out
08:32:14 - fcitx5: DBus call error: org.freedesktop.DBus.Error.NoReply Method call timed out
08:32:14 - fcitx5: Query portal value reaches retry limit
08:32:21 - gnome-terminal-server.service 啟動(請求後 26 秒!)

步驟 3:找出 Portal 服務問題

fcitx5 的日誌顯示 portalsettingmonitor.cpp 重複嘗試查詢桌面 portal 設定時發生錯誤。進一步檢查 portal 服務:

$ journalctl --user -b 0 --no-pager | grep -E "portal"

關鍵發現:

08:31:46 - 啟動 xdg-desktop-portal.service
08:31:46 - 啟用 org.freedesktop.impl.portal.desktop.gnome
08:31:46 - xdg-desktop-portal-gnome.service: Job failed with result 'dependency'
08:31:49 - fcitx5 啟動(portal 尚未就緒!)
08:32:36 - xdg-desktop-portal-gtk.service 以備用方案啟動(延遲 50 秒!)

根本原因分析

這個問題是從先前問題演變而來的:

先前的問題(已解決):

  • fcitx5 啟動太早(在 graphical-session.target 之前)
  • 透過讓 fcitx5 等待 graphical-session.target 來修正

目前的問題(apt upgrade 之後):

  1. xdg-desktop-portal-gnome.service 在 08:31:46 嘗試啟動,早於 graphical-session.target 完全就緒的時間(08:31:49)
  2. 由於 Requisite=graphical-session.target 相依性,GNOME portal 啟動失敗
  3. fcitx5 在 08:31:49 正確啟動(在 graphical-session.target 之後),但立即嘗試查詢 portal 設定
  4. portal 尚未就緒,導致 fcitx5 被阻塞並重試 4 次(每次逾時 5 秒 = 總共 20 秒)
  5. gnome-terminal 的啟動被阻塞,等待 fcitx5 完成初始化
  6. 在 fcitx5 放棄後,xdg-desktop-portal-gtk 以備用方案啟動,gnome-terminal 終於能夠啟動

為什麼在 apt upgrade 後發生:

套件更新可能修改了 xdg-desktop-portal 服務的時序或相依性,導致 GNOME portal 在開機序列中更早失敗。這造成了 fcitx5 和 portal 服務之間的新競爭條件。

解決方案

更新 fcitx5 systemd 服務,明確等待桌面 portal 服務:

檔案: ~/.config/systemd/user/fcitx5.service

[Unit]
Description=Fcitx5 Input Method
Documentation=man:fcitx5(1)
PartOf=graphical-session.target
After=graphical-session.target xdg-desktop-portal.service
Wants=graphical-session.target xdg-desktop-portal.service

[Service]
Type=simple
ExecStart=/usr/bin/fcitx5
ExecStartPost=/usr/bin/dbus-update-activation-environment --systemd GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx
Restart=on-failure
RestartSec=3

[Install]
WantedBy=graphical-session.target

變更內容:

  • 在 After= 指令中加入 xdg-desktop-portal.service:fcitx5 會等到 portal 就緒後才啟動
  • 在 Wants= 指令中加入 xdg-desktop-portal.service:確保 portal 服務被請求/啟動

套用修正:

$ systemctl --user daemon-reload
$ systemctl --user show fcitx5.service | grep -E "^(After|Wants)="
Wants=graphical-session.target xdg-desktop-portal.service
After=graphical-session.target basic.target xdg-desktop-portal.service app.slice

驗證結果

重新開機系統後:

  • gnome-terminal 立即啟動,沒有延遲
  • fcitx5 日誌中沒有 DBus 逾時錯誤
  • 正確的啟動序列:graphical-session.target → xdg-desktop-portal → fcitx5 → gnome-terminal

關鍵要點

  1. 服務相依性很重要:即使修正了最初的 im-config 競爭條件,其他相依性(如桌面 portal)仍可能引入新的時序問題
  2. 系統更新可能改變時序:套件更新可能改變服務啟動順序或相依性,暴露出先前隱藏的競爭條件
  3. 監控所有元件:問題不在於 fcitx5 相對於 graphical-session.target 的時序(這部分是正確的),而是它與 portal 服務的互動
  4. 適當的相依鏈:同時使用 After= 和 Wants= 確保服務以正確順序啟動,並且所需的服務確實被啟動

參考資料