UBUNTU 26.04 正式 發行. 系統要求至少 6GB RAM, 25GB 儲存空間

Ubuntu 主機螢幕解析度看起來正常 1920 x1080

但 Virtualbox 一直解讀 實體機外接的 Panasonic TV HDMI 解析度是 3072 x 1728

Panasonic TV EDID 提供完全錯誤的解析度, Ubuntu Virtualbox 死抓錯誤不放

VM 字變成超級小, Scaling 也不 work, VM window 一移動就縮成半高

Windows Virtualbox 完全正常

==

AI 幫我改一堆設定企圖修正, 徒勞無功
xrandr 指令輸出

randr Screen 0: minimum 16 x 16, current 3072 x 1728, maximum 32767 x 32767
HDMI-1 connected primary 3072x1728+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
3072x1728 59.94*+
2048x1536 59.95
1920x1440 59.97
1600x1200 59.87
1440x1080 59.99
1400x1050 59.98
1280x1024 59.89
1280x960 59.94
1152x864 59.96
1024x768 59.92
800x600 59.86
640x480 59.38
320x240 59.29
2560x1600 59.99
1920x1200 59.88
1680x1050 59.95
1440x900 59.89
1280x800 59.81
1152x720 59.97
960x600 59.63
928x580 59.88
800x500 59.50
768x480 59.90
720x480 59.71
640x400 59.95
320x200 58.14
2880x1620 59.96
2560x1440 59.96
2048x1152 59.90
1920x1080 59.96
1600x900 59.95
1368x768 59.88
1280x720 59.86
1024x576 59.90
864x486 59.92
720x400 59.27
640x350 59.28

AI 說 Ubuntu 做了自動 scaling 但沒告訴你, 所以看起來正常

AI 要我執行 xrandr --output HDMI-1 --mode 1920x1080 --rate 60 但得到以下錯誤

X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 7 (RRSetScreenSize)
Serial number of failed request: 21
Current serial number in output stream: 22

您看到的 BadMatch 錯誤非常具體且資訊豐富。它表示 X 伺服器(顯示系統)拒絕了您的請求,因為您嘗試使用的解析度、刷新率或顯示佈局組合不受您的硬體或當前配置支援。

這種錯誤在使用外接顯示器(尤其是電視)時非常常見,通常與它們透過 EDID(擴展顯示識別資料)報告自身功能的方式有關。 RRSetScreenSize 函數出現 BadMatch 錯誤(次要操作碼 7)通常表示 X 伺服器無法或不會將螢幕尺寸變更為您要求的尺寸。這可能是由多種原因造成的,但對於電視而言,通常是訊號相容性問題。

==

AI 要我執行 xrandr --verbose | grep -A5 "connected" 結果得到

HDMI-1 connected primary 3072x1728+0+0 (0x41) normal (normal left inverted right x axis y axis) 0mm x 0mm
Identifier: 0x21
Timestamp: 4137281
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 0.0

AI:
輸出結果顯示您的電視報告的實體尺寸為 0mm x 0mm,這很不尋常,通常表示電視的 EDID 資料已損壞或不完整。這就是為什麼 Xorg 會回退到預設的高解析度 (3072x1728),以及您收到 BadMatch 錯誤的原因——顯示器無法正確報告其效能。
所以主機裝ubuntu顯示正常,ubuntu上面的virtualbox系統裝ubuntu顯示異常,
主機裝windows顯示正常,windows上面的virtualbox系統裝ubuntu顯示也正常,對嗎?
還是說Panasonic TV是第2螢幕?


有沒有試過改電視本身或virtualbox本身的設定呢?
以上指令都在實體機 跑 Ubuntu

VM 是 Windows. Windows VM 裡只有四個怪異的解析度可選, 最高就是3072x1727 其他三個 解析度都很低
中間的解析度完全不見了. 虛擬醬 window 稍微動一下, Window 高度 就會一下子snap砍半

VirtualBox Guest Additions extension 肯定是裝了, 沒用

只有接一台 Panasonic TV

真的用電腦超過 30 年, 沒遇過這種情況
cruiseton wrote:
以上指令都在實體機 ...(恕刪)

這有點有趣...實體ubuntu正常,虛擬機不正常?
可是裝了"正確版本"的Guest Additions extension的虛擬機解析度不是可以隨便拉嗎?
像我虛擬機裡的win7在視窗下是1920x904,視窗縮小就變1407x765,切成全螢幕就跳成1920x1080,
感覺不干EDID的事啊?

如果要硬幹的話,google這麼說:
3. 使用指令自訂螢幕解析度 (強制修正)
如果客體機抓取到錯誤的解析度,可以使用 VBoxManage 指令強制固定解析度,而不依賴 EDID。

關閉虛擬機。
開啟終端機或命令提示字元 (cmd),切換到 VirtualBox 安裝目錄。
執行以下指令(將 你的虛擬機名稱 替換為實際名稱,並設定你想要的解析度):

