chromium resets after update

cryptearth · 2026-02-20 22:49:38

as this happened a few times recently and always after an update of chromium via pacman I guess this section seems fit

anyway

issue: for some reason since the last few months every once in a while when there's an update for chromium it sometimes resets
with "reset" meaning: it's as if $home/.config/chromium would get completely wiped - it's back to when you first start it after a clean OS install - when it happens it even resets the window size, too
leaning towards https://bbs.archlinux.org/viewtopic.php?id=311617 I guess my nvme actually is dying - but just more slowly
important note: it is only chromium affected (as far as I can tell) - all other applications that rely on any sort of config in $home are fine as always

no - i've not consulted AI as I likely find way better help here than with any LLM - or even combine them for the sake of fun

I'm a bit puzzled
for what it's worth here's my daily morning:

- grab my phone to silence the alarm
- use ConnectBot to connect via SSH to my home "server" (it's an old SBC - so one could hardly call it a "server")
- wake my system via WoL
- ssh into my main system
- run pacman -Syu (and -Syu only, no double y or u)
- no matter what kind of updates or how many: reboot
- only then I get my head up, walk over to the keyboard, punch in my super secret 4-letter password - and start my day

what happens every now and then: browsing to this very bbs and find myself no longer logged in anymore - re-checking by browsing to youtube and get greeted by that stupid "please agree to our ToS" popup
ok, it's not a problem after all - there're about a dozen sites I visit and most of them are either via passkey or social login from said accounts - so getting back into the important stuff is about punching in my (more secure) token pin and touch it a few times (when does arch SSO with passkey support commin? please?) - but it's annoying and I can't figure out WHY?
it's also not every update - sometimes it passes several updates in a row - sometimes it breaks at every update

asking google brings up ... well, mixed results - I guess I use the wrong search terms - and instead of relying on googles AI, or microsofts, or whomevers (is that even an english word?) - without trying I can smell already: "nah, bad idea - will likely only cause even more harm"

as my network is setup for PXE boot i just booted up recent arch install and ran fsck - and aside from "narrowing" exactly ONE inode it didn'T report any issue

anyone else get similar issues lately? guess that's on my end - maybe my nvme ssd actually is dying? just pure speculation with some hope of if anyone has any hint where to start looking - thanks in advance

killertofus · 2026-02-21 00:03:38

does ungoogled-chromium work?

seth · 2026-02-21 08:40:28

it's as if $home/.config/chromium would get completely wiped

But it's not, is it?

- ssh into my main system
- run pacman -Syu (and -Syu only, no double y or u)
- no matter what kind of updates or how many: reboot

Reboot *how*? Is a chromium instance running at this point and does it get a chance to properly terminate?
System time and hwclock are ok? You're not starting w/ 5 days drift and only fix that via ntp after chromium had started?

maybe my nvme ssd actually is dying?

https://wiki.archlinux.org/title/Solid_ … NVMe#SMART

cryptearth · 2026-02-21 10:42:06

killertofus wrote:

does ungoogled-chromium work?

as i do use google services i'm not sure with a stripped version is the right version to use
i use chromium mainly because its in the repo rather then the regular full chrome which is aur

seth wrote:

it's as if $home/.config/chromium would get completely wiped
But it's not, is it?

no, it doesn't get actually wiped but by timestamps a lot of stuff gets recreated while other stuff remains
i could also think about kwalletd as the security provider: from how i understand chromium locks down stuff like cookies and credentials which get unlocked via pam upon successful login which in turn unlocks kwalletd which seem to guard chromium stuff - but when the issue occurs there's no simultaneous kwalletd update; vise-versa i haven't dncountered any issue when only kwalletd gets updated but not chromium
so if kwalletd is somehow involved it doesn't look like the cause - at least from what i understand

seth wrote:

- ssh into my main system
- run pacman -Syu (and -Syu only, no double y or u)
- no matter what kind of updates or how many: reboot
Reboot *how*? Is a chromium instance running at this point and does it get a chance to properly terminate?
System time and hwclock are ok? You're not starting w/ 5 days drift and only fix that via ntp after chromium had started?

running

sudo pacman -Syu
sudo reboot

there's no chromium instance up at this time nor any other applications using it
clock is fine and regular synced - only drifts for very few seconds
i have to add that after the first update with pacman and reboot i then use yay as aur helper to check for updates of my few aur packages - but i don't use yay for regular pacman tasks
i also pay attention about to not use yay to update packages from the regular repos
i also only have core, extra and multilib - nothin like chaotic

seth wrote:

maybe my nvme ssd actually is dying?
https://wiki.archlinux.org/title/Solid_ … NVMe#SMART

the only thing that smart comes up with is a high count over temperature warnings as note in my linked topic - but no failed sectors

seth · 2026-02-21 15:52:38

i could also think about kwalletd as the security provider

If you're only losing login data that's the most likely cause and you're switching around the services or the session bus is broken or there's a race condition.
https://wiki.archlinux.org/title/Chromi … word_store
This will hinge on how you start the session, when you start chromium, what triggers kwallet and ultimately errors in the journal might get you a hint.
(The update condition would then be a red herring, it's more the reboot that causes this)

cryptearth · 2026-02-21 17:28:50

I use sddm - but without actual logging in this should not cause any issue as I don't use auto-login https://wiki.archlinux.org/title/KDE_Wa … y_on_login
so rebooting remote via ssh shouldn't be the cause - as I do it pretty much since I switched to arch back in october 2022 - and the issue only started recently about fall last year (at least i don't remember to have ever encountered it any earlier) - or could it be that because i log in remotely and the reboot that something not correctly releases and hence causing some issues when I log in local after the reboot?
what I might add: every now and then my chromium craches - often when I open a new tab and start typing the address or during loading after hitting return
yesterday when it happened I just completely wiped both .config/chromium as well as .cache/chromium to compeltely reset it - just logged into google, opened another tab and started typing another url > crash; repeated the exact same steps > no crash the second time

it's just one of those: ok, I guess there could be something that gets stuck or gets a hickup and causes issue during/after reboot - but I don't have anything to even start at - is it chromium itself? is it something lower down the stack like kwallet or even pam? is ssh vs local? some stupid racecondition caused by something seemingly random
don't get me wrong - i'm not going to blame anyone as it's hardly on purpose - but something supposed to be simple as "when I login pam unlocks kwallet which unlocks whatever chromium use as storage" breaking by what's look like updates - which are supposed to not even touch anything in $home at all ...

seth · 2026-02-21 20:12:35

so rebooting remote via ssh shouldn't be the cause

No, just the reboot - or rather the login makes things susceptible to a race condition here in general.

Does chromium autostart w/ the session?
Does it usually help to just restart chromium?

You could try to force chromium to use the basic (builtin) storage but there's gonna be sth. logged to the journal or stdout if there're problems w/ talking to the https://specifications.freedesktop.org/ … ce/latest/

cryptearth · 2026-02-21 22:24:19

no, chromium does not get started at all unless i login local and start it - so i don't see why the reboot should cause an issue? at this point the local plasma isn't logged in yet but waits at sddm greeter

seth · 2026-02-21 22:28:46

i don't see why the reboot should cause an issue? at this point the local plasma isn't…

It's not even the actual boot, it's just that the session gets setup fresh - though w/o chromium autostarting, chances for a race condition get rather slim
Do you have a system journal covering such incident?

cryptearth · 2026-02-22 09:57:29

I got the logs from before the update - of the update itself - and after the update
funny enough 0x0 seems to block both my ipv4 and ipv6:

Your network (2a0c:d240::/29) is blocked from uploading files.
Your network (88.150.0.0/17) is blocked from uploading files.

so I put it on my own server
https://lim.cryptearth.de/~cryptearth/before_update.txt
https://lim.cryptearth.de/~cryptearth/update.txt
https://lim.cryptearth.de/~cryptearth/after_update.txt
https://lim.cryptearth.de/~cryptearth/r … update.txt

seth · 2026-02-22 14:38:24

Feb 20 22:55:26 main systemd[1598]: Started Unlock kwallet from pam credentials.
Feb 20 22:55:26 main pam_kwallet_init[1777]: 2026/02/20 22:55:26 socat[1777] W address is opened in read-write mode but only supports read-only
Feb 20 22:55:34 main dbus-daemon[1633]: [session uid=1000 pid=1633 pidfd=5] Activating service name='org.kde.kwalletd6' requested by ':1.49' (uid=1000 pid=2213 comm="/usr/lib/chromium/chromium --ignore-gpu-blocklist ")
Feb 20 22:55:35 main kwalletd6[2291]: g_dbus_proxy_get_object_path: assertion 'G_IS_DBUS_PROXY (proxy)' failed
Feb 20 22:55:35 main dbus-daemon[1633]: [session uid=1000 pid=1633 pidfd=5] Successfully activated service 'org.kde.kwalletd6'
# red herring  -- Feb 20 22:55:35 main kwalletd6[2291]: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: App info not found for 'org.kde.kwalletd'")
…
Feb 20 22:56:47 main chromium[2866]: [2866:2866:0220/225647.218117:ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:251] '--ozone-platform=wayland' is not compatible with Vulkan. Consider switching to '--ozone-platform=x11' or disabling Vulkan
# shutdown -- Feb 20 23:16:41 main kwalletd6[2291]: Secret Service availability changed: Unavailable

This here looks worrysome

Feb 20 22:55:24 main sddm-helper[1577]: pam_kwallet5(sddm:auth): pam_kwallet5: pam_sm_authenticate
Feb 20 22:55:24 main sddm-helper[1577]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Feb 20 22:55:24 main sddm-helper[1577]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
Feb 20 22:55:24 main sddm-helper[1615]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
Feb 20 22:55:26 main systemd[1598]: Started Unlock kwallet from pam credentials.
Feb 20 22:55:26 main pam_kwallet_init[1777]: 2026/02/20 22:55:26 socat[1777] W address is opened in read-write mode but only supports read-only
Feb 20 22:55:34 main dbus-daemon[1633]: [session uid=1000 pid=1633 pidfd=5] Activating service name='org.kde.kwalletd6' requested by ':1.49' (uid=1000 pid=2213 comm="/usr/lib/chromium/chromium --ignore-gpu-blocklist ")
Feb 20 22:55:35 main kwalletd6[2291]: g_dbus_proxy_get_object_path: assertion 'G_IS_DBUS_PROXY (proxy)' failed
Feb 20 22:55:35 main dbus-daemon[1633]: [session uid=1000 pid=1633 pidfd=5] Successfully activated service 'org.kde.kwalletd6'
Feb 20 22:55:35 main kwalletd6[2291]: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: App info not found for 'org.kde.kwalletd'")
Feb 20 23:16:41 main kwalletd6[2291]: Secret Service availability changed: Unavailable

pam operates a kwallet5 socket but chromium triggers kwalletd6

pacman -Qs kwallet

You might have kwallet and kwallet5 conflicting each other?

cryptearth · 2026-02-22 15:25:20

doesn'T look like it

[main@main ~]$ pacman -Qs kwallet
local/ksshaskpass 6.6.0-1 (plasma)
    ssh-add helper that uses kwallet and kpassworddialog
local/kwallet 6.23.0-1 (kf6)
    Secure and unified container for user passwords
local/kwallet-pam 6.6.0-1 (plasma)
    KWallet PAM integration
local/signon-kwallet-extension 25.12.2-1 (kde-applications kde-network)
    KWallet integration for signon framework

searching for anyting kde5/qt5 related only brings up vlc which still depends on it via vlc-gui-qt - but if I'd remove vlc i could get rid of all of that - so nothin else seem to depend on it anymore
yes, this is quite an old install - oct 2022 - but even with such major upgrades like from kde 5 to 6 this should all resolved now
i doubt that a new user would bring more insights - rather I could test setup arch from scratch - but this would still require either wait for the next chromium update or hunt down a few previous versions and test whether updating them breaks it

seth · 2026-02-22 22:02:36

this would still require either wait for the next chromium update or

I don't think the updates really have to do anything w/ this - are you sure you can otherwise just reboot at will and never run into this?

cryptearth · 2026-02-23 03:53:48

seth wrote:

are you sure you can otherwise just reboot at will and never run into this?

at least i haven't encountered the issue when chromium was not updated - hence i suspect it's specific to cromium
tried to search again - but not much came up other than what's already summarized in the wiki - the only thing that made any sense was a quite old question on stackoverflow: someone replied it could be an issue between two versions due to some internal stuff - didn't really understand it fully
i still fail to see how rebooting the system - no matter how - could cause the issue i encounter - espacially when using ssh as nothin affected should be loaded this way - unless somehow some stuff does get triggered I'm unaware of

[main@main ~]$ cat .bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls -aFhl --color=auto'
PS1='[\u@\h \W]\$ '
[main@main ~]$ cat .bash_profile
#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

the only thing i do in these is overlay an ls alias - but i doubt this could be it

seth · 2026-02-23 09:11:49

i still fail to see how rebooting the system - no matter how - could cause the issue i encounter

Startup sequence between chromium and kwallet - try to use the "basic" (internal) password storage and whether that stabilizes things.
If not we can at least rule out kwallet's relevance.

cryptearth · 2026-02-23 11:53:18

as written: I do the update and reboot all over SSH - I only login local after rebooting after the update - so at this point no graphical user session has started yet - neither kwallet nor chromium even had a chance yet to run
it's a simple sudo reboot via ssh while the local graphical console waits at sddm greeter
it's equivalent to if i would first change to a TTY and login text mode only console - but just it remote over network

to widen my question: i fail to see how this could be related as the way i do the update does not cause any graphical stuff to start but only tty over ssh

seth · 2026-02-23 13:19:59

so at this point no graphical user session has started yet - neither kwallet nor chromium even had a chance yet to run

And it is at this point that you notice the login data to be lost?
How?

You'll notice that when starting chromium.
You're starting chromium because you've just started a new session.
You've started a new session because you rebooted.
You've rebooted because you updated the system.

You'll need to get this entire narrative "update causes the loss of passwords" out of your head - you're, very likely, "losing" that data because the communication between chromium and kwallet fails.
To verify that, you can test to cause this when bypassing kwallet (by using the integrated password storage)

If that's the case you'll have to figure *why* the communication (initially?) fails, eg. by
1. restarting chromium to see whether the later access then succeeds (so you're having a race condition)
2. disabling pam_kwallet (chromium in your journal *triggered* kwallet despite pam should™ have opened it)
The entire chain below is for now coincidental and just happens to trigger the immediate problem without being causal at all.

cryptearth · Yesterday 16:28:41

ok - let's try to debug this
i came home - booted the system via wol - logged in remote via ssh - ran pacman: uodate for chromium available
what i would usually do: update - reboot - sit down in my chair and log on into greeter
what's your advise what I SHOULD do instead?
if i would have both root and home on a snapshot-capable FS i would just give a try and revert back just to check whether there's a difference - but i can't as both root and home are on regular ext4 - and cloning about 40gb just to check takes time even on a nvme
so i'm right at the point where i have to risk chromium losing its memory again without having any clue or way to check one method against the other due to lack of precise reproducability
it's not like i'm unwilling to change my habits - but i would need at least eith a clue or a way to properly test several options

also: i not put myself into this narrative - i just explained what i did and what the result was - and from what i was able to observe are two key factors:
the only way I encountered the issue until now is
- when there's an update for chromium
AND
- i reboot after the update
I not encountered the issue by rebooting in several different ways without an update of chromium - no matter if i have a local kde session running and killing it via ssh when i already laid down in bed or by clicking shutdown via the mouse
hence: from this observation i suspect that updating chromium has at least something to do with what i experience

again: i still fail to see how

communication between chromium and kwallet fails.

could have any play here if i haven't even logged on at the local graphical session but all what happend was a merely pacman -Syu from a TTY - the fact that it's via ssh shouldn't matter - and so shouldn't the reboot
if you can hint me in any direction how chromium and kwallet would even able to interact without any of them even being started neither before nor after the reboot - but only after i logon graphical - ok, i may found some weird race condition that either should not happen - or at least should not cause the issue i experience

i guess both gnome-keyring as well as kwallet are some sort of generailzed api chromium hooks into as its security backend - then the proper way for chromium would be to wait for this backend to become responsible instead of wasting the previous session and create a blank one when it wins the race - otherwise its a bad implementation of chromium and it being at fault

fact is: neither do i know nor am i able to test (at least not without quite some additional to investigate an issue which shouldn't exists in the first place

// edit
here's current journal before starting anything like chromium or steam:

[main@main ~]$ journalctl -b | grep -i wallet
Feb 24 17:44:15 main sddm-helper[1581]: pam_kwallet5(sddm:auth): pam_kwallet5: pam_sm_authenticate
Feb 24 17:44:15 main sddm-helper[1581]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Feb 24 17:44:15 main sddm-helper[1581]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
Feb 24 17:44:15 main sddm-helper[1647]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
Feb 24 17:44:16 main systemd[1605]: Started Unlock kwallet from pam credentials.
Feb 24 17:44:16 main pam_kwallet_init[1809]: 2026/02/24 17:44:16 socat[1809] W address is opened in read-write mode but only supports read-only
[main@main ~]$ journalctl -b | grep -i chrom
[main@main ~]$ pacman -Qs pam
local/kwallet-pam 6.6.0-1 (plasma)
    KWallet PAM integration
local/lib32-pam 1.7.1-1
    Pluggable Authentication Modules
local/pam 1.7.2-2
    PAM (Pluggable Authentication Modules) library
local/pam-u2f 1.4.0-2
    Universal 2nd Factor (U2F) PAM authentication module from Yubico
local/pambase 20250719-1
    Base PAM configuration for services
local/shadow 4.18.0-1
    Password and account management tool suite with support for shadow files and PAM
local/yubico-pam 2.27-3
    Yubico YubiKey PAM module
[main@main ~]$

there's that call to kwallet5 again - but from pam - not from steam, not from chromium - and as listed previous: I don't have kwallet5 installed
so ... is it PAM at fault here by try calling outdated endpoints? or sddm? should i switch to what's the new plasma one called?

installing "plasma" wants to add some crap I don't need:

[main@main ~]$ LC_ALL=C sudo pacman -S --needed plasma
warning: aurorae-6.6.0-1 is up to date -- skipping
warning: bluedevil-1:6.6.0-1 is up to date -- skipping
warning: breeze-6.6.0-2 is up to date -- skipping
warning: breeze-cursors-6.6.0-2 is up to date -- skipping
warning: breeze-gtk-6.6.0-1 is up to date -- skipping
warning: discover-6.6.0-1 is up to date -- skipping
warning: kactivitymanagerd-6.6.0-1 is up to date -- skipping
warning: kde-cli-tools-6.6.0-1 is up to date -- skipping
warning: kde-gtk-config-6.6.0-1 is up to date -- skipping
warning: kdecoration-6.6.0-1 is up to date -- skipping
warning: kdeplasma-addons-6.6.0-1 is up to date -- skipping
warning: kgamma-6.6.0-1 is up to date -- skipping
warning: kglobalacceld-6.6.0-1 is up to date -- skipping
warning: kinfocenter-6.6.0-1 is up to date -- skipping
warning: kmenuedit-6.6.0-1 is up to date -- skipping
warning: knighttime-6.6.0-1 is up to date -- skipping
warning: kpipewire-6.6.0-1 is up to date -- skipping
warning: kscreen-6.6.0-1 is up to date -- skipping
warning: kscreenlocker-6.6.0-1 is up to date -- skipping
warning: ksshaskpass-6.6.0-1 is up to date -- skipping
warning: ksystemstats-6.6.0-1 is up to date -- skipping
warning: kwallet-pam-6.6.0-1 is up to date -- skipping
warning: kwayland-6.6.0-1 is up to date -- skipping
warning: kwin-6.6.0-1 is up to date -- skipping
warning: kwrited-6.6.0-1 is up to date -- skipping
warning: layer-shell-qt-6.6.0-1 is up to date -- skipping
warning: libkscreen-6.6.0-1 is up to date -- skipping
warning: libksysguard-6.6.0-1 is up to date -- skipping
warning: libplasma-6.6.0-1 is up to date -- skipping
warning: milou-6.6.0-1 is up to date -- skipping
warning: ocean-sound-theme-6.6.0-1 is up to date -- skipping
warning: oxygen-sounds-6.6.0-1 is up to date -- skipping
warning: plasma-activities-6.6.0-1 is up to date -- skipping
warning: plasma-activities-stats-6.6.0-1 is up to date -- skipping
warning: plasma-browser-integration-6.6.0-1 is up to date -- skipping
warning: plasma-desktop-6.6.0-1 is up to date -- skipping
warning: plasma-disks-6.6.0-1 is up to date -- skipping
warning: plasma-firewall-6.6.0-1 is up to date -- skipping
warning: plasma-integration-6.6.0-1 is up to date -- skipping
warning: plasma-pa-6.6.0-1 is up to date -- skipping
warning: plasma-sdk-6.6.0-1 is up to date -- skipping
warning: plasma-systemmonitor-6.6.0-1 is up to date -- skipping
warning: plasma-thunderbolt-6.6.0-1 is up to date -- skipping
warning: plasma-workspace-6.6.0-1 is up to date -- skipping
warning: plasma-workspace-wallpapers-6.6.0-1 is up to date -- skipping
warning: plasma5support-6.6.0-1 is up to date -- skipping
warning: polkit-kde-agent-6.6.0-1 is up to date -- skipping
warning: powerdevil-6.6.0-1 is up to date -- skipping
warning: qqc2-breeze-style-6.6.0-1 is up to date -- skipping
warning: sddm-kcm-6.6.0-1 is up to date -- skipping
warning: spectacle-1:6.6.0-1 is up to date -- skipping
warning: systemsettings-6.6.0-1 is up to date -- skipping
warning: xdg-desktop-portal-kde-6.6.0-1 is up to date -- skipping
:: There are 15 members in group plasma:
:: Repository extra
   1) breeze-plymouth  2) drkonqi  3) flatpak-kcm  4) krdp  5) kwin-x11  6) oxygen  7) oxygen-cursors  8) plasma-keyboard  9) plasma-login-manager  10) plasma-nm  11) plasma-vault  12) plasma-welcome  13) plymouth-kcm
   14) print-manager  15) wacomtablet

