Good morning,
(f39 workstation last patched Thursday, August 22)
My boot logs (from journalctl -b > log20240826.txt) contain the warning below. Note that for context, I'm including the last 5 lines before the warning and the first 5 lines after the warning. I also added line numbers.
- - - - - -
1021 Aug 26 08:01:58 coyote systemd[1]: RTC configured in localtime, applying delta of -360 minutes to system time. 1022 Aug 26 08:01:58 coyote systemd[1]: Relabeled /dev, /dev/shm, /run, /sys/fs/cgroup in 78.112ms. 1023 Aug 26 08:01:58 coyote systemd[1]: systemd 254.16-1.fc39 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) 1024 Aug 26 08:01:58 coyote systemd[1]: Detected architecture x86-64. 1025 Aug 26 08:01:58 coyote systemd[1]: bpf-lsm: LSM BPF program attached /1026 Aug 26 08:01:58 coyote systemd-sysv-generator[595]: SysV service '/etc/rc.d/init.d/network' lacks a native systemd unit file. ~ Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it safe, robust and future-proof. ! This compatibility logic is deprecated, expect removal soon. !/ 1027 Aug 26 08:01:58 coyote systemd[1]: initrd-switch-root.service: Deactivated successfully. 1028 Aug 26 08:01:58 coyote systemd[1]: Stopped initrd-switch-root.service - Switch Root. 1029 Aug 26 08:01:58 coyote systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1. 1030 Aug 26 08:01:58 coyote systemd[1]: Created slice system-akmods\x2dkeygen.slice - Slice /system/akmods-keygen. 1031 Aug 26 08:01:58 coyote systemd[1]: Created slice system-getty.slice - Slice /system/getty.
- - - - - -
Line 1026 is the line of concern.
Is this a false alarm that I can ignore, or a ticking time bomb (a warning that needs attention soon), a problem for which I've been lucky to not yet see symptoms (other than the log entry), or a major immediate problem?
The warning suggests updating some package. I do a "dnf upgrade" weekly. Why did the update not already automatically happen?
On 27 Aug 2024, at 15:22, home user via users users@lists.fedoraproject.org wrote:
SysV service '/etc/rc.d/init.d/network'
That should not exist as it predates systemd world. Where did the files in /etc/rc.d come from?
Barry
On 8/27/24 11:34 AM, Barry wrote:
On 27 Aug 2024, at 15:22, home user via users users@lists.fedoraproject.org wrote:
SysV service '/etc/rc.d/init.d/network'
That should not exist as it predates systemd world. Where did the files in /etc/rc.d come from?
Barry
I don't know. If it helps, the stand-alone workstation was bought, assembled, and installed between 11 and 12 years ago. Something installed with something else? Something that should have been cleaned out by a past update, but wasn't?
That directory appears to be quite recent: -bash.1[~]: ls -la /etc/rc.d total 48 drwxr-xr-x. 10 root root 4096 Jul 24 18:00 . drwxr-xr-x. 204 root root 12288 Aug 22 19:17 .. drwxr-xr-x. 2 root root 4096 Aug 8 14:24 init.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc0.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc1.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc2.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc3.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc4.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc5.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc6.d -bash.2[~]:
What's the correct way to delete whatever should be deleted there?
On 27 Aug 2024, at 19:46, home user via users users@lists.fedoraproject.org wrote:
I don't know. If it helps, the stand-alone workstation was bought, assembled, and installed between 11 and 12 years ago. Something installed with something else? Something that should have been cleaned out by a past update, but wasn't?
I would have assumed that those file would have been removed when the RPM that owned them was removed.
Anyway this is what I have on a upgrade f40 system:
$ find /etc/rc.d/ /etc/rc.d/ /etc/rc.d/rc4.d /etc/rc.d/rc2.d /etc/rc.d/rc0.d /etc/rc.d/rc3.d /etc/rc.d/rc6.d /etc/rc.d/rc1.d /etc/rc.d/init.d /etc/rc.d/init.d/README /etc/rc.d/init.d/functions /etc/rc.d/rc5.d
I think it's safe for you to remove all the files in /etc/rc.d - suggest you back up /etc/rc.d just incase there is something needed.
Barry
On 8/28/24 4:12 AM, Barry Scott wrote:
On 27 Aug 2024, at 19:46, home user via users users@lists.fedoraproject.org wrote:
I don't know. If it helps, the stand-alone workstation was bought, assembled, and installed between 11 and 12 years ago. Something installed with something else? Something that should have been cleaned out by a past update, but wasn't?
I would have assumed that those file would have been removed when the RPM that owned them was removed.
Anyway this is what I have on a upgrade f40 system:
$ find /etc/rc.d/ /etc/rc.d/ /etc/rc.d/rc4.d /etc/rc.d/rc2.d /etc/rc.d/rc0.d /etc/rc.d/rc3.d /etc/rc.d/rc6.d /etc/rc.d/rc1.d /etc/rc.d/init.d /etc/rc.d/init.d/README /etc/rc.d/init.d/functions /etc/rc.d/rc5.d
I think it's safe for you to remove all the files in /etc/rc.d - suggest you back up /etc/rc.d just incase there is something needed.
Barry
Something else is puzzling me here. The warning during boot would not happen unless something#1 during boot is looking at and/or using something#2 in that directory, right? What? What will happen when that something#1 fails to find that directory?
I assume you're suggesting that I use "rm -rf". Am I correct? I think I can more easily get a good test by instead using "mv" to either rename or move the directory. Once it's definite that that broke nothing, I can do the "rm -rf".
My /etc/rc.d/ has a lot of links in its subdirectories. Should what they "point to" also be removed?
On 28 Aug 2024, at 16:54, home user mattisonw@comcast.net wrote:
Something else is puzzling me here. The warning during boot would not happen unless something#1 during boot is looking at and/or using something#2 in that directory, right? What? What will happen when that something#1 fails to find that directory?
The something is a systemd that has "generators" that create unit files from legacy config. For example the /etc/fstab is turned in mount units.
There is a generator for SysV legacy that is what you saw the error message from. That generator is due to be removed from systemd soon.
See https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.ht...
Barry
On 8/29/24 10:31 AM, Barry Scott wrote:
On 28 Aug 2024, at 16:54, home user mattisonw@comcast.net wrote:
Something else is puzzling me here. The warning during boot would not happen unless something#1 during boot is looking at and/or using something#2 in that directory, right? What? What will happen when that something#1 fails to find that directory?
The something is a systemd that has "generators" that create unit files from legacy config. For example the /etc/fstab is turned in mount units.
There is a generator for SysV legacy that is what you saw the error message from. That generator is due to be removed from systemd soon.
See https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.ht...
Barry
ok. Thank-you, Barry.
On 8/27/24 11:34 AM, Barry wrote:
On 27 Aug 2024, at 15:22, home user via users users@lists.fedoraproject.org wrote:
SysV service '/etc/rc.d/init.d/network'
That should not exist as it predates systemd world. Where did the files in /etc/rc.d come from?
Barry
I notice that that directory has a lot of redundant stuff, mostly soft? links, mostly old:
- - - - - -
-bash.9[etc]: ls -lRa /etc/rc.d /etc/rc.d: total 48 drwxr-xr-x. 10 root root 4096 Jul 24 18:00 . drwxr-xr-x. 204 root root 12288 Aug 22 19:17 .. drwxr-xr-x. 2 root root 4096 Aug 8 14:24 init.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc0.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc1.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc2.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc3.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc4.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc5.d drwxr-xr-x. 2 root root 4096 Jan 16 2024 rc6.d
/etc/rc.d/init.d: total 44 drwxr-xr-x. 2 root root 4096 Aug 8 14:24 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. -rwxrwxrwx. 1 root root 0 Oct 21 2017 cups -rw-r--r--. 1 root root 18229 Jan 29 2024 functions -rwxr-xr-x. 1 root root 8921 Jan 29 2024 network -rw-r--r--. 1 root root 1162 Jul 24 18:00 README
/etc/rc.d/rc0.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc1.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc2.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc3.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc4.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc5.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network
/etc/rc.d/rc6.d: total 8 drwxr-xr-x. 2 root root 4096 Jan 16 2024 . drwxr-xr-x. 10 root root 4096 Jul 24 18:00 .. lrwxrwxrwx. 1 root root 20 Mar 17 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 18 Mar 17 2013 K85ebtables -> ../init.d/ebtables lrwxrwxrwx. 1 root root 17 Sep 22 2015 K90network -> ../init.d/network -bash.10[etc]:
- - - - - -
Does that help?
On Tue, Aug 27, 2024 at 3:54 PM home user via users < users@lists.fedoraproject.org> wrote:
On 8/27/24 11:34 AM, Barry wrote:
On 27 Aug 2024, at 15:22, home user via users <
users@lists.fedoraproject.org> wrote:
SysV service '/etc/rc.d/init.d/network'
That should not exist as it predates systemd world. Where did the files in /etc/rc.d come from?
Barry
I notice that that directory has a lot of redundant stuff, mostly soft? links, mostly old:
Issues like this tend to accumulate when systems have been upgraded many times because upgrades don't remove old configuration data. I prefer to do a fresh install every once in a while to keep things clean and avoid wasting time sorting out issues like this. Now that systemd is firmly established, it would be a good time for a fresh install on a system that was first installed in sysv init days.
On 8/28/24 5:55 AM, George N. White III wrote:
On Tue, Aug 27, 2024 at 3:54 PM home user via users < users@lists.fedoraproject.org> wrote:
On 8/27/24 11:34 AM, Barry wrote:
On 27 Aug 2024, at 15:22, home user via users <
users@lists.fedoraproject.org> wrote:
SysV service '/etc/rc.d/init.d/network'
That should not exist as it predates systemd world. Where did the files in /etc/rc.d come from?
Barry
I notice that that directory has a lot of redundant stuff, mostly soft? links, mostly old:
Issues like this tend to accumulate when systems have been upgraded many times because upgrades don't remove old configuration data. I prefer to do a fresh install every once in a while to keep things clean and avoid wasting time sorting out issues like this. Now that systemd is firmly established, it would be a good time for a fresh install on a system that was first installed in sysv init days.
That would be good if this were not a dual-boot workstation and I were a real sys.admin. But this is a dual boot system and I'm certainly not a real sys.admin., making a fresh install very risky.
I look forward to the day that I can just get a whole new workstation - now that's a fresh install!
George N. White III:
Issues like this tend to accumulate when systems have been upgraded many times because upgrades don't remove old configuration data. I prefer to do a fresh install every once in a while to keep things clean and avoid wasting time sorting out issues like this. Now that systemd is firmly established, it would be a good time for a fresh install on a system that was first installed in sysv init days.
home user:
That would be good if this were not a dual-boot workstation and I were a real sys.admin. But this is a dual boot system and I'm certainly not a real sys.admin., making a fresh install very risky.
I look forward to the day that I can just get a whole new workstation
- now that's a fresh install!
If do-able (cost and somewhere to plug in), a second drive is a good way around this kind of thing.
Unplug the existing drive, do fresh install(s) onto the new drive. Experiment away. Then plug in the old drive, and copy any data over that you want (leave the original drive in its original condition).
On 8/27/24 8:19 AM, home user via users wrote:
Good morning,
(f39 workstation last patched Thursday, August 22)
My boot logs (from journalctl -b > log20240826.txt) contain the warning below. Note that for context, I'm including the last 5 lines before the warning and the first 5 lines after the warning. I also added line numbers.
[snip]
/1026 Aug 26 08:01:58 coyote systemd-sysv-generator[595]: SysV service '/etc/rc.d/init.d/network' lacks a native systemd unit file. ~ Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it safe, robust and future-proof. ! This compatibility logic is deprecated, expect removal soon. !/
[snip]
Line 1026 is the line of concern.
Is this a false alarm that I can ignore, or a ticking time bomb (a warning that needs attention soon), a problem for which I've been lucky to not yet see symptoms (other than the log entry), or a major immediate problem?
The warning suggests updating some package. I do a "dnf upgrade" weekly. Why did the update not already automatically happen?
Wednesday evening, I renamed "/etc/rc.d/", rebooted, and checked the logs. I saw no indication that the rename caused trouble. Yesterday morning's boot also showed no indication of trouble caused by the rename. Yesterday's weekly patching and subsequent reboot showed no signs of trouble that might have been caused by the rename. Likewise this morning's boot.
I thank Barry for his help, and George and Tim for their suggestions.
There are other issues in the boot logs. I will start new separate threads for those soon, one at a time.
Bill.
On Fri, Aug 30, 2024, at 8:28 AM, home user via users wrote:
Wednesday evening, I renamed "/etc/rc.d/", rebooted, and checked the logs.
Not that it really matters, but you could put back the few parts that come from systemd:
rpm -qil systemd | grep "etc/rc.d"
/etc/rc.d /etc/rc.d/init.d /etc/rc.d/init.d/README
You can verify with:
rpm -V systemd-255.10-3.fc40.x86_64
I get no output from that, but I think you will see the above three items called out.
The only reason you might need those items is if you wanted to install an rc.local file.
On 30 Aug 2024, at 16:36, Doug Herr fedoraproject.org@wombatz.com wrote:
The only reason you might need those items is if you wanted to install an rc.local file.
Better to write a systemd service to do what you need and not use the legacy rc.local.
As I mentioned systemd is going to stop supporting the old rc.d stuff in a up coming releaes. That I assume will also mean that the rc-local.service will go away.
Barry
-
Barry -
Barry Scott
-
Doug Herr -
George N. White III -
home user -
Tim