Re: password issue with f40

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 19, 2024, at 13:25, Michael Hennebry <hennebry@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> I recently installed F40 from DVD.
> F40 and I are having a difference of opinion
> regarding what password I gave the initial user.
> F40 is winning.
> I find it hard to believe I typed in the same wrong password twice,
> but it's F40's opinion that counts.
> I try to login: click on the user and type in my password.
> F40 just goes back to the select a user screen.
> There is only one user.
> 
> My usual strategy is to boot a live disk
> and to edit the passwd and shadow files directly.
> It did not work.
> Now F40 no longer even gives me a chance to type in a password.
> It just blinks at me and goes right back to the select a user screen.
> What is going on?
> How do I fix it?
> I would much prefer not to reinstall.
> Even if I have to reinstall, I would like to know what is going on.
> My line from /etc/passwd :
> hennebry::1000:1000:The Michael:/home/hennebry:/bin/bash
> My line from /etc/shadow :
> hennebry::19893:0:99999:7:::

If what you posted is actually what’s in /etc/shadow then you’ve set a null password for your account. There should be no password prompt at all. 

However, if you’ve removed the “nullok” from the pam_unix.so lines in /etc/pam.d (or Fedora has finally removed it in F40), accounts with a null password hash entry won’t be able to log in. 

I’m going to assume from here on that you actually are using a password. 

So, if you’ve used a rescue disk to boot into Linux, chroot into your OS’s disk, and run “passwd” to change a password, or otherwise edit /etc/shadow or /etc/passwd (or other files in /etc), you most likely need to fix the selinux labels of those files. Easiest way to do this is to run “touch /.autorelabel” before exiting the chroot, then rebooting. That will force the OS to check the selinux labels on all the files in your filesystem upon boot. It might take some time. 

Another solution is to boot with “enforcing=0” in the kernel arguments, and see if you can log in. If so, then you can manually run a relabel by running “sudo restorecon -R -v /etc”. 


-- 
Jonathan Billings
--
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux