This is an old bug where if the hostname changes, kiosk doesn't work. Now that name change changes the hostname, it's been brought to the foreground as a serious issue
Steps to Reproduce
Go to setting and rename archipelago to the new name.
Reboot
Expected Behavior
Kiosk should come up
Actual Behavior
Black screen
Archipelago Version
1.7.101-alpha
Hardware
x86_64 (Intel/AMD)
Relevant Logs
No response
Screenshots
No response
### Description
This is an old bug where if the hostname changes, kiosk doesn't work. Now that name change changes the hostname, it's been brought to the foreground as a serious issue
### Steps to Reproduce
Go to setting and rename archipelago to the new name.
Reboot
### Expected Behavior
Kiosk should come up
### Actual Behavior
Black screen
### Archipelago Version
1.7.101-alpha
### Hardware
x86_64 (Intel/AMD)
### Relevant Logs
_No response_
### Screenshots
_No response_
Root cause: Chromium's profile lock (SingletonLock) encodes hostname+pid; after a rename the stale lock reads as another computer holding the profile, Chromium silently refuses to start (--noerrdialogs) and the kiosk black-screens. Fix on main: a177ef3b — the kiosk launcher now clears Singleton{Lock,Cookie,Socket} before every Chromium start, and the rename handler clears them immediately as a hostname side-effect (covers nodes still on the old launcher). Ships via next OTA/RC; leaving open until verified with a rename+reboot on hardware.
Root cause: Chromium's profile lock (SingletonLock) encodes hostname+pid; after a rename the stale lock reads as another computer holding the profile, Chromium silently refuses to start (--noerrdialogs) and the kiosk black-screens. Fix on main: `a177ef3b` — the kiosk launcher now clears Singleton{Lock,Cookie,Socket} before every Chromium start, and the rename handler clears them immediately as a hostname side-effect (covers nodes still on the old launcher). Ships via next OTA/RC; leaving open until verified with a rename+reboot on hardware.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
This is an old bug where if the hostname changes, kiosk doesn't work. Now that name change changes the hostname, it's been brought to the foreground as a serious issue
Steps to Reproduce
Go to setting and rename archipelago to the new name.
Reboot
Expected Behavior
Kiosk should come up
Actual Behavior
Black screen
Archipelago Version
1.7.101-alpha
Hardware
x86_64 (Intel/AMD)
Relevant Logs
No response
Screenshots
No response
Root cause: Chromium's profile lock (SingletonLock) encodes hostname+pid; after a rename the stale lock reads as another computer holding the profile, Chromium silently refuses to start (--noerrdialogs) and the kiosk black-screens. Fix on main:
a177ef3b— the kiosk launcher now clears Singleton{Lock,Cookie,Socket} before every Chromium start, and the rename handler clears them immediately as a hostname side-effect (covers nodes still on the old launcher). Ships via next OTA/RC; leaving open until verified with a rename+reboot on hardware.