Bugzilla – Bug 1224461
Shell other than default system shells prevents user logon post-install
Last modified: 2024-05-22 14:22:38 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Build Identifier: User with alternate shell (fish, zsh, etc) must install in the core via transactional-updates, but installer rightly does not add user specified packages from previous install to upgrade install. If user has alternate shell specified in /etc/passwd, login is not possible. Reproducible: Always Steps to Reproduce: 1. Add alternate shell to core OS 2. Change user shell 3. Perform RC2 tik update Actual Results: Unable to login; no root login is possible in an upgraded or fresh RC2. Expected Results: At minimum, detect user shell is not a system default and warn/block the upgrade, recommend user logon to old system, chsh, and restart upgrade.
I'm torn on this one. Changing the default shell for your admin/root account is never a good idea - I've done that before on servers just to lock myself out when zsh wasn't installed On Aeon, your first account is the admin/root account, so..same rule should apply And typically speaking with Aeon, we do not spend time supporting things which users shouldn't do But..maybe I'll see how easy it is to identify if the default shell was changed during the migration and force a move to /bin/bash
Prio Med
> On Aeon, your first account is the admin/root account, so..same rule should apply I do get where you are coming from; beyond Aeon, it's almost universally common for a Linux system to offer user/admin accounts so it's likely over time this will trip up future users doing migration or new Aeon release reinstalls. While I don't disagree with the cleaner approach you've chosen for RC2+, this example does show a practical issue with going this route. An installer warning would be good enough, would you agree?
addressed in https://github.com/sysrich/tik/pull/16