Enter a selection (default=all): 
resolving dependencies...
looking for conflicting packages...

Packages (37) composefs-1.0.8-1  elfutils-0.194-1  flatpak-1:1.16.3-1  freerdp-2:3.22.0-2  gocryptfs-2.6.1-1  libmalcontent-0.13.1-1  libndp-1.9-1  libnewt-0.52.25-2  libteam-1.32-3  mobile-broadband-provider-info-20251101-1
              modemmanager-1.24.2-1  modemmanager-qt-6.23.0-1  networkmanager-1.54.3-1  networkmanager-qt-6.23.0-1  ostree-2025.7-2  plymouth-24.004.60-14  ppp-2.5.2-1  python-pygdbmi-0.11.0.0-6  python-sentry_sdk-2.53.0-1
              sdl3_ttf-3.2.2-3  wpa_supplicant-2:2.11-5  xf86-input-wacom-1.2.4-1  breeze-plymouth-6.6.0-1  drkonqi-6.6.0-1  flatpak-kcm-6.6.0-1  krdp-6.6.0-1  kwin-x11-6.6.0-1  oxygen-6.6.0-2  oxygen-cursors-6.6.0-2
              plasma-keyboard-6.6.0-1  plasma-login-manager-6.6.0-1  plasma-nm-6.6.0-1  plasma-vault-6.6.0-1  plasma-welcome-6.6.0-1  plymouth-kcm-6.6.0-1  print-manager-1:6.6.0-1  wacomtablet-6.6.0-1

