{ "source_file": "0930", "source_platform": "Dev.to", "author": "xbill", "title_listed": "The Desktop Looked Right: 2,093 Parse Errors a Boot, and 10.9 Seconds That Weren't Doing Anything", "keywords": "", "domain": "大模型算法", "content_type": "工程实践", "is_paid_flag": "否", "url": "https://dev.to/gde/the-desktop-looked-right-2093-parse-errors-a-boot-and-109-seconds-that-werent-doing-anything-4bb", "publish_date": "2026-09-08", "corpus_stage": "", "notes": "", "id": "26c637d5ebd3", "collected_at": "2026-10-02T13:51:40", "title": "The Desktop Looked Right: 2,093 Parse Errors a Boot, and 10.9 Seconds That Weren't Doing Anything - DEV Community", "body_markdown": "This article walks through one afternoon of Debian system management, in which the machine turned out to have been reporting two of its own defects continuously, for as long as it had been configured, to nobody.\nDebian tells you almost everything. It just does not tell you on screen.\nThe kernel ring buffer, the systemd journal,\nsystemd-analyze\n,\ndpkg\n,\napt-cache policy\nand\n/sys\nbetween them describe the state of the machine in far more detail than any settings panel — and a desktop can look completely correct while those sources are recording a failure a few hundred times a minute.\nWhat that gap creates is a feedback loop with a missing half. The machine emits the evidence; nothing reads it. The two defects below had both been present since the day the setup script was written, both were sitting in plain text in the journal, and neither was discoverable from the desktop:\nThe GTK theme was\ndiscarded at parse time\n, 161 rules per application launch,\n2,093 log lines in the boot I measured\n, while reporting success and looking\napproximately right.\n10.9 seconds of a 39.3-second boot\nwere spent waiting for something nothing\nwas waiting for.\nBoth were introduced by\nflex\n, the script in this repository whose job is to configure the machine:\nhttps://github.com/xbill9/chromeos-boot\nThe Machine\nOne laptop, measured on 2026-09-08:\nHardware\nLenovo Yoga 9i, Intel CometLake-H, NVIDIA GTX 1650 Ti Mobile\nOS\nDebian 13 (trixie)\nKernel\n7.1.8+deb13-amd64\n(from\ntrixie-backports\n)\nDesktop\nGNOME 48, Wayland, gdm3\nGTK\nlibgtk-4-1\n4.18.6\n,\nlibadwaita-1-0\n1.7.6\nThat GTK version is the whole article, and nothing on the desktop ever mentions it.\nAt This Point You Should Have\nA Debian desktop you have customised with something — a script, a dotfile\nrepo, a settings panel, an afternoon of\ngsettings\n— and that appears to work\nsudo\n, or membership of\nadm\n/\nsystemd-journal\n.\nCheck this first\n, for\nreasons in Step 0\nsystemd-analyze\n,\njournalctl\n,\ndpkg\n,\napt-cache\n— all base install\nSomewhere durable to write findings that is not your shell scrollback\nNone of the diagnosis below changes anything. Steps 0 through 3 are reads.\nStep 0 — Find Out Whether You Can Read the Evidence At All\nThis step exists because the investigation nearly started with a wrong answer.\nThe first\njournalctl\nrun reported four errors this boot, all of them GNOME session scopes failing to start, and that looked like the whole picture. It was not the whole picture. It was the picture available to an unprivileged user:\nid\nEnter fullscreen mode\nExit fullscreen mode\nuid=1000(xbill) gid=1000(xbill) groups=1000(xbill),24(cdrom),25(floppy),\n27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev),\n102(scanner),106(bluetooth),108(lpadmin),989(docker),992(render)\nEnter fullscreen mode\nExit fullscreen mode\nNo\nadm\n, no\nsystemd-journal\n.\nWithout either,\njournalctl\nsilently narrows to your own user journal rather than refusing — you get output, it is correctly formatted, and it is a small fraction of what happened. The kernel buffer is closed off separately:\ndmesg |\ntail\n-3\nEnter fullscreen mode\nExit fullscreen mode\ndmesg: read kernel buffer failed: Operation not permitted\nEnter fullscreen mode\nExit fullscreen mode\nThe difference between the two views on this machine:\nView\nerr\nand above, this boot\nUnprivileged\njournalctl\n4\nsudo journalctl\n17\nFour against seventeen, and nothing in the first view indicates the other thirteen exist.\nA loop that reads a filtered log converges on a wrong answer confidently\n, which is worse than not reading it. Add yourself to\nadm\nand log back in, or accept that everything downstream needs\nsudo\n— but decide it deliberately, because the failure mode is silence, not an error.\nStep 1 — Count Before You Read\nerr\nand above is where people look, and on this machine it was almost entirely a red herring. The volume was one priority down:\nsudo\njournalctl\n-b\n-p\nerr\n--no-pager\n-q\n|\nwc\n-l\nsudo\njournalctl\n-b\n-p\nwarning\n--no-pager\n-q\n|\nwc\n-l\nEnter fullscreen mode\nExit fullscreen mode\n17\n1032\nEnter fullscreen mode\nExit fullscreen mode\nA thousand warnings is too many to read, so collapse them into shapes first. Normalising the numbers and hex out of each message turns a thousand lines into a histogram of distinct problems:\nsudo\njournalctl\n-b\n-p\nwarning\n--no-pager\n-q\n-o\ncat\n\\\n|\nsed\n's/[0-9a-f]\\{8,\\}/HEX/g; s/[0-9]\\+/N/g'\n\\\n|\nsort\n|\nuniq\n-c\n|\nsort\n-rn\n|\nhead\n-5\nEnter fullscreen mode\nExit fullscreen mode\n795 Theme parser error: libadwaita.css:N:N-N: Unknown @ rule\n 27 blacklist: Duplicate blacklisted hash bin:HEX\n 24 Can't update stage views actor unnamed [StBin] is on because it needs an allocation.\n 10 Theme parser error: libadwaita-tweaks.css:N:N-N: Unknown @ rule\n 7 Unable to get default source\nEnter fullscreen mode\nExit fullscreen mode\n805 of the 1,032 warnings on this system were one defect.\nIt had never appeared on screen, in any settings panel, or in the output of the script that caused it — which had reported, and still reports, success.\nStep 2 — Attribute the Message Before You Believe the Field\nThe obvious next question is which program is producing them, and the obvious way to ask is the journal's own\n_COMM\nfield. That gives a wrong answer, and it is worth showing because the same trap applies to any log the agent will read.\n1288 cat\n 322 gnome-control-c\n 161 gnome-software\n 161 xdg-desktop-por\n 161 mutter-x11-fram\nEnter fullscreen mode\nExit fullscreen mode\ncat\nis not a GTK application and does not parse stylesheets. Pulling one of those 1,288 records apart explains it:\n_COMM=cat _PID=11105 _EXE=/usr/bin/cat\nMESSAGE=(chrome:11097): Gtk-WARNING **: 09:20:36.757: Theme parser error: ...\nEnter fullscreen mode\nExit fullscreen mode\nThe webapp launchers this repository installs pipe their stderr, so journald attributes the line to the process that\nwrote\nit rather than the process that\nproduced\nit. The real emitter is in the message payload, in the\n(name:pid)\nprefix that GLib puts there.\nThe structured field describes the plumbing; the unstructured payload describes the event.\nGrouping by\n_COMM\ncredits 1,288 parse errors to\ncat\nand hides Chrome entirely. Parse the prefix instead:\nsudo\njournalctl\n-b\n-q\n-o\ncat\n|\ngrep\n\"Theme parser error: libadwaita\"\n\\\n|\nsed\n-E\n's/^\\(([a-zA-Z0-9_.-]+):[0-9]+\\).*/\\1/'\n|\nsort\n|\nuniq\n-c\n|\nsort\n-rn\nEnter fullscreen mode\nExit fullscreen mode\nCorrected, the emitters are\ngnome-control-center\n,\ngnome-software\n,\nxdg-desktop-portal-gtk\n,\nmutter-x11-frames\nand Chrome — every GTK4 process on the system, each one failing identically, every time it starts.\nWhat the Theme Declared, and What GTK Served\n161 distinct parse failures per process: 159 in\nlibadwaita.css\n, 2 in\nlibadwaita-tweaks.css\n. At\nwarning\nand above each one appeared exactly five times — 159 × 5 = 795, 2 × 5 = 10 — one set per GTK4 process running at boot. Across all priorities, including the Chrome instances started later from the shelf,\n2,093 lines in one boot.\nThe message names the construct:\nTheme parser error: libadwaita.css:94:1-7: Unknown @ rule\nEnter fullscreen mode\nExit fullscreen mode\nColumns 1-7 of line 94:\n@media\n(\nprefers-color-scheme\n:\ndark\n)\n{\n@define-color\nwindow_bg_color\n#222226\n;\n...\n}\nEnter fullscreen mode\nExit fullscreen mode\n@media\n. GTK's CSS parser is not a browser's, and\nGTK 4.18 does not implement\n@media\n.\nIt reports the rule as unknown and discards the entire block.\nWhich block is discarded matters more than the noise.\nflex\ninstalls adw-gtk3 from the upstream release tarball, pinned:\ngrep\nADW_VERSION flex\nEnter fullscreen mode\nExit fullscreen mode\nADW_VERSION=${ADW_VERSION:-v6.5}\nEnter fullscreen mode\nExit fullscreen mode\nUpstream's own release notes, read in order, are unambiguous about what that pin means:\nRelease\nUpstream's note\n@media\nin the GTK4 CSS\nv5.7\n\"New release for GNOME 48 and libadwaita 1.7\"\n0\nv6.3\nlast release before the change\n0\nv6.4\n\"The GTK4 theme now requires GTK 4.20 or later.\"\n3\nv6.5\n\"Release for GNOME 50.\"\n159\nThe machine runs GNOME 48, GTK 4.18.6 and libadwaita 1.7.6. The pin was\nv6.5\n— GNOME 50, GTK 4.20+. There is a release named for this exact platform, in upstream's own words, and it is two major versions below the pin.\ngit log\nsays the pin was never wrong\nlater\n; it was wrong from the start:\ngit log\n--oneline\n-L58\n,58:flex\nEnter fullscreen mode\nExit fullscreen mode\n12a0ddc Add flex: Debian desktop customization to mimic ChromeOS Flex\n+ADW_VERSION=${ADW_VERSION:-v6.5}\nEnter fullscreen mode\nExit fullscreen mode\nThe newest release at the time, taken as the right one because it was newest, never checked against the desktop it had to run on.\nWhy Nothing Looked Wrong\nA theme silently dropping 159 rule blocks should be visible, and it was not. Two reasons, and the second is the expensive one.\nFirst, libadwaita applications largely do not use the GTK theme at all — they carry their own stylesheet and follow\ncolor-scheme\ndirectly. Most of the desktop stayed dark because most of the desktop was never asking the theme.\nSecond, and much worse:\nT\n=\n~/.local/share/themes\nfor\nf\nin\n$(\ncd\n$T\n/adw-gtk3/gtk-4.0\n&&\nfind\n.\n-type\nf |\nsort\n)\n;\ndo\ncmp\n-s\n\"\n$T\n/adw-gtk3/gtk-4.0/\n$f\n\"\n\"\n$T\n/adw-gtk3-dark/gtk-4.0/\n$f\n\"\n\\\n&&\necho\n\"identical:\n$f\n\"\n||\necho\n\"DIFFERS:\n$f\n\"\ndone\nEnter fullscreen mode\nExit fullscreen mode\nidentical: ./assets/bullet-symbolic.svg\nidentical: ./assets/check-symbolic.svg\nidentical: ./assets/dash-symbolic.svg\nidentical: ./assets/devel-symbolic.svg\nidentical: ./gtk.css\nidentical: ./gtk-dark.css\nidentical: ./libadwaita.css\nidentical: ./libadwaita-tweaks.css\nEnter fullscreen mode\nExit fullscreen mode\nAt v6.5,\nevery one of the eight files under\ngtk-4.0/\nis byte-identical between\nadw-gtk3\nand\nadw-gtk3-dark\n.\nFrom v6.4 upstream stopped shipping two GTK4 stylesheets. There is one file, and dark is selected at runtime by the\n@media\nquery — the query GTK 4.18 throws away.\nSo the dark theme's own file defines the light value, unconditionally, and the dark value only inside the block that never executes:\nadw-gtk3-dark/gtk-4.0/libadwaita.css:62:\n @define-color window_bg_color #fafafb; <- light, applied\ninside @media (prefers-color-scheme: dark):\n @define-color window_bg_color #222226; <- dark, discarded\nEnter fullscreen mode\nExit fullscreen mode\n46 of the 154\n@define-color\nrules in that file are inside\n@media\nblocks.\nAll 46 were being dropped. And because the two GTK4 trees are identical,\nset-mode.sh\n— the helper this repository installs specifically to flip light and dark — could not change a GTK4 application's palette at all. It flipped a setting between two names that pointed at the same bytes.\nThat is the shape of the whole problem:\nthe setting declared a dark theme, and the filesystem served a light one.\nNothing in the declaring layer knows what the serving layer did with it, and the only place the two are compared is the log.\nThe Fix, and the Second Bug It Exposed\nMoving the pin to\nv5.7\nis one line. Applying it was not, and the reason is a bug the first bug was hiding.\nbash flex theme\nEnter fullscreen mode\nExit fullscreen mode\n==> theme: adw-gtk3 v5.7 into /home/xbill/.local/share/themes\n already installed -- skipping\nEnter fullscreen mode\nExit fullscreen mode\nThe stage's idempotence guard tested that the theme\ndirectories existed\n, not which version was in them. That is fine while the pin is right and fatal once it is wrong:\ncorrecting the pin was a no-op, because the evidence of the bad install was also the thing that suppressed the repair.\nEvery re-run confirmed the wrong theme.\nIdempotence has to mean \"on the pinned version\", not \"something is there\". The guard now records what it installed and compares:\nif\n[\n-d\n\"\n$THEMES\n/adw-gtk3-dark\"\n]\n&&\n[\n-d\n\"\n$THEMES\n/adw-gtk3\"\n]\n\\\n&&\n[\n\"\n`\ncat\n\"\n$THEMES\n/.adw-gtk3-version\"\n2>/dev/null\n`\n\"\n=\n\"\n$ADW_VERSION\n\"\n]\n;\nthen\nstep\n\"already installed at\n$ADW_VERSION\n-- skipping\"\nreturn\nfi\nEnter fullscreen mode\nExit fullscreen mode\nIt also removes the old tree before extracting rather than unpacking over it. The layout changed between the two releases — v6.3 added\nlibadwaita.css\nand\nlibadwaita-tweaks.css\nto\ngtk-4.0\n, and v5.7 has neither — so extracting v5.7 on top of v6.5 would have left both files orphaned on disk, imported by nothing and still found by anything globbing the directory.\nRe-run, and the two themes are two themes again:\nadw-gtk3/gtk-4.0/gtk.css: @define-color window_bg_color #fafafb;\nadw-gtk3-dark/gtk-4.0/gtk.css: @define-color window_bg_color #222226;\nEnter fullscreen mode\nExit fullscreen mode\nsudo\njournalctl\n-b\n-o\ncat\n-q\n|\ngrep\n-c\n\"Theme parser error\"\nEnter fullscreen mode\nExit fullscreen mode\n0\nEnter fullscreen mode\nExit fullscreen mode\n2,093 to 0\n, and\nwarning\n-and-above for the whole system fell from 1,032 to 151. ✅\nThe Same Loop, Three More Times\nOne defect found this way could be luck. The value is in the loop, so it is worth running it against three other subsystems — each with its own evidence source, and each teaching something different about how to read one.\nDrivers: the error you must refuse to act on\nThe kernel log's firmware section looks alarming and mostly is not:\nsudo\njournalctl\n-b\n-k\n-q\n-o\ncat\n|\ngrep\n-i\niwlwifi\nEnter fullscreen mode\nExit fullscreen mode\niwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz\niwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)\niwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)\niwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)\niwlwifi 0000:00:14.3: loaded firmware version 77.2753b721.0 QuZ-a0-hr-b0-77.ucode\nEnter fullscreen mode\nExit fullscreen mode\nThree failures, then success.\niwl-debug-yoyo.bin\nis an optional debug blob that Debian does not ship and the driver does not need; the device is working.\nAn agent that treats \"failed\" as actionable installs packages to fix a working radio.\nThe correction is cheap and general: read the lines\nafter\nthe error before acting on it, and prefer the state of the device to the wording of the log.\nThe genuinely interesting driver finding was on the other side, and it is a non-event worth confirming rather than assuming:\nsudo\ndkms status\nEnter fullscreen mode\nExit fullscreen mode\nnvidia/610.57.04, 6.12.107+deb13-amd64, x86_64: installed\nnvidia/610.57.04, 7.1.8+deb13-amd64, x86_64: installed\nEnter fullscreen mode\nExit fullscreen mode\nThis machine runs a\nbackports kernel\nwith an out-of-tree NVIDIA module, which is the configuration most likely to break on an upgrade. DKMS had rebuilt against both kernels, and both header packages are present — so the next kernel will not silently land without a GPU. The taint word says exactly what is loaded and why:\ncat\n/proc/sys/kernel/tainted\n# 12289 -> bits 0, 12, 13\nmokutil\n--sb-state\n# SecureBoot disabled\nEnter fullscreen mode\nExit fullscreen mode\nProprietary, out-of-tree, unsigned — all three expected here, and all three would be worth an alarm on a machine where Secure Boot was on.\nPackages: what apt declares against what apt will serve\napt\nwill happily tell you a package is available without telling you it will never choose it:\napt-cache policy |\ngrep\n-A1\nbackports |\nhead\n-4\nEnter fullscreen mode\nExit fullscreen mode\n100 https://deb.debian.org/debian trixie-backports/main amd64 Packages\n release o=Debian Backports,a=stable-backports,n=trixie-backports\nEnter fullscreen mode\nExit fullscreen mode\nPriority 100 against 500 for everything else.\nBackports is enabled and will never be selected automatically — which is correct, and is also why the running kernel had to be asked for by name. Six third-party origins are configured on this box (Docker, Chrome, cloud-sdk, CUDA, Claude Desktop, and backports), and\napt-cache policy\nis the only place that relationship is written down.\nThe rest of the package state was one line of debris and one pending upgrade:\nrc linux-image-6.12.94+deb13-amd64 (removed, config files remain)\ncontainerd.io 2.3.4 -> 2.3.5 (upgradable)\nEnter fullscreen mode\nExit fullscreen mode\nNeither is a problem. Both are the kind of thing that is invisible until something asks.\nTuning: the wait that nothing was waiting for\nsystemd-analyze\nis the least-used excellent tool on a Debian desktop, because it does not report which unit is\nslow\n— it reports which unit is\nin the way\n:\nsystemd-analyze critical-chain\nEnter fullscreen mode\nExit fullscreen mode\ngraphical.target @10.626s\n└─power-profiles-daemon.service @10.547s +78ms\n └─multi-user.target @10.545s\n └─docker.service @9.507s +1.037s\n └─network-online.target @9.505s\n └─NetworkManager-wait-online.service @1.730s +7.774s\nEnter fullscreen mode\nExit fullscreen mode\n7.774 seconds, on the path to the desktop appearing, spent blocking until the network was routable\n— because\ndocker.service\nasks for\nnetwork-online.target\nand\nNetworkManager-wait-online\nis what satisfies it. Docker does not need a routable address at start; it needs one when a container asks. The dependency is a default, not a decision.\nAnd one phase up, the loader was carrying a 5-second GRUB menu nobody reads — on a machine whose own repository already ships\nboot-splash.sh\nto remove it, documented as installed-but-never-run.\nBoth changed, one reboot, measured:\nphase\nbefore\nafter\ndelta\nfirmware\n16.064s\n14.448s\n−1.616s\nnot touched\nloader\n8.014s\n2.776s\n−5.238s\nGRUB_TIMEOUT\n5 → 0\nkernel\n4.617s\n4.978s\n+0.361s\nnot touched\nuserspace\n10.626s\n4.941s\n−5.685s\nwait-online\ndisabled\ntotal\n39.324s\n27.144s\n−12.180s\nThe attributable figure is −10.9 s, not −12.180 s\n, and the table says why. Firmware and kernel are phases nothing in this change touches, and they moved by −1.255 s between the two runs on their own. That is the run-to-run noise of the measurement, and it is the reason the two columns cannot simply be subtracted:\na change measured against the previous boot is measured against time as well.\nOne boot either side is a weak design, and the honest claim is a bound — around eleven seconds, of which 5.238 s and 5.685 s land in exactly the two phases that were altered.\nnetwork-online.target\nis still reached, incidentally. It is reached at\n@1.720 s instead of @9.505 s\n, because nothing is now blocking on it. Docker started clean.\nAnd the loop immediately found the next thing\nsystemd-analyze blame |\nhead\n-3\nEnter fullscreen mode\nExit fullscreen mode\n3.303s nvidia-persistenced.service\n2.689s plymouth-quit-wait.service\n2.208s thermald.service\nEnter fullscreen mode\nExit fullscreen mode\nnvidia-persistenced\nis now\n3.303 s of a 4.941 s userspace boot\nand sits on the critical chain where\nwait-online\nused to. That is not a disappointment; it is the loop working. Removing the largest cost promotes the next one into view, and it was invisible while a 7.8-second wait was in front of it. ✅\nWhere the Agent Actually Fits\nNothing above required a capability Debian was missing. Every number came from\njournalctl\n,\nsystemd-analyze\n,\ndpkg\n,\ndkms\n,\napt-cache\nand\ncmp\n— all of them installed, all of them documented, none of them new. The evidence had been there, in the same files, since the machine was configured.\nWhat was missing was the other half of the loop:\nsomething willing to read a thousand warnings, at the moment they stop being free to ignore.\nThat is a specific job, and it is worth being precise about which parts of it are the agent's:\nReading at volume without triage fatigue.\n1,032 warnings is where a human\nstarts sampling. The 805-line defect was in the histogram's first row, and the\nhistogram is trivial to build — the reason nobody had built it is that nobody\nhad a reason to.\nCorrelating across sources that share no vocabulary.\nThe finding needed a\njournal message, a CSS file, a\ndpkg -l\nversion, four GitHub release notes and\na\ngit log -L\non one line of a shell script. Each is unremarkable alone.\nActing, then re-reading.\nThe fix is only confirmed by the same query that\nfound it returning 0 — and by\nwarning+\ndropping 1,032 → 151, which is a\ndifferent check than \"the desktop still looks fine\".\nAnd the parts that are not:\nDeciding what is worth fixing.\nThe\niwlwifi\nline is a failure the correct\naction is to ignore. An agent that treats every\nerror\nas work will find\nplenty of it.\nAnything that touches the boot chain.\nboot-splash.sh\nis in this\nrepository precisely because it edits GRUB, and this repository deliberately\nnever runs it for you. Reading it first was a human decision; so was accepting\nthat Docker would now start without waiting for the network.\nBelieving the log's own metadata.\n_COMM\nsaid\ncat\n1,288 times.\nThe loop that produced everything above is four steps and does not need tooling:\nread the evidence, form a claim about which layer disagrees with which, change one thing, re-read the same source.\nThe last step is the one that distinguishes it from a guess, and it is the step a settings panel cannot offer, because a settings panel only ever shows you what was declared.\nCheat Sheet\nNothing here writes:\n# 0. can you actually see the system's evidence, or only your own?\nid\n|\ngrep\n-o\n'adm\\|systemd-journal'\n||\necho\n\"unprivileged view -- use sudo\"\n# 1. volume first, at warning, not just err\nsudo\njournalctl\n-b\n-p\nerr\n--no-pager\n-q\n|\nwc\n-l\nsudo\njournalctl\n-b\n-p\nwarning\n--no-pager\n-q\n|\nwc\n-l\n# 2. collapse a thousand lines into distinct problems\nsudo\njournalctl\n-b\n-p\nwarning\n--no-pager\n-q\n-o\ncat\n\\\n|\nsed\n's/[0-9a-f]\\{8,\\}/HEX/g; s/[0-9]\\+/N/g'\n\\\n|\nsort\n|\nuniq\n-c\n|\nsort\n-rn\n|\nhead\n-20\n# 3. attribute by payload, not by _COMM\nsudo\njournalctl\n-b\n-q\n-o\ncat\n|\ngrep\n\"\"\n\\\n|\nsed\n-E\n's/^\\(([a-zA-Z0-9_.-]+):[0-9]+\\).*/\\1/'\n|\nsort\n|\nuniq\n-c\n|\nsort\n-rn\n# 4. what is in the way of the desktop -- not what is slow\nsystemd-analyze\nsystemd-analyze critical-chain\nsystemd-analyze blame |\nhead\n-10\n# 5. out-of-tree modules against every installed kernel\nsudo\ndkms status\n;\ncat\n/proc/sys/kernel/tainted\n;\nmokutil\n--sb-state\n# 6. what apt will actually serve you, priorities included\napt-cache policy\n;\napt list\n--upgradable\n2>/dev/null\n;\ndpkg\n-l\n|\ngrep\n'^rc'\n# 7. re-read the exact query that found it -- this is the step that confirms\nEnter fullscreen mode\nExit fullscreen mode\nSummary\nThe goal of this article was to find out what a correctly-behaving Debian desktop was failing to mention, and whether reading its own logs systematically would repay the effort. The key to the solution was treating the configuration layer and the serving layer as two separate claims that have to be compared — what\ngsettings\ndeclared against what GTK parsed, what a unit file requested against what the boot actually waited for — because every defect found was invisible in the declaring layer and plainly stated in the serving one. The measured results were:\n2,093 CSS parse errors per boot went to 0.\nThe theme pin was two major\nversions above what the desktop's GTK could parse, from the first commit that\nintroduced it.\nSystem-wide\nwarning\n-and-above fell 1,032 → 151.\nerr\n-and-above stayed at\n17, correctly — none of those were theme-related.\n46 of 154\n@define-color\nrules were being discarded\n, and all eight\ngtk-4.0\nfiles were byte-identical between the light and dark themes, so the\nmode switcher could not change a GTK4 application at all.\nBoot went 39.324 s → 27.144 s, of which −10.9 s is attributable\n— 5.238 s\nof GRUB timeout and 5.685 s of\nNetworkManager-wait-online\n— with the\nuntouched phases drifting −1.255 s as noise.\nnetwork-online.target\nis now reached at @1.720 s rather than @9.505 s\n, and\nDocker starts clean without it being waited on.\nA second bug was hidden by the first\n: the theme stage's idempotence guard\ntested only that files existed, so correcting the pin was a no-op until the\nguard was made version-aware.\nScope: one laptop, one operating system, measured 2026-09-08 on Debian 13 with GNOME 48, GTK 4.18.6 and kernel 7.1.8+deb13-amd64 from backports. The boot figures are\nn = 1 on each side\n— a single boot before and a single boot after — which is why the attributable claim is stated as a bound rather than a measurement, and the ±1.255 s drift in the two untouched phases is the only estimate of noise available from that design; repeated boots on each configuration are queued and would replace it. The 2,093 → 0 result is not subject to the same weakness, being a count of a deterministic parse failure rather than a timing. Whether any application's appearance visibly changed as a result of the theme fix was\nnot\nmeasured: the five confirmed emitters prove the file was parsed, not that a user could see the difference, and libadwaita applications never consulted the theme either way.\nnvidia-persistenced\nat 3.303 s is now the largest item on the critical chain and has not been investigated.\nThe strategy of reading the system's own evidence at volume, attributing it by payload rather than metadata, changing one thing, and re-running the query that found it was validated with an incremental step by step approach.\nDisclosure: I ran this with Claude Code as the diagnostic agent — it swept the journal, built the histograms, traced the pin to the upstream release notes, wrote the fix and re-measured after the reboot, while I steered and made the calls about what to touch. The commands, the counts and both defects are real and archived in the repository.", "metadata": { "title": "The Desktop Looked Right: 2,093 Parse Errors a Boot, and 10.9 Seconds That Weren't Doing Anything - DEV Community", "description": "A Debian desktop that looked and behaved correctly was throwing 2,093 CSS parse errors per boot and spending 10.9 seconds of a 39-second boot waiting on nothing. Neither is visible on screen. Both are in the journal, and both were introduced by the script that was supposed to set the machine up. Tagged with debian, linux, claudecode, devops.", "keywords": "debian, linux, claudecode, devops, software, coding, development, engineering, inclusive, community", "author": null, "og:type": "article", "og:url": "https://dev.to/gde/the-desktop-looked-right-2093-parse-errors-a-boot-and-109-seconds-that-werent-doing-anything-4bb", "og:title": "The Desktop Looked Right: 2,093 Parse Errors a Boot, and 10.9 Seconds That Weren't Doing Anything", "og:description": "A Debian desktop that looked and behaved correctly was throwing 2,093 CSS parse errors per boot and spending 10.9 seconds of a 39-second boot waiting on nothing. Neither is visible on screen. Both are in the journal, and both were introduced by the script that was supposed to set the machine up.", "og:site_name": "DEV Community", "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fxbill9%2Fchromeos-boot%2Fmain%2Fdocs%2Ffeedback-loops%2Fcover.33f0beb1.jpg", "twitter:site": "@thepracticaldev", "twitter:creator": "@", "twitter:title": "The Desktop Looked Right: 2,093 Parse Errors a Boot, and 10.9 Seconds That Weren't Doing Anything", "twitter:description": "A Debian desktop that looked and behaved correctly was throwing 2,093 CSS parse errors per boot and spending 10.9 seconds of a 39-second boot waiting on nothing. Neither is visible on screen. Both are in the journal, and both were introduced by the script that was supposed to set the machine up.", "twitter:card": "summary_large_image", "twitter:widgets:new-embed-design": "on", "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fraw.githubusercontent.com%2Fxbill9%2Fchromeos-boot%2Fmain%2Fdocs%2Ffeedback-loops%2Fcover.33f0beb1.jpg" }, "paywall": { "listed_paid": false, "detected": false, "marker": "", "public_only": false, "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙" }, "crawl": { "success": true, "status_code": 200, "error": "" }, "code_blocks": [ { "file": "attachments/26c637d5ebd3/code/body-000.txt", "chars": 3, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-001.txt", "chars": 211, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-002.txt", "chars": 16, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-003.txt", "chars": 58, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-004.txt", "chars": 104, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-005.txt", "chars": 8, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-006.txt", "chars": 143, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-007.txt", "chars": 321, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-008.txt", "chars": 107, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-009.txt", "chars": 119, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-010.txt", "chars": 150, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-011.txt", "chars": 58, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-012.txt", "chars": 83, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-013.txt", "chars": 22, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-014.txt", "chars": 33, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-015.txt", "chars": 31, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-016.txt", "chars": 104, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-017.txt", "chars": 211, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-018.txt", "chars": 266, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-019.txt", "chars": 218, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-020.txt", "chars": 16, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-021.txt", "chars": 96, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-022.txt", "chars": 214, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-023.txt", "chars": 140, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-024.txt", "chars": 60, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-025.txt", "chars": 2, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-026.txt", "chars": 50, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-027.txt", "chars": 356, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-028.txt", "chars": 17, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-029.txt", "chars": 113, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-030.txt", "chars": 114, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-031.txt", "chars": 48, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-032.txt", "chars": 142, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-033.txt", "chars": 113, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-034.txt", "chars": 31, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-035.txt", "chars": 240, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-036.txt", "chars": 32, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-037.txt", "chars": 93, "language": "text" }, { "file": "attachments/26c637d5ebd3/code/body-038.txt", "chars": 1141, "language": "text" } ], "images": [], "audio": [], "videos": [], "links": [ { "href": "https://github.com/xbill9/chromeos-boot", "label": "https://github.com/xbill9/chromeos-boot", "type": "a" } ], "repair_version": 2, "repaired_at": "2026-10-14T10:48:35Z", "source_url": "https://dev.to/gde/the-desktop-looked-right-2093-parse-errors-a-boot-and-109-seconds-that-werent-doing-anything-4bb", "papers": [], "actual_video_files": [], "body_chars": 25168, "expected_body_images": 0, "discovery_status": "ok", "delivery_status": "ok", "missing_reason": "", "raw_html": "attachments/26c637d5ebd3/pages/source.html", "local_html": "attachments/26c637d5ebd3/pages/article.html", "body_base_path": "attachments/26c637d5ebd3/pages/", "body_markdown_path": "attachments/26c637d5ebd3/pages/article.md" }