Ubuntu 22.04 GDM3登录背景gresource替换与回滚脚本

简介：面向 Ubuntu 22.04 及以上版本用户的 GDM 登录背景定制脚本包，适合希望在新版 GNOME 显示管理器环境下完成桌面个性化设置的 Linux 用户、运维人员及桌面美化爱好者。针对旧版修改方式在新版中失效的问题，包内提供可执行脚本、透明背景处理脚本及说明文档，并按系统版本区分不同入口，方便使用者根据自身环境选择对应方案。压缩包共 10 个文件，以 sh 脚本为主，辅以 md 说明、license 许可文件及版本标记等，整体约 20KB，体量轻便，便于快速查阅、留存与取用。已有 1136 人学习下载，说明其在 Ubuntu 登录界面美化场景中具有一定参考价值。读者可从中获得适配 GDM 变更的背景设置脚本、透明效果方案与 README 使用说明，减少自行检索兼容方法的时间，适合需要轻量工具完成登录背景替换的桌面用户。

1. 登录背景不是换张图那么简单：这份脚本解决的是 GDM3 的 gresource 回滚问题

Ubuntu 22.04 以上版本修改登录背景脚本，真正难的不是找一张图，而是改完 GDM3 的 gresource 后还能体面回滚。装完系统默认登录界面是紫红底色，实验室机器、展厅机器、交付给客户的样机往往要换成统一视觉；手动解包gnome-shell-theme.gresource时，manifest 前缀写错、图片资源名对不上、编译后权限不对，轻则背景不显示，重则登录循环。脚本把探测、备份、解包、替换、编译、恢复串成一条命令，适合桌面运维、装机交付和愿意动手的桌面用户；只想要桌面壁纸的人不用碰它，直接在设置里换图就行。下面按“文件在哪、脚本怎么拆、命令怎么跑、翻车怎么救”的顺序拆。

2. GDM3 背景加载链路：从 gresource 到锁屏容器的四个关键路径

2.1 GDM3、GNOME Shell 与 Yaru 主题的关系

GDM3 是 Ubuntu 默认的登录管理器，登录界面本身是 GNOME Shell 以gdm用户身份跑起来的一个会话，它加载的主题通常来自 Yaru。桌面用户看到的“登录背景”并不是一张放在/usr/share/backgrounds里的普通壁纸，而是主题 gresource 包里的图片资源，再由gnome-shell.css里的lockDialogGroup规则引用。也就是说，登录背景加载链路上有四个关键路径：第一是 gresource 文件本身，第二是 CSS 里的锁屏容器规则，第三是规则指向的图片资源名，第四是gdm用户读取主题时的缓存和权限。很多人只替换了图片，却没检查 CSS 引用的资源名，最后 gresource 编译成功但登录界面还是老样子，这种翻车在现场很常见。

它和 Ubuntu 软件/插件里那种换主题、换图标的工具不是一回事。那些工具多数作用于当前桌面会话，改的是用户级 dconf；GDM3 登录界面发生在用户登录之前，读的是系统级主题文件。脚本选择直接改 gresource，是因为这条路径在 22.04 和 24.04 上相对稳定，而且能通过备份文件做整包回滚。代价是每次gnome-shell包更新后，系统可能把 gresource 覆盖回默认版本，所以脚本必须保留备份目录和时间戳，不能只改完就结束。

2.2 背景图到底藏在哪：gresource 文件定位与资源清单

不同安装方式下，主题文件可能落在三个位置。Ubuntu 22.04 的 Yaru 主题常见路径是/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource；部分版本或精简安装会使用/usr/share/gnome-shell/gnome-shell-theme.gresource；还有的镜像把主题放在/usr/share/gnome-shell/theme/gnome-shell-theme.gresource。脚本不应该硬编码一个路径，而是按优先级探测。下面这段命令用于定位并列出资源清单，先确认系统到底在用哪个文件。

for f in \ /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource \ /usr/share/gnome-shell/gnome-shell-theme.gresource \ /usr/share/gnome-shell/theme/gnome-shell-theme.gresource; do if [ -f "$f" ]; then echo "== $f" gresource list "$f" | sed -n '1,15p' fi done

这段命令的逻辑是按候选路径依次判断文件是否存在，存在就打印路径并列出前 15 个资源。gresource list输出的是资源内部路径，例如/org/gnome/shell/theme/gnome-shell.css、/org/gnome/shell/theme/background-logo.png。参数上，sed -n '1,15p'只是控制输出长度，避免资源太多刷屏；真正要关注的是前缀/org/gnome/shell/theme/，后面编译 manifest 时必须保持一致。如果命令提示找不到gresource，先确认libglib2.0-bin是否安装，这个包提供gresource和glib-compile-resources。

