Bug 1224461

Summary: Shell other than default system shells prevents user logon post-install
Product: [openSUSE] openSUSE Aeon Reporter: Mike Watkins <solutionroute>
Component: InstallationAssignee: Richard Brown <rbrown>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P3 - Medium    
Version: Current   
Target Milestone: ---   
Hardware: All   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Mike Watkins 2024-05-19 23:14:28 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.
Comment 1 Richard Brown 2024-05-21 08:05:15 UTC
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
Comment 2 Richard Brown 2024-05-21 08:05:56 UTC
Prio Med
Comment 3 Mike Watkins 2024-05-22 05:10:08 UTC
> 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?
Comment 4 Richard Brown 2024-05-22 14:22:38 UTC
addressed in https://github.com/sysrich/tik/pull/16