On 6/12/21 11:09 PM, Tim via users wrote:
On Sat, 2021-06-12 at 22:50 -0700, ToddAndMargo via users wrote:
So why am I getting "file not found" in the following?
If your files are at the expected paths, check SELinux. It's a common
cause of unexpected and unexplained "file not found" errors.
Oh poop! Figured it out!
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service;
enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-06-12 14:49:05 PDT; 8h
On Sat, 2021-06-12 at 22:50 -0700, ToddAndMargo via users wrote:
> So why am I getting "file not found" in the following?
If your files are at the expected paths, check SELinux. It's a common
cause of unexpected and unexplained "file not found" errors.
--
uname -rsvp
Linux 5.11.21-100.fc32.x
On 6/12/21 4:39 PM, ToddAndMargo via users wrote:
Hi All,
Just upgraded from FC33 to FC34.
# rpm -aq bind\*
bind-export-libs-9.11.11-1.fc30.x86_64
bind-license-9.16.16-1.fc34.noarch
bind-dnssec-doc-9.16.16-1.fc34.noarch
bind-libs-9.16.16-1.fc34.x86_64
bind-utils-9.16.16-1.fc34.x86_64
bind-dnss
Hi,
I just upgraded to f34 and now my menus are against the top of the
screen and the apps are along the bottom. How do I move them all to
the bottom?
I've updated all the extensions that I could at extensions.gnome.org,
but I don't recall which extensions perform which functions, and it
appears
On 13/06/2021 08:41, Samuel Sieb wrote:
So that gave me the clue that led to the real problem. The service is included
in the initrd and masking it on the system doesn't change that. Even
re-creating the initrd with dracut after masking didn't change anything.
And also the nm-initrd.service
On 6/12/21 5:13 PM, Todd Zullinger wrote:
Hi,
ToddAndMargo via users wrote:
Hi All,
Just upgraded from FC33 to FC34.
FC34 broke my bind. Here are "some" of the repeating errors:
Bind was updated from 9.11 to 9.16 in Fedora 34:
https://fedoraproject.org/wiki/Changes/BIND9.16
You'll ne
On 2021-06-12 4:59 p.m., Ed Greshko wrote:
On 13/06/2021 07:36, Samuel Sieb wrote:
Yes, but I would think there is still a period of time associated
with calling the service, discovering the link to /dev/null
and then understanding the service has completed.
It isn't as if the service file n
On 6/12/21 5:26 PM, Tom Horsley wrote:
On Sat, 12 Jun 2021 16:39:45 -0700
ToddAndMargo via users wrote:
Please note this all worked perfectly under FC33
Named completely ceased working for me under f34 as well
(I just run a server for my local LAN). Apparently some
setting in the new config f
On Sat, 12 Jun 2021 16:39:45 -0700
ToddAndMargo via users wrote:
> Please note this all worked perfectly under FC33
Named completely ceased working for me under f34 as well
(I just run a server for my local LAN). Apparently some
setting in the new config files screwed something up.
Rather than t
On 6/12/21 5:14 PM, Ed Greshko wrote:
Since it is being "pulled in" by other services I think you may expect
to see this.
That would be true if it were only disabled. Once it's masked it can't
be started by systemd until it's been unmasked.
___
u
On 6/12/21 4:46 PM, Patrick O'Callaghan wrote:
I've masked it and rebooted. Makes no difference to boot time in my
case.
Have you checked with systend-analyze blame again to see what else might
be delaying your boot?
___
users mailing list -- users@
Hi,
ToddAndMargo via users wrote:
> Hi All,
>
> Just upgraded from FC33 to FC34.
>
> FC34 broke my bind. Here are "some" of the repeating errors:
Bind was updated from 9.11 to 9.16 in Fedora 34:
https://fedoraproject.org/wiki/Changes/BIND9.16
You'll need to review the upstream documentati
On 13/06/2021 07:36, Samuel Sieb wrote:
Yes, but I would think there is still a period of time associated with calling
the service, discovering the link to /dev/null
and then understanding the service has completed.
It isn't as if the service file no longer exits.
"impossible to start them
Hi All,
Just upgraded from FC33 to FC34.
FC34 broke my bind. Here are "some" of the repeating errors:
# named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts
xyz.hosts:3: ignoring out-of-zone data (xyz.local)
xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local)
1
On 6/12/21 4:29 PM, Ed Greshko wrote:
On 13/06/2021 07:22, Samuel Sieb wrote:
On 2021-06-12 4:14 p.m., Ed Greshko wrote:
On 13/06/2021 07:06, Samuel Sieb wrote:
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m.,
On 13/06/2021 07:22, Samuel Sieb wrote:
On 2021-06-12 4:14 p.m., Ed Greshko wrote:
On 13/06/2021 07:06, Samuel Sieb wrote:
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 202
On 2021-06-12 4:14 p.m., Ed Greshko wrote:
On 13/06/2021 07:06, Samuel Sieb wrote:
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
Accord
On 13/06/2021 07:06, Samuel Sieb wrote:
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
According to https://github.com/openzfs/zfs/issues
On 13/06/2021 06:57, Ed Greshko wrote:
But, does your plot show a difference?
Speaking of your plot.
Don't you think the time between
sys-devices-pci:00-:00:1a.0-usb1-1\x2d1-1\x2d1.6-1\x2d1.6.2.device and
dev-disk-by\x2dpath-pci\x2d:00:14.0\x2dusb\x2d0:3:1.0\x2dscsi\x2d0:0:0:1
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
According to https://github.com/openzfs/zfs/issues/10891 has been
depricated since last yea
On 13/06/2021 06:46, Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
According to https://github.com/openzfs/zfs/issues/10891 has been
depricated since last year.
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
> On 2021-06-12 10:19 a.m., Tom Horsley wrote:
> > On Sat, 12 Jun 2021 10:44:19 -0600
> > Joe Zeff wrote:
> >
> > > According to https://github.com/openzfs/zfs/issues/10891 has been
> > > depricated since last year. Disable and mask it and tha
On 2021-06-12 2:15 p.m., Patrick Dupre wrote:
dnf system-upgrade download --refresh --releasever=34
provides all these errors,
How can I avoid to demove all these packages?
Error:
Problem 1: package perl-Geometry-Primitive-0.24-1.fc32.noarch requires
perl(:MODULE_COMPAT_5.30.2), but none o
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
According to https://github.com/openzfs/zfs/issues/10891 has been
depricated since last year. Disable and mask it and that should fix
your issue.
It is listed as a "static" service on my system. C
dnf system-upgrade download --refresh --releasever=34
provides all these errors,
How can I avoid to demove all these packages?
Error:
Problem 1: package perl-Geometry-Primitive-0.24-1.fc32.noarch requires
perl(:MODULE_COMPAT_5.30.2), but none of the providers can be installed
- perl-libs-4
On 5/29/21 12:54 PM, Tim Evans wrote:
On 5/4/21 8:33 AM, Jouk Jansen wrote:
Hi All,
I'm using one of my Fedora machines as a router between 2 networks.
The two
network devices on the machine are called enp0s25 and tun0. On F33 it
worked
as expected. However, after an upgrade to F34 It looks l
On 6/12/21 11:54 AM, Patrick O'Callaghan wrote:
Not my case. I don't have systemd-udev-settle.service. This is a fresh
install of F34.
Ok, you can still use systemd-analyze blame to find out what's causing
the delay.
___
users mailing list -- users@
On Sat, 2021-06-12 at 18:54 +0100, Patrick O'Callaghan wrote:
> On Sat, 2021-06-12 at 11:31 -0400, Frank McCormick wrote:
> > I found and fixed the problem. The key was in my systemd log.
> >
> > 1.825245] udevadm[363]: systemd-udev-settle.service is deprecated.
> > Please fix nm-initrd.service
On Sat, 2021-06-12 at 11:31 -0400, Frank McCormick wrote:
> I found and fixed the problem. The key was in my systemd log.
>
> 1.825245] udevadm[363]: systemd-udev-settle.service is deprecated.
> Please fix nm-initrd.service not to pull it in
>
>
> Personally I think this should be spread more
On Sat, 2021-06-12 at 07:25 -0600, Chris Murphy wrote:
> Both problems need logs. It's quite a bit over kill but these boot
> parameters will help provide enough info.
>
> systemd.log_level=debug udev.log-priority=debug
> rd.debug x-systemd.timeout=180
>
> The debug options are resource inventiv
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:
> According to https://github.com/openzfs/zfs/issues/10891 has been
> depricated since last year. Disable and mask it and that should fix
> your issue.
It is listed as a "static" service on my system. Can those be
disabled or masked?
_
On 6/12/21 6:32 AM, Frank McCormick wrote:
Systemd-analyze blame pinpoints "systemd-udev-settle.service" more than
a 2 minute wait!!
According to https://github.com/openzfs/zfs/issues/10891 has been
depricated since last year. Disable and mask it and that should fix
your issue.
On Sat, Jun 12, 2021 at 9:32 AM Frank McCormick wrote:
> I found and fixed the problem. The key was in my systemd log.
>
> 1.825245] udevadm[363]: systemd-udev-settle.service is deprecated.
> Please fix nm-initrd.service not to pull it in
>
Interesting; on my F34 system, the message mentions n
I found and fixed the problem. The key was in my systemd log.
1.825245] udevadm[363]: systemd-udev-settle.service is deprecated.
Please fix nm-initrd.service not to pull it in
Personally I think this should be spread more...it seems there are quite
a few with this problem
___
On 12/06/2021 21:45, Stephen Morris wrote:
The problem I have is Gnome scales when the windows size changes, but KDE does
not, which is why I put the modelines in the conf file, and then KDE does scale.
I think it is going to be "difficult" to track down the actual culprit. I say
that becaus
On 12/6/21 14:29, Samuel Sieb wrote:
On 2021-06-11 6:46 p.m., Stephen Morris wrote:
Below are the modelines that I had to add into the config over and
above what xrandr provided as the supported resolutions,
coincidentally the supported resolutions that xrandr displayed also
happened to match
Both problems need logs. It's quite a bit over kill but these boot
parameters will help provide enough info.
systemd.log_level=debug udev.log-priority=debug
rd.debug x-systemd.timeout=180
The debug options are resource inventive and slow down boot by allot. The
point of the timeout is hopefully
Systemd-analyze blame pinpoints "systemd-udev-settle.service" more than
a 2 minute wait!!
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs
On Fri, 2021-06-11 at 20:26 -0600, Joe Zeff wrote:
> On 6/11/21 8:16 PM, Frank McCormick wrote:
> >
> > The boot is interrupted for a longtime (2 minutes) while
> > a start job runs for wait for udev to complete initialization.
> >
> > The timeout is three minutes and it almost reaches that point
40 matches
Mail list logo