定位到文件后，下一步不是急着替换图片，而是看 CSS 里lockDialogGroup到底引用了哪个资源。执行下面这条命令，把 CSS 提取出来看上下文。

theme=/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource gresource extract "$theme" /org/gnome/shell/theme/gnome-shell.css \ | grep -A10 -B2 'lockDialogGroup'

gresource extract把指定资源输出到标准输出，grep -A10 -B2打印匹配行前后各若干行。这里要看的是background或background-image后面的url("resource:///org/gnome/shell/theme/xxx.png")。脚本解析的就是这个文件名，而不是盲猜background-logo.png。如果 CSS 里只有background-color没有图片 URL，说明当前主题不是用图片资源做登录背景，脚本应该直接退出并提示，不要强行写一个图片进去，否则登录界面可能黑屏。

2.3 脚本适用边界：22.04、24.04 与不同桌面环境的差异

这份脚本的适用边界要说清楚：它面向 GDM3 + GNOME Shell 主题的 Ubuntu 22.04 及以上版本，Wayland 和 Xorg 会话都能用，因为登录背景读的是主题资源，和会话协议关系不大。它不适用于 KDE、LightDM、SDDM 这类登录管理器，也不适用于已经换成非 Yaru 主题且 gresource 结构完全不同的系统。脚本里做版本白名单，是为了避免在结构未知的版本上直接写系统文件；白名单之外的版本可以用--force跳过检查，但前提是先用gresource list确认资源前缀和 CSS 规则。

另一个边界是“系统更新会覆盖”。gnome-shell包升级时，包管理器会把 gresource 重新装回默认版本，手动改过的文件会被覆盖。这不是脚本的 bug，而是改包内文件的固有代价。脚本把备份放在/var/backups/gdm-background，每次执行带时间戳，恢复时取最近一份；批量装机时可以把“更新后重跑脚本”写进交付清单。还有一点，远程 SSH 改 GDM 有风险，重启gdm3会注销图形会话，最好本地开一个 TTY 再操作，至少保留一条能进系统的路。

3. 脚本拆解：一个可回滚的登录背景替换流程包含哪些步骤

3.1 前置检查：版本、权限、磁盘与图片格式

脚本入口名按set-gdm-background.sh来拆。它第一段不是直接改文件，而是做前置检查：是不是 root、依赖命令在不在、系统版本是否在白名单、/usr剩余空间够不够、图片是不是 PNG 或 JPEG、图片尺寸是否合理。这些检查看起来琐碎，但能挡掉大部分低级翻车。比如用普通用户执行，解包到一半才报权限错误；或者图片是 WebP，替换成.png后 GDM 读不出来；又或者/usr只剩几十 MB，编译到一半失败，原文件已经被覆盖。下面这段是检查骨架。

#!/usr/bin/env bash set -euo pipefail need_root() { [ "$(id -u)" -eq 0 ] || { echo "请用 sudo 执行"; exit 1; } } need_cmd() { command -v "$1" >/dev/null 2>&1 || { echo "缺少命令: $1"; exit 1; } } need_root for c in gresource glib-compile-resources file awk sed; do need_cmd "$c" done . /etc/os-release case "${VERSION_ID:-}" in 22.04|24.04|24.10) ;; *) echo "当前版本 ${VERSION_ID:-unknown} 不在白名单，确认结构后再加 --force";; esac

逻辑说明：set -euo pipefail让脚本遇到未定义变量、管道失败或命令非零退出时立即停下，避免半成品写回系统。need_root用id -u判断 root；need_cmd用command -v检查依赖。/etc/os-release读取VERSION_ID，白名单只是保护，不是技术限制。参数上，--force在脚本后面用于跳过版本和图片检查；如果版本不在白名单又没有--force，脚本应该只打印探测结果并退出，不能继续写文件。

图片检查可以用file和python3读 PNG 头，不依赖 ImageMagick。常见做法是要求 PNG，尺寸至少 1920×1080，文件小于 2 MB。不是绝对标准，但登录界面加载大图会拖慢首屏，尤其在老机器上。脚本可以打印图片尺寸让用户确认，而不是自动缩放；自动缩放容易把构图裁坏，登录背景的人像或 logo 被切掉一半，现场很难解释。

3.2 核心流程：备份、解包、替换、编译、写回

核心流程分五步：备份原 gresource、按资源清单解包到临时目录、解析 CSS 找到背景资源名、用新图片覆盖同名资源、重新编译并写回原路径。顺序不能乱，尤其是备份必须在任何写操作之前完成。下面两个函数分别负责探测主题和备份，脚本后面的解包、编译都依赖它们返回的路径。

detect_theme() { local candidates=( /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource /usr/share/gnome-shell/gnome-shell-theme.gresource /usr/share/gnome-shell/theme/gnome-shell-theme.gresource ) local f for f in "${candidates[@]}"; do if [ -f "$f" ]; then printf '%s\n' "$f" return 0 fi done return 1 } backup_theme() { local theme="$1" backup_dir="$2" stamp install -d -m 0755 "$backup_dir" stamp="$(date +%Y%m%d-%H%M%S)" cp -a "$theme" "$backup_dir/gnome-shell-theme.gresource.$stamp" printf '%s\n' "$backup_dir/gnome-shell-theme.gresource.$stamp" }

detect_theme按候选数组顺序找第一个存在的文件，找到就输出路径并返回 0；找不到返回 1，让调用方报错退出。backup_theme用install -d创建备份目录并设 0755，cp -a保留原文件的权限、属主和时间戳，备份文件名带年月日-时分秒，避免多次执行互相覆盖。参数上，$1是主题文件路径，$2是备份目录；默认备份目录可以设成/var/backups/gdm-background，不要放/tmp，因为重启后/tmp可能被清理，后悔药就没了。

解包阶段建议用gresource list逐条提取，而不是只提取一张图。因为重新编译需要完整 manifest，缺资源会导致主题缺图标、缺样式。脚本可以先mktemp -d建工作目录，按资源路径去掉前缀后创建子目录，再gresource extract写入。替换图片时只覆盖 CSS 指向的那个资源名，其他文件原样保留。编译用glib-compile-resources --sourcedir=工作目录 --target=新gresource manifest.xml，manifest 的prefix必须和原资源前缀一致，通常是/org/gnome/shell/theme。写回前先install -m 0644 -o root -g root，不要用cp覆盖后忘记权限。

3.3 参数设计：图片路径、备份目录、恢复开关与 dry-run

参数设计要围绕“可试跑、可回滚、可指定”三个目标。图片路径必填，恢复模式除外；备份目录可改，方便批量装机把备份放到数据盘；恢复开关只取最近一份备份；dry-run 只打印探测结果和将执行的命令，不写系统文件。下面这张表是脚本对外暴露的主要参数。

参数解析可以用getopts或while case，脚本里用后者更直观。--dry-run要打印四类信息：探测到的 gresource 路径、CSS 中解析出的背景资源名、备份将写入的完整路径、编译命令的完整参数。这样即使不执行，也能看出脚本有没有找错主题。--restore不应该要求--image，否则恢复流程多一步；恢复逻辑是取备份目录下按时间排序最新的gnome-shell-theme.gresource.*，复制回原路径，再提示重启gdm3。如果备份目录为空，直接报错退出，不能猜。

4. 照着执行：用脚本替换登录背景的完整命令与参数说明

4.1 准备一张符合 GDM 分辨率的图片

先准备图片，不要直接拿一张 4K 照片就往里塞。GDM 登录界面在不同机器上分辨率不同，常见是 1920×1080，也有 2560×1440 或 2K 屏。图片比例不对会被拉伸，或者只显示局部。比较稳妥的做法是按目标屏幕分辨率做居中裁剪，输出 PNG，去掉元数据，文件控制在 2 MB 以内。如果机器上装了 ImageMagick，可以用下面这条命令处理；没有装也不影响脚本使用，手动导出 PNG 即可。

mkdir -p ~/gdm-bg convert ~/Pictures/wallpaper.jpg \ -resize 1920x1080^ \ -gravity center \ -extent 1920x1080 \ -strip \ ~/gdm-bg/login-bg.png

-resize 1920x1080^表示短边也至少铺满 1920×1080，避免留白；-gravity center把裁剪焦点放中间；-extent 1920x1080强制输出目标画布；-strip去掉 EXIF 等元数据，减小文件体积。参数上，1920×1080 要按实际屏幕改，比如 2560×1440。如果图片里有文字或 logo，不要用自动裁剪，手工在图像工具里对齐安全区，登录输入框通常在屏幕中下方，背景太花会影响输入框可读性。

注意：登录背景不是桌面壁纸，图片太亮或对比度太低会让用户名和密码框看不清。选图时把输入框区域留暗一点，现场验收会少很多返工。

4.2 首次执行：带 dry-run 的试跑与正式替换

脚本拿到手后先赋执行权限，然后带--dry-run跑一遍。dry-run 不会写系统文件，但会走探测和解析逻辑，能提前暴露“找不到 gresource”“CSS 里没有图片 URL”“备份目录不可写”等问题。

