简介面向 Ubuntu 22.04 及以上版本、希望自定义 GDM 登录界面背景的用户与运维人员这份下载包提供一套可执行的脚本方案重点应对新版 GDM 配置方式变化后旧方法失效的问题适合具备基础 Linux 权限与命令行操作能力的读者参考使用。压缩包共 10 个文件约 20KB以 3 个 sh 脚本为核心并配有可执行脚本、透明背景变体、README 说明及 LICENSE 等辅助内容按系统版本区分 pre-23 与 post-23 两类处理路径另含透明背景分支便于快速判断适用场景与效果差异。目前已有 1136 人学习。读者可获得可直接运行的登录背景设置工具、不同 Ubuntu 版本下的适配思路以及透明效果变体和说明文档方便在理解脚本结构后按需调整与验证。整体体积轻量目录组织围绕设置脚本、版本适配与说明授权展开适合作为登录界面美化的参考工具包。1. 登录背景改不动先看清 GDM3 已经把控制权收走了Ubuntu 22.04 往上几个版本改登录背景这件事比 20.04 那一代麻烦了一截。老办法是往/etc/gdm3/greeter.dconf-defaults里写个picture-uri重启 gdm3 就能看到新图现在这么干大概率没反应登录界面还是那块深紫色。原因不复杂GNOME 42 之后 GDM3 的 greeter 就是一个完整的 gnome-shell 进程以gdm用户身份跑在--modegdm下它的样式全部来自编译好的gresource主题包你在文件系统里丢一张 png 进去shell 根本不会去读。所以真正要动的是一份二进制资源包解包、换图、改 CSS、重新编译、装回去。手动做一次大概十几步版本一多路径还会变写脚本才是正解。这篇就围绕一个可复现的 bash 脚本展开从资源定位、CSS 块级替换到回编译权限、黑屏救援把每一步的参数和失败特征都摊开讲。手上管着几台 Ubuntu 22.04 或 24.04 桌面机、想把开机第一屏换成自家图的同学可以直接照着抄已经踩过黑屏坑的重点看第 4 章。2. 主题包藏在哪gresource 拆包与结构确认2.1 greeter.dconf-defaults 为什么在 22.04 之后失灵先把这个流传最广的误区说清楚不然脚本写出来也是白写。/etc/gdm3/greeter.dconf-defaults里的[org/gnome/desktop/background]段本质上是往 gdm 用户的 dconf 数据库里写键值。在 GNOME 3.x 时代greeter 的锁屏层会用这个 uri 去渲染背景所以改了就生效。从 GNOME 42 开始Ubuntu 的 Yaru 主题在gnome-shell.css里给#lockDialogGroup显式写了background-color和background-image两条规则样式优先级压过了 dconf 的 fallback 路径。你可以自己验证一下# 看默认配置里有没有 picture-uri 示例 grep -n picture-uri /etc/gdm3/greeter.dconf-defaults # 看主题 css 里 lockDialogGroup 到底写了什么 GRES/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource gresource extract $GRES /org/gnome/shell/theme/gnome-shell.css \ | awk /#lockDialogGroup/,/}/ | head -n 12第二条命令的输出通常长这样background-color: #2c001eUbuntu 紫、background-image: url(resource:///org/gnome/shell/theme/noise-texture.png)、background-repeat: repeat。那个noise-texture.png是一张很小的噪点纹理靠 repeat 铺满全屏看起来像纯色。你就算把picture-uri指过去也会被这层纹理盖住。提示网上还有一类教程让你直接覆盖/usr/share/backgrounds/warty-final-ubuntu.png这个文件确实存在但它是桌面壁纸不是 greeter 的绘制源改了同样没效果。2.2 用 gresource list 摸清主题包的文件清单不同 Ubuntu 版本、不同主题包gresource 的路径不一样。与其背路径不如让脚本自己找。先看候选清单路径典型系统/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresourceUbuntu 22.04 / 24.04 默认 Yaru/usr/share/gnome-shell/theme/gnome-shell-theme.gresource上游 GNOME 默认主题/usr/share/gnome-shell/theme/ubuntu/gnome-shell-theme.gresource部分旧版或第三方主题包真实环境里还可能装了不止一份比如装过 gnome-shell 主题美化插件之后。稳妥的探测方式不是按路径找而是按内容找——谁包含gnome-shell.css谁就是 greeter 用的那份。#!/usr/bin/env bash # 找出所有候选 gresource并打印其中是否含 gnome-shell.css set -euo pipefail detect_gresource() { local f # 先按已知路径顺序找 for f in \ /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource \ /usr/share/gnome-shell/theme/gnome-shell-theme.gresource do if [[ -f $f ]]; then echo $f return 0 fi done # 兜底全盘搜 gnome-shell 目录下的 gresource while IFS read -r f; do if gresource list $f 2/dev/null | grep -q /org/gnome/shell/theme/gnome-shell.css$; then echo $f return 0 fi done (find /usr/share/gnome-shell -name *.gresource -type f 2/dev/null) return 1 } detect_gresource这段函数做了两层判断。第一层按 Ubuntu 已知的稳定路径找命中就直接返回速度最快。第二层用find加gresource list做内容过滤正则$锚定结尾避免匹配到gnome-shell.css之外的类似文件名。函数返回的是绝对路径后面所有命令都用这个变量不要写死。拿到路径之后列一下包里的内容心里有个数GRES$(detect_gresource) echo 使用: $GRES gresource list $GRES | head -n 40 gresource list $GRES | wc -l典型输出是一批/org/gnome/shell/theme/前缀下的资源gnome-shell.css、noise-texture.png、checkbox-off.svg、toggle-on.svg之类。注意前缀——这个/org/gnome/shell/theme/是 gresource 的 mount pointCSS 里写resource:///org/gnome/shell/theme/xxx时三个斜杠后面跟的就是它。回编译时前缀必须原样保留改一个字符CSS 里所有resource://引用全部失效表现就是登录框变白板、图标全丢。资源总数通常在几十到一百多个之间其中包括 svg 图标和 png 纹理。脚本后面要做全量解包再全量回编译不能只挑 css 和背景图两个文件塞回去否则图标资源会丢。2.3 读懂 #lockDialogGroup 那段 CSS定位到包之后把 css 抽出来单独看这一段。#lockDialogGroup是 gnome-shell 里承载登录/锁屏背景的那层 widget改背景就是改它的三条属性image、repeat、size。# 抽 css 到临时文件方便反复查看 gresource extract $GRES /org/gnome/shell/theme/gnome-shell.css /tmp/gs.css grep -n lockDialogGroup /tmp/gs.css awk /#lockDialogGroup/,/^}/ /tmp/gs.css用awk的范围匹配比grep -A可靠因为grep -A给的行数是拍脑袋定的不同版本这段块的属性数量不一样给少了看不全给多了会把后面的规则也带出来。范围匹配到第一个右花括号就停一般够用。看到原块之后要改的东西其实只有三处background-image换成新图的resource:///地址文件名自己定比如login-bg.pngbackground-repeat从repeat改成no-repeat否则图片会像瓷砖一样铺满补一条background-size: cover让图片等比缩放填满屏幕不留黑边。background-color建议保留原来的深色它的作用是图片加载失败时的兜底色删了万一图片资源缺失登录界面就是一片白什么都看不清那时候只能进 TTY 救场。注意不要只替换noise-texture.png的内容而不改 CSS。那张纹理是几十像素见方的小图被repeat平铺你换成一张 1920×1080 的照片结果就是满屏缩略图看起来很怪而且图片体积会撑大整个 gresource。3. 把改动写成脚本从备份到重编译 gresource3.1 脚本骨架参数、依赖检查和幂等设计整脚本分四段解析参数、检查依赖、备份、处理与安装。先搭骨架把最容易被忽略的幂等性放在最前面考虑——同一个脚本会被跑第二次、第三次每次换一张图如果备份逻辑写错回滚能力就废了。#!/usr/bin/env bash set -euo pipefail BG_IMG${1:-} TARGET_RES${2:-1920x1080} ACTION${3:-apply} BACKUP_DIR/var/backups/login-bg WORK$(mktemp -d /tmp/login-bg.XXXXXX) trap rm -rf $WORK EXIT die() { echo [错误] $* 2; exit 1; } [[ $EUID -eq 0 ]] || die 需要 root 权限运行 [[ -n $BG_IMG ]] || die 用法: $0 背景图路径 [分辨率 例如 1920x1080] [restore]参数用位置参数而不是getopt因为一共就三个getopt那套--long解析在单文件脚本里属于过度设计还容易在set -u下踩空变量的坑。默认分辨率给 1920×1080 是个折中后面 3.2 会讲怎么让它自动取。trap里清理临时目录这句很关键——脚本中途失败比如convert报错退出时工作目录会被清掉不会在/tmp里堆一堆解包出来的主题文件。BACKUP_DIR特意放在/var/backups下而不是/tmp因为/tmp在部分系统上配置了开机清理备份丢了就再也回不去了。依赖检查单独写个函数need() { command -v $1 /dev/null 21 || die 缺少命令 $1请先安装对应软件包 } need gresource need glib-compile-resources need convert need python3gresource和glib-compile-resources来自libglib2.0-binconvert来自imagemagick这两个在 Ubuntu 桌面版上通常已经存在最小化安装可能没有。用command -v而不是which因为which在某些精简环境里没有而且退出码行为不一致。装依赖这一步不放进脚本自动做避免脚本在无人值守环境下突然触发 apt 锁。3.2 图片预处理分辨率对齐与格式选择greeter 的显示效果对图片尺寸非常敏感。给一张 4K 图gnome-shell 启动时要解码登录会变慢给一张 800×600 的图cover拉伸之后人脸就糊了。我一般按目标屏幕分辨率裁切格式固定用 png。convert $BG_IMG \ -resize ${TARGET_RES}^ \ -gravity center \ -extent $TARGET_RES \ -strip \ -define png:compression-level9 \ $WORK/login-bg.png参数逐个说。-resize ${TARGET_RES}^里的脱字符表示「按短边填满」即等比缩放到至少覆盖目标尺寸可能有一边超出。-gravity center -extent接着把超出的部分从中心裁掉得到精确的目标分辨率不变形。-strip去掉 EXIF、ICC 等元数据一张手机拍的照片能因此小几百 KB。png:compression-level9是 zlib 的最高压缩级别多花一点 CPU 换体积对一张图来说可以忽略。如果原图本身比例和目标分辨率差别很大比如竖版图配横屏cover裁切会切掉主体的上半部分或下半部分。这种情况我一般建议先把原图手工裁成 16:9 再喂给脚本比在脚本里猜构图靠谱。分辨率来源可以考虑从当前桌面读detect_res() { if command -v xrandr /dev/null 21 [[ -n ${DISPLAY:-} ]]; then xrandr --current | awk /\*/{print $1; exit} else echo 1920x1080 fi }xrandr只在 X11 会话下可用Wayland 下会报错或者返回空串所以外面套一层command -v和DISPLAY判断都不满足就退回默认值。真要在 Wayland 下取分辨率得走gdbus查 Mutter 的显示配置代码量翻倍收益不大——登录界面本来就是多用户场景写死一个主流分辨率反而更省心。3.3 改 CSS块级替换比 sed 全文件替换稳这一步是整个脚本里最容易写崩的地方。很多人用sed -i s/background-image:.*/.../一把梭问题在于 css 里background-image不止出现一次滚动条、按钮、下拉框都在用全量替换之后登录框的按钮会莫名其妙没背景。正确做法是把#lockDialogGroup { ... }整个块抠出来替换。用 python 写正则的非贪婪匹配加上count1足够安全#!/usr/bin/env python3 import pathlib import re import sys css_path pathlib.Path(sys.argv[1]) css css_path.read_text(encodingutf-8) new_block #lockDialogGroup { background-color: #2c001e; background-image: url(resource:///org/gnome/shell/theme/login-bg.png); background-repeat: no-repeat; background-size: cover; } pattern re.compile(r#lockDialogGroup\s*\{[^}]*\}, re.S) if pattern.search(css): css pattern.sub(new_block, css, count1) action replaced else: css css \n new_block \n action appended css_path.write_text(css, encodingutf-8) print(flockDialogGroup {action})正则[^}]*匹配块内所有非右花括号字符天然在第一个}处停下不需要处理嵌套——css 的声明块本来就不嵌套。re.S让.能匹配换行其实这里没用到点号加不加无所谓保留是习惯。count1防的是同一份 css 里出现多个同名选择器媒体查询里偶尔会有只改第一个主块。找不到块时追加到文件末尾这个分支保证幂等第二次运行时正则能匹配到上次写入的块走替换分支就算某个版本把#lockDialogGroup重命名了追加的那块也不会生效但至少不会破坏原文件。background-color写死成 Ubuntu 紫是为了兜底如果你换的主题不是这个色系改成自己的深色值就行它只在图片加载失败时露脸。这个 python 片段在 bash 里通过 heredoc 内联调用省得脚本拆成两个文件python3 - $WORK/extract/org/gnome/shell/theme/gnome-shell.css PY # 上面那段 python 代码原样放这里 PYPY带单引号heredoc 内容不做变量展开$和反引号原样传给 python避免 bash 提前吃掉。这个细节不注意的话${TARGET_RES}之类的字符串会被替换成空调试半天找不到原因。3.4 回编译 gresource 与安装权限资源包解包出来之后要把它们重新编成一个二进制.gresource。glib-compile-resources要一份 XML 清单描述前缀和文件列表。手写清单不现实用find生成PREFIX/org/gnome/shell/theme cd $WORK/extract find . -type f -printf %P\n | sort $WORK/files.txt { echo ?xml version1.0 encodingUTF-8? echo gresources echo gresource prefix\$PREFIX\ while IFS read -r f; do echo file$f/file done $WORK/files.txt echo /gresource echo /gresources } $WORK/theme.gresource.xml%P是find的格式符输出相对于起始点的路径正好是file标签需要的相对路径。sort让清单稳定方便 diff 两次运行的差异。PREFIX必须和原包一致前面用gresource list的输出确认过直接从那里取也行PREFIX$(gresource list $GRES \ | grep /org/gnome/shell/theme/gnome-shell.css$ \ | sed s#/gnome-shell.css$##)这样写更保险不依赖人工抄写。sed的#作分隔符是因为路径里有斜杠用/得转义一长串。编译和安装glib-compile-resources \ --sourcedir$WORK/extract \ --target$WORK/gnome-shell-theme.gresource \ $WORK/theme.gresource.xml install -o root -g root -m 0644 \ $WORK/gnome-shell-theme.gresource $GRES--sourcedir指定文件基准目录XML 里的相对路径都相对它解析。install一行同时做三件事复制、设属主、设权限。gresource 必须是root:root且0644权限不对或者属主是普通用户gdm 读不到就会退回默认主题甚至黑屏这一点在第 4 章还会展开。安装完成后立刻做一次静态校验通过再提示重启gresource list $GRES | grep -q login-bg.png$ || die 新图未进入资源包 gresource extract $GRES $PREFIX/login-bg.png /dev/null || die 资源无法提取 echo 安装成功运行 systemctl restart gdm3 查看效果grep -q只看退出码不打印输出|| die在失败时立刻终止并给出可读的错误。两步都通过基本可以确定资源包是完好的重启之后不会黑屏。4. 避坑与排查黑屏、紫屏、登录框消失的几种情况4.1 重启 gdm3 之后整屏黑只剩一个鼠标指针现象执行systemctl restart gdm3屏幕闪一下变黑鼠标能看见但不动等一两分钟也没有登录框。原因gnome-shell 在 greeter 模式下加载主题失败时进程会直接退出systemd 反复拉起又反复退出表现出来就是黑屏。最常见的触发点是 gresource 的属主或权限不对其次是 XML 里漏了文件、编译过程本身报错但被set -e之外的管道吞掉。解决切到 TTYCtrlAltF3用备份还原然后核对权限。ls -l /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource # 期望 root root 644不是的话 chown root:root /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource chmod 0644 /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource journalctl -b -u gdm3 --no-pager | grep -iE theme|fail|error | tail -n 20日志里出现Failed to load theme、Unable to load resource之类的行基本就是这个原因。脚本里那句install -o root -g root -m 0644就是为这个场景准备的别用cp代替。4.2 登录框出来了背景还是紫色没变现象重启后登录界面正常显示用户名输入框也在但背景纹丝不动还是原来那块噪点纹理。原因改错文件了。系统里同时存在多份 gresourcegreeter 实际加载的是Yaru目录下那份你改的是/usr/share/gnome-shell/theme/gnome-shell-theme.gresource。另一个可能是桌面主题切成过Yaru-dark或第三方主题greeter 跟着换了资源包。解决逐份确认哪个包里含gnome-shell.css再看 greeter 实际用的是哪份find /usr/share/gnome-shell -name *.gresource -type f \ -exec sh -c echo $1; gresource list $1 | grep -c gnome-shell.css _ {} \; gsettings get org.gnome.desktop.interface gtk-theme第一条命令列出每个包里gnome-shell.css出现的次数正常的主题包恰好一次。第二条看当前桌面主题greeter 默认跟随它。如果输出是Yaru-dark那就去/usr/share/gnome-shell/theme/Yaru-dark/下找对应的 gresource别在 Yaru 那份上折腾。4.3 第二次运行脚本换图回滚之后还是改过的图现象第一次改完不满意再跑一次脚本换第二张图之后想恢复原状执行 restore 发现登录界面还是第一张自定义图。原因备份逻辑写成了「运行前把当前文件 cp 一份到.bak」。第二次运行时当前文件已经是第一次改过的版本.bak被覆盖原始文件就永久丢了。解决备份只在原文件不存在时才创建用.orig后缀区分同时留一条dpkg重装的兜底路径。ORIG$BACKUP_DIR/gnome-shell-theme.gresource.orig mkdir -p $BACKUP_DIR if [[ ! -f $ORIG ]]; then cp -a $GRES $ORIG echo 已保存原始备份: $ORIG else echo 原始备份已存在跳过 fi万一备份真的丢了查文件归属之后重装对应包也能还原dpkg -S $GRES # 输出形如 yaru-theme-gnome-shell: /usr/share/.../gnome-shell-theme.gresource apt install --reinstall yaru-theme-gnome-shelldpkg -S的输出以实际系统为准不同版本包名可能不同照着输出装就行。4.4 24.04 上脚本报「找不到 gresource」现象同一份脚本在 22.04 上跑得好好的换到 24.04 直接die提示找不到资源包。原因候选路径里写死了 22.04 的 Yaru 路径24.04 改了主题目录结构或者系统装的是精简版没有 Yaru 包。解决不要只依赖路径硬编码把 2.2 里那套「按内容探测」的逻辑做成主路径。再加一条人工确认的检查GRES$(detect_gresource) || die 未找到任何含 gnome-shell.css 的 gresource echo 探测到: $GRES gresource list $GRES | grep -q /org/gnome/shell/theme/ || die 前缀不符合预期第二行检查前缀避免选到一个结构完全不同的第三方主题包那种包改完之后登录界面会缺图标。前缀检查通过再往下走比改完再回滚省事。4.5 图显示出来了但被拉伸或者重复平铺现象背景确实换成了自己的图但人物被拉长或者同一张图在屏幕上出现了好几块。原因css 里background-repeat还是repeat或者background-size没写浏览器引擎默认按图片原始像素尺寸渲染再平铺。解决确认#lockDialogGroup块里三行同时存在。抽出来看gresource extract $GRES $PREFIX/gnome-shell.css \ | awk /#lockDialogGroup/,/^}/输出应该是background-repeat: no-repeat和background-size: cover都在。少了任何一条回去检查 3.3 的 python 替换逻辑——大概率是正则没匹配上走了追加分支追加的块排在文件末尾被前面的原块压住看起来像是没生效。5. 验证与回滚不动图形会话先确认资源包没问题5.1 不重启 gdm3 的静态验证改完直接重启 gdm3如果坏了就得进 TTY来回折腾。养成习惯先做三组静态检查全部通过再重启。这三组检查覆盖资源清单、CSS 块、图片本身基本能拦住九成以上的翻车。GRES/usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource PREFIX/org/gnome/shell/theme # 1. 新图和 css 都在清单里 gresource list $GRES | grep -E login-bg\.png$|gnome-shell\.css$ # 2. css 里的块内容正确 gresource extract $GRES $PREFIX/gnome-shell.css \ | awk /#lockDialogGroup/,/^}/ # 3. 图片能正常提取且尺寸正确 gresource extract $GRES $PREFIX/login-bg.png /tmp/check-bg.png identify /tmp/check-bg.png第一组的grep -E用|做或匹配两个文件都得在少一个就说明 xml 生成时漏了。第二组看输出里background-size: cover是否存在。第三组用 ImageMagick 的identify打印尺寸和格式输出形如PNG 1920x1080格式不是 PNG 就要回头查convert那一步。还有个容易忽略的点资源包的文件大小。原包通常几百 KB加了图之后涨到一两 MB 正常如果突然变成十几 MB说明图片没压或者解包时把无关文件也塞进去了登录会明显变慢。du -h $GRES把这条和原备份对比一下就能看出来du -h /var/backups/login-bg/gnome-shell-theme.gresource.orig两个数字相差在合理范围内再往下走。5.2 一次真实的重启演练与日志检查静态检查通过之后才重启。重启 gdm3 会终止当前图形会话所有没保存的窗口全丢所以先在 SSH 或 TTY 里操作别在图形界面的终端里直接敲。# 从 TTY 或 SSH 执行先确认没有前台任务在跑 systemctl restart gdm3 # 等两三秒确认服务活着 systemctl is-active gdm3 # 看最近日志里有没有主题相关的报错 journalctl -b -u gdm3 --no-pager | tail -n 40systemctl is-active返回active只代表进程在跑不代表主题加载成功最后还是得回图形界面看一眼登录框。日志里如果出现JS ERROR或者Failed to load按第 4 章对应条目排查。演练时有个小技巧先在 TTY 里把回滚命令准备好粘贴在终端但别回车登录界面确认没问题再清掉。真黑屏了切回 TTY 直接回车就能救回来比现敲命令省时间。5.3 回滚脚本与救援兜底回滚要能一条命令完成而且不依赖脚本的其他分支。单独写一个函数只做三件事校验备份存在、装回去、重启 gdm3。restore_theme() { local orig$BACKUP_DIR/gnome-shell-theme.gresource.orig [[ -f $orig ]] || die 备份不存在: $orig install -o root -g root -m 0644 $orig $GRES echo 已还原: $GRES # 静态确认还原后资源包可读 gresource list $GRES /dev/null || die 还原后的资源包损坏 systemctl restart gdm3 }先install再校验再重启顺序不能换。gresource list对损坏的包会返回非零退出码用它当还原后的健康检查很合适比肉眼比对文件大小靠谱。最坏的情况是 TTY 也进不去比如改了/etc/gdm3/custom.conf里的 Wayland 开关又没配对配置图形和文本都起不来。这时候只能上安装 U 盘挂载根分区之后 chroot 还原# 在 U 盘启动的 live 环境里假设根分区是 /dev/nvme0n1p2 mount /dev/nvme0n1p2 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt # chroot 之后用备份覆盖回去 cp -a /var/backups/login-bg/gnome-shell-theme.gresource.orig \ /usr/share/gnome-shell/theme/Yaru/gnome-shell-theme.gresource exit umount -R /mnt reboot分区名用lsblk -f自己确认别照抄。这套流程真正用到的时候不多但备份目录必须放在/var/backups而不是/tmp就是为它留的后路——/tmp在部分发行版配置里是 tmpfs重启即清空。6. 进阶多分辨率、锁屏背景与一键分发6.1 高分屏和倾斜分辨率怎么出图background-size: cover的行为是按屏幕逻辑分辨率等比缩放2K/4K 屏上喂 1920×1080 的图会被放大边缘发糊。我一般出两倍图分辨率参数传3840x2160然后用 pngquant 压一遍把体积从五六 MB 压到 1 MB 以内视觉上看不出差别。convert $BG_IMG -resize 3840x2160^ -gravity center -extent 3840x2160 \ -strip $WORK/login-bg.png pngquant --quality80-95 --force --output $WORK/login-bg.png $WORK/login-bg.pngpngquant是有损压缩--quality80-95是质量区间低于 80 会明显掉色高于 95 压不动体积。它来自pngquant包不是默认安装的依赖检查里记得加上need pngquant。多屏环境下GDM 会为每块屏各自计算cover宽屏加竖屏的组合里同一张 16:9 图在竖屏上只能显示中间一条。真要适配得给#lockDialogGroup加媒体查询按aspect-ratio换不同背景图代码量不小一般企业桌面统一型号的话没必要做。6.2 把参数收敛成配置文件脚本跑顺之后命令行参数就有点多余了。把常用配置写到/etc/login-bg.conf脚本里source进来分发到多台机器时只改这一个文件# /etc/login-bg.conf BG_IMG/srv/assets/login-bg.png TARGET_RES3840x2160 BACKUP_DIR/var/backups/login-bg脚本里加一行[[ -f /etc/login-bg.conf ]] source /etc/login-bg.conf位置放在参数解析之后让命令行参数优先于配置文件。这样单机调试还能临时覆盖批量部署时又不用带一长串参数。6.3 分发时的版本判定跨版本批量部署最容易翻车的是路径和前缀。我的做法是在脚本开头跑一次「探测 记录」把探测结果写进日志出问题直接看日志定位{ echo date$(date -Is) echo host$(hostname) echo gresource$GRES echo prefix$PREFIX echo res$TARGET_RES } /var/log/login-bg.loghostname和date是为了多机排查时能对上号。日志追加而不是覆盖出过几次事之后就能从历史记录里看出是哪次改动引入的问题。最后说个教训。早期我给一台机器改登录背景图省事跳过了静态验证直接systemctl restart gdm3结果 gresource 的属主被cp改成了普通用户greeter 起不来屏幕黑着。那台机器在机房没有 KVM最后是让人过去接显示器进的 TTY。从那以后我每次改 gresource 都强制走一遍三组静态检查加install -o root -g root -m 0644重启前再把回滚命令贴在另一个终端里。多花两分钟换的是不用跑机房。希望帮到你。本文还有配套的精品资源点击获取