Total Download Size:    35.10 MiB
Total Installed Size:  149.11 MiB

:: Proceed with installation? [Y/n] n
[main@main ~]$

I don't even understand some of the dependencies - why flatpak of all stuff?

Last edited by cryptearth (Yesterday 16:52:58)

seth · Yesterday 22:06:32

I not encountered the issue by rebooting in several different ways without an update of chromium

This would be the money quote - if you can assure that updating chromium is a hard requirement to trigger this the only reasonable (but insane) explanation would be for it to create version-dependent wallets.
You could see thos in kwallet.

Can you trigger this by
1. explicitly re-installing the current version of chromium
2. downgrading and upgrading chromium
and then reboot in either case?

Can you reproduce it when enforcing the basic password store (internal to chromium)?
Can you reproduce it when disabling the kwallet pam? (This is a condition you could change ahead of the next update w/o doing more explicit tests)

Does the kwallet pam successfully open kwallet (notably wrt kwallet being triggered by chromium afterwards) or are you at some point facing a password dialog?

fact is: neither do i know nor am i able to test (at least not without quite some additional to investigate an issue which shouldn't exists in the first place

Yes "should" …
Keep in mind that this isn't a commonplace issue, so there's gonna be something peculiar about your setup that'll be a factor here.
If the update is critical part of this I wonder whether some zfs related action (snapshot creation etc) causes data loss.
Do you keep other data in kwallet? If you just add a dummy password before update and reboot, is that preserved or also lost?

Arch Linux

#1 2026-02-20 22:49:38

chromium resets after update

#2 2026-02-21 00:03:38

Re: chromium resets after update

#3 2026-02-21 08:40:28

Re: chromium resets after update

#4 2026-02-21 10:42:06

Re: chromium resets after update

#5 2026-02-21 15:52:38

Re: chromium resets after update

#6 2026-02-21 17:28:50

Re: chromium resets after update

#7 2026-02-21 20:12:35

Re: chromium resets after update

#8 2026-02-21 22:24:19

Re: chromium resets after update

#9 2026-02-21 22:28:46

Re: chromium resets after update

#10 2026-02-22 09:57:29

Re: chromium resets after update

#11 2026-02-22 14:38:24

Re: chromium resets after update

#12 2026-02-22 15:25:20

Re: chromium resets after update

#13 2026-02-22 22:02:36

Re: chromium resets after update

#14 2026-02-23 03:53:48

Re: chromium resets after update

#15 2026-02-23 09:11:49

Re: chromium resets after update

#16 2026-02-23 11:53:18

Re: chromium resets after update

#17 2026-02-23 13:19:59

Re: chromium resets after update

#18 Yesterday 16:28:41

Re: chromium resets after update

#19 Yesterday 22:06:32

Re: chromium resets after update

Board footer