VBoxManage setextradata "你的虛擬機名稱" "CustomVideoMode1" "1920x1080x32"


我覺得你可以先檢查windows螢幕驅動程式是不是VirtualBox Graphics Adapter (WDDM),
然後虛擬機的設定->顯示->圖形控制器調別的看看,我用的是VBoxSVGA...
X4san6 wrote:
這有點有趣...實體ubuntu正常,虛擬機不正常?
可是裝了"正確版本"的Guest Additions extension的虛擬機解析度不是可以隨便拉嗎?
像我虛擬機裡的win7在視窗下是1920x904,切成全螢幕就跳成1920x1080,
感覺不干EDID的事啊?


理論如此, 在 Windows Virtualbox 下完全正常. 不管 VM 是 Windows/Linux. 連 AI 都說 Windows 支援較好 不過這是實話. 桌面 Linux OS 永遠只占 5%, bug 修正需要開發者有空有閒還不缺錢.

X4san6 wrote:
VBoxManage setextradata "你的虛擬機名稱" "CustomVideoMode1" "1920x1080x32"


稍後再試
cruiseton wrote:
理論如此, 在 Windows...(恕刪)

如果windows跟linux下的VirtualBox都是同一版的話,先試試
虛擬機的設定->顯示->圖形控制器調別的看看,
還不行的話,那就是VirtualBox的linux版有bug了,
怎麼看都是VirtualBox的鍋就是了...因為這邊實體EDID應該是無關的,
有問題的是虛擬機的驅動程式或EDID

cruiseton wrote: 需要開發者有空有閒還不缺錢.

很可惜不只如此,比如驅動程式需要硬體廠商提供資料,不然就要硬hack導致相容性差,
但是硬體廠商經常對微軟以外保密到家...
linux開發者拿不到廠商資料就很難搞的好,比如像nouveau

硬體廠商幾乎一定會開發windows版驅動程式,
但是linux版不是沒有就是放個1版當作有支援
奇了. 重裝 UBUNTU, 結果 這次 XRANDR 輸出正常, max resolution 是 1920x1080 了

但 GNOME SETTINGS 一直當, 程式極度緩慢. 昨天就說介面一直在繞圈圈

今天才剛開機用 Firefox 下載並裝了 VB , 沒多久就 DEVICE MEMORY IS NEARLY FULL?

迷你主機有 32GB



解析度也正常

這 UBUNTU 是在故意搞我嗎?

SORRY, BYE!
可怕的 snap 軟體安裝包:

Q: how much more space required for snap package than plain .deb ?

AI said:

Snap 軟體包通常比傳統的 .deb 軟體包佔用更多的磁碟空間,這主要是由於其設計哲學的根本差異所致。
具體來說,空間佔用的增加主要來自以下三個方面:

1. 依賴項的捆綁(Bundled Dependencies)

  • .deb 軟體包: 遵循「共享庫」原則。如果一個軟體需要某個庫(例如 libssl),它會假設系統中已經安裝了該庫,或者要求系統透過包管理器安裝一份共享副本。
  • Snap 軟體包: 為了確保在不同發行版上的相容性,Snap 採取「自給自足」的方式,將應用程式運行所需的大部分依賴庫直接打包在內。


  • 空間差異: 同一個庫可能會在多個 Snap 中各存一份,而 .deb 則全系統共享一份。這會導致 Snap 的體積通常是 .deb 的 3 到 10 倍。

2. 多版本保留(Revision Retention)

Snapd 默認會為每個安裝的軟體保留 兩個版本(目前的版本和前一個版本)。
  • 如果你安裝了一個 200MB 的軟體,Snap 實際上會佔用約 400MB 的空間,以便在更新出錯時隨時「回滾」(Rollback)。
  • 雖然這增加了安全性,但對磁碟空間有限的用戶來說是個負擔。
    小撇步: 你可以透過命令 sudo snap set system refresh.retain=2(這是最低值)來限制保留的版本數量。

3. 運行環境與掛載機制

Snap 使用 SquashFS 壓縮鏡像。雖然 SquashFS 本身是壓縮的,但為了運行這些 Snap,系統需要額外安裝核心運行時環境(如 core22、gnome-42-2204 等)。
  • 即使你只安裝了一個很小的 Snap 軟體,系統也可能需要額外下載數百 MB 的核心平台包。

數據對比示例

以常見軟體為例,空間佔用的差異大致如下:
<thead></thead>
軟體名稱 .deb 佔用空間 (約略) Snap 佔用空間 (含依賴) 空間增幅
Firefox ~70 MB ~250 MB ~3.5 倍
VLC ~15 MB ~300 MB ~20 倍
Calculator ~2 MB ~100 MB (含運行環境) ~50 倍
關閉廣告
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!