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

Terry Barnaby <terry1@xxxxxxxxxxx> · Mon, 19 Dec 2022 11:03:21 +0000



    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