Re: Fedora37: Fails to boot with NISDOMAIN=... in /etc/sysconfig/network

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

 



Well the /etc/nsswitch.conf is as set by authselect:

# Generated by authselect on Sun Dec 11 04:58:36 2022
# Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
# You can stop authselect from managing your configuration by calling 'authselect opt-out'.
# See authselect(8) for more details.

# In order of likelihood of use to accelerate lookup.
passwd:     files nis systemd
shadow:     files nis
group:      files nis systemd
hosts:      files myhostname resolve [!UNAVAIL=return] nis dns
services:   files nis
netgroup:   files nis
automount:  files nis

aliases:    files nis
ethers:     files nis
gshadow:    files nis
networks:   files nis dns
protocols:  files nis
publickey:  files nis
rpc:        files nis

All the "users" for the system daemons should be in the files.

Really on this host the nis should be removed as it is the nis master. The config came from general config for clients and servers and I will remove the nis auth from the server. However this worked fine on Fedora35, so it is a change in Fedora37.

Although my config is really wrong, I wouldn't have thought this should cause a systemd boot fail.


On 18/12/2022 18:23, Roger Heflin wrote:
If the nisdomain is not responding, I would claim the system should still boot, so I would think that is a bug.  But if systemd/pam is not timing out on the non-responding nisdomain or the timeout is too high then I would think that might screw up a significant part of the system because lookups of passwd/hosts/group access may not work, depending on where else nis pieces are setup.  I would think if file was first and there is a valid entry in the file that it should not go to nisdomain, but that may depend on what the order is in /etc/nsswitch.conf.


On Sun, Dec 18, 2022 at 10:03 AM Terry Barnaby <terry1@xxxxxxxxxxx> wrote:
A strange one this. I was just updating a Fedora35 server to Fedora37,
using a full reinstall and then copying configuration files from the old
system.

The system failed to boot with lots of strange issues with systemd. It
started with console messages like:

[ TIME ] Timeout waiting for device dev-zram0.device - /dev/zram0.

Some further issues with zram, followed by some other services starting
fine then the system gets in a loop:

[ FAILED] Failed to start systemd-udevd.service - ...

[ FAILED] Failed to start systemd-oomd.service - ...

None of this was logged in /var/log/messages.

After some tracking down on a VM, I found the issue was somehow caused
by having "NISDOMAIN=kingnet" in the file /etc/sysconfig/network. This
came from an old client configuration ,setting the NIS domain. This was
not actually needed on the server and in fact not needed on the clients
now as the DHCP does this on our systems, it was a hangback from 20
years or so.

I have no idea why this has caused the boot fail though, I thought I'd
mention it in case anyone else sees it. I will report it as a "bug"
against systemd although I'm not sure it is really a systemd issue or
really a bug at all, but a bit nasty as the system fails to boot.

Terry
_______________________________________________
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

_______________________________________________
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


_______________________________________________
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