chmod +x ./set-gdm-background.sh sudo ./set-gdm-background.sh --dry-run -i ~/gdm-bg/login-bg.png

这段命令里，chmod +x给脚本执行权限；sudo是必须的，因为要读/usr/share/gnome-shell并写备份目录；--dry-run只打印；-i指定图片。dry-run 输出里重点看三行：theme=后面的 gresource 路径是不是你期望的 Yaru 主题；background resource=后面的文件名是不是 CSS 里真实引用的资源；backup=后面的目录有没有写权限。如果路径不对，用-t手动指定，不要硬跑。

确认无误后去掉--dry-run正式执行。下面这条命令同时指定了备份目录，适合把备份放到独立数据盘或运维保留目录。

sudo ./set-gdm-background.sh \ -i ~/gdm-bg/login-bg.png \ -b /var/backups/gdm-background

正式执行时，脚本会先备份原 gresource，再解包到临时工作目录，替换 CSS 指向的图片资源，重新编译，最后写回原路径。参数上，-i是输入图片，-b是备份目录；如果省略-b，使用默认值。执行过程中不要 Ctrl+C 中断，尤其在写回阶段，中断可能留下不完整的 gresource。脚本应该在写回前先编译到临时文件，校验文件非空、gresource list能读，再原子替换；如果编译失败，原文件不动。

提示：正式执行前开一个 TTY（Ctrl+Alt+F3）并登录，确认自己能回来。重启gdm3会注销当前图形会话，远程 SSH 直接重启可能让你失去连接。

4.3 生效验证：重启 gdm、查看日志与回滚

写回后需要重启 GDM3 才能看到效果。执行下面三条命令，先重启，再看服务状态，最后看日志。

sudo systemctl restart gdm3 systemctl status gdm3 --no-pager journalctl -u gdm3 -b --no-pager | tail -n 50

systemctl restart gdm3会重启登录管理器，当前图形会话会被注销；systemctl status看服务是不是active (running)；journalctl -u gdm3 -b看本次启动的 GDM 日志，tail -n 50只看最后 50 行。日志里如果出现Failed to load resource、Error loading theme、JS ERROR，大概率是 gresource 编译或资源名有问题。此时不要反复重启，直接进 TTY 回滚。

回滚用脚本的--restore，它会取备份目录里最新一份 gresource 复制回原路径，然后重启 GDM3。

sudo ./set-gdm-background.sh --restore sudo systemctl restart gdm3

--restore不需要-i，因为它只恢复主题文件；systemctl restart gdm3让恢复生效。如果脚本本身也跑不起来，手动回滚：进 TTY，用ls -1t /var/backups/gdm-background/gnome-shell-theme.gresource.* | head -n1找最新备份，cp -a回原路径，再重启。手动回滚时一定要确认目标路径和备份文件大小，不要复制成 0 字节文件。

5. 避坑与排查：登录背景替换后黑屏、循环登录、图片不显示的 5 个原因

5.1 现象一：重启后登录界面黑屏只剩鼠标

现象是重启后看不到登录框，只有鼠标指针，按 Ctrl+Alt+F3 能进 TTY。原因通常是 gresource 编译时 manifest 前缀写错，CSS 引用的resource:///org/gnome/shell/theme/xxx.png在包里找不到；或者写回后文件权限不是 0644，gdm用户读不到；也可能是编译过程被中断，生成了不完整文件。解决顺序是先回滚，再检查资源清单，不要在原文件上继续编译。

last=$(ls -1t /var/backups/gdm-background/gnome-shell-theme.gresource.* | head -n1) sudo cp -a "$last" /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource sudo systemctl restart gdm3

这段命令用ls -1t按时间倒序列出备份，head -n1取最新一份，cp -a保留属性复制回原路径。参数上，目标路径要按detect_theme实际探测结果改，不要无脑抄 Yaru 路径。回滚后如果 GDM 恢复，说明问题在编译或资源名；用gresource list对比原文件和备份文件的资源列表，重点看gnome-shell.css和背景图片是否都在。

5.2 现象二：图片被拉伸或只显示局部

现象是登录背景变形，或者只显示图片中间一块。原因一般不是脚本编译错，而是图片比例和 GDM 的background-size不匹配。GNOME Shell 主题里锁屏背景常用cover或固定尺寸，图片比例和屏幕不一致时就会裁剪或拉伸。解决方法是按目标分辨率做居中裁剪，而不是把任意比例图片直接缩放。

convert ~/Pictures/wallpaper.jpg \ -resize 2560x1440^ \ -gravity center \ -extent 2560x1440 \ -strip \ ~/gdm-bg/login-bg-2k.png

-resize 2560x1440^保证短边铺满，-extent裁成精确画布，-gravity center控制裁剪位置。参数上，2560×1440 只是示例，按实际屏幕改；如果机器是 1920×1080，就用 1920×1080。不要用-resize 1920x1080!强制拉伸，感叹号会破坏比例，人像和 logo 会变形。处理完用file确认输出是 PNG，再重新跑脚本。

5.3 现象三：脚本执行成功但背景没变

现象是脚本退出码为 0，重启后登录背景还是默认紫红色。原因可能是改错了 gresource：系统实际加载的是/usr/share/gnome-shell/gnome-shell-theme.gresource，脚本却改了 Yaru 路径；也可能是 GDM 缓存了旧主题；还有可能是 CSS 里lockDialogGroup根本没引用图片，脚本替换了一个没人用的资源。排查时先确认实际文件，再确认 CSS 规则。

theme=/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource gresource extract "$theme" /org/gnome/shell/theme/gnome-shell.css \ | grep -A8 'lockDialogGroup'

gresource extract输出 CSS，grep -A8看lockDialogGroup后 8 行，确认url(...)指向的资源名。如果资源名和脚本替换的不一致，说明解析逻辑或 CSS 结构变了。缓存问题可以清理 GDM 的 GNOME Shell 缓存目录，再重启；清理前确认路径存在，不要删错用户目录。缓存不是万能药，先确认文件真的被替换，再谈缓存。

5.4 现象四：系统更新后背景被还原

现象是某次apt upgrade后登录背景变回默认。原因是gnome-shell包更新时覆盖了/usr/share/gnome-shell/theme/.../gnome-shell-theme.gresource。这不是脚本失效，而是改包内文件的正常代价。排查可以用dpkg -S查文件归属，确认它属于哪个包，更新后重新执行脚本即可。

dpkg -S /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource

dpkg -S输出包名和文件路径，例如属于gnome-shell-common或yaru-theme-gnome-shell之类的包。参数上，路径按实际主题文件改。知道归属后，批量装机可以把“系统更新后重跑登录背景脚本”写进交付清单；个人机器可以保留备份目录，更新后先跑--dry-run再正式替换。不要试图用chattr +i锁文件，包管理器升级时可能报错，后续维护更麻烦。

5.5 现象五：恢复备份后 GDM 无法启动

现象是回滚后 GDM 还是起不来，或者服务状态不断重启。原因可能是备份文件本身不完整、复制时权限或属主不对、恢复到了错误路径，或者备份来自旧版本gnome-shell，和当前包不匹配。解决方法是先用包管理器恢复原版主题文件，再重启 GDM3，不要继续在备份文件上打转。

pkg=$(dpkg -S /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource | cut -d: -f1) sudo apt install --reinstall "$pkg" sudo systemctl restart gdm3

dpkg -S找到文件所属包，cut -d: -f1取冒号前的包名，apt install --reinstall重装该包，把主题文件恢复成发行版原版。参数上，路径要按实际文件改；如果dpkg -S报“没有找到”，说明文件不是包管理器装的，需要从同版本系统复制一份。重装后先重启 GDM3 验证，再考虑重新换背景。这个流程比反复覆盖备份稳，血泪经验是：备份只能救“改坏”，救不了“版本不匹配”。

6. 进阶用法：把登录背景纳入装机流程与批量验证

把登录背景纳入装机流程时，不要只检查脚本退出码。退出码为 0 只能说明脚本没报错，不能说明 gresource 真的被替换。更稳的验证是记录替换前后的校验和，再确认资源列表里背景资源存在。下面这段命令用于生成校验和并对比备份。

theme=/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource sha256sum "$theme" ls -1t /var/backups/gdm-background/gnome-shell-theme.gresource.* | head -n1

sha256sum输出当前文件哈希，和备份文件的哈希对比，能确认写回是否发生；ls -1t找最新备份。批量部署时，我一般把参数固定成模板：-i /opt/gdm-bg/login-bg.png -b /var/backups/gdm-background，图片随镜像分发，备份目录单独保留。执行前统一跑--dry-run，把输出里的theme=和background resource=收进日志，出问题能定位到哪台机器改错了路径。

最后一个习惯：每次改 gresource 前先sha256sum存一份，再开一个 TTY 放着，确认能回滚才重启gdm3。从那以后我每次做登录背景替换，都强制走一遍--dry-run、备份、TTY 验证、重启四步，不再相信“编译成功就等于生效”。希望帮到你。

本文还有配套的精品资源，点击获取