Re: NM, wpa_supplicant flooding error log

2021-07-01 Thread Ed Greshko

On 02/07/2021 09:45, Jon LaBadie wrote:

On Fri, Jul 02, 2021 at 05:36:30AM +0800, Ed Greshko wrote:


Well, what I would do in this case is to first do "lspci -v" and compare my 
hardware specs and
driver in use with that reported in the BZ to see how they match up.  It is not 
inconceivable that
an error message may be the same while the underlying issue different than 
reported in a BZ.



Not a driver match.  Bug report is Broadcom, mine is Intel (iwlwifi)




I see.  So, in summary.  Your wifi is working OK.  The device wlo1 is connected 
to an access point.
And the logs are getting flooded with messages.

Would you mind to post the output of "sudo lspci -vnn" for that device for 
completeness?

It may be that iwlwifi has been updated upstream but the changes have yet made 
it to fedora.
Are you on F34?  I don't think you mentioned it

--
Remind me to ignore comments which aren't germane to the thread.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread Tim via users
On Thu, 2021-07-01 at 12:21 -0400, Tom Horsley wrote:
> If you are never going to want to hibernate, do what I do
> and remove the resume= from the kernel boot line in grub. Then
> it won't even look for a device to resume from.

It was my understanding that there didn't need to be a resume parameter
on the kernel line to be able to resume, so long as the system could
find the swap partition by itself without problems.  It was only needed
to ensure it found the right one.

-- 
 
uname -rsvp
Linux 3.10.0-1160.31.1.el7.x86_64 #1 SMP Thu Jun 10 13:32:12 UTC 2021 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: NM, wpa_supplicant flooding error log

2021-07-01 Thread Jon LaBadie

On Fri, Jul 02, 2021 at 05:36:30AM +0800, Ed Greshko wrote:

On 02/07/2021 00:40, Jon LaBadie wrote:

On Thu, Jul 01, 2021 at 07:35:12AM -0300, George N. White III wrote:

On Thu, 1 Jul 2021 at 02:02, Jon LaBadie  wrote:


Laptop running F34 with an "Intel Cannon Point-LP CNVi [Wireless-AC]"
controller.


Every 10 seconds I get this error message (/var/log/messages):

   wpa_supplicant[78893]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22

A websearch shows this is not an uncommon problem though most
see it every 1 second, not 10 seconds.  I've tried numerous
suggested solutions that were all ineffective (reboot after
changes).  These included:

- downgrading wpa_supplicant (none available)
- downgrading NM (restored current)
- eliminating all NM interfaces except the active one
- eliminated the ethernet (wired) NM interface
- several .conf changes for NM and wpa_supplicant

Still the messages keep coming (200K+).

Any suggestions?



Have you seen ?
This indicates the messages are due to wpa_supplicant not properly handling
your wifi hardware, so you may want to check upstream.   This could
be an issue with the firmware version provided by Fedora.

My Fedora 33 system has wpa_supplicant messages in "the systemd(1)
journal as written by systemd-journald.service(8)."  so either Fedora 34 has
changed logging for wpa_supplicant or you have a local wpa_supplicant
version/configuration.

This sort of problem often appears across multiple linux distros, so it is
worth
checking for similar issues on other distros, in particular Ubuntu and
Arch.



My bugzilla-foo is weak, I overlooked that one.  Couple of things.

I'm not having connection problems at all.

Yes, most of the websearch results are Arch & Ubuntu
In that bugzilla report the messages the messages end with "retries=1",
as do most of the found reports.  Mine do not.

Logging to /var/log/message is just my old school habit.  systemD
journal gets them too.

wpa_supplicant is totally stock.  Never even tried to look at config
before.

Does wifi work if wpa_supplicant service is disabled?


Well, what I would do in this case is to first do "lspci -v" and compare my 
hardware specs and
driver in use with that reported in the BZ to see how they match up.  It is not 
inconceivable that
an error message may be the same while the underlying issue different than 
reported in a BZ.



Not a driver match.  Bug report is Broadcom, mine is Intel (iwlwifi)


--
Jon H. LaBadie  jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Questions on creating RPM Package??

2021-07-01 Thread Samuel Sieb

On 2021-06-28 3:39 p.m., Michael D. Setzer II via users wrote:

That would then add options to the grub boot menu
similar to how memtest worked to add option. It
would load kernel image, and then g4l in ram to
run. Looked at memtest, but note that they don't
have an option with the EFI version, which was my
new question with shift to more systems using that?
Issues with creating signed kernels?


I think memtest just didn't work with EFI at all, but there is also the 
more general problem of secure boot.  You have to sign the kernel you 
use with a recognized key.  Is it a special kernel or can you use the 
default Fedora kernel?



Wondering if there might be information or
someone might know of a list or page?


The devel list would probably be a better place to ask.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread Jonathan Ryshpan
On Thu, 2021-07-01 at 07:26 -0700, stan via users wrote:
> On Thu, 01 Jul 2021 07:13:38 -0700
> Jonathan Ryshpan  wrote:
> 
> > The system always tries to restore from hibernation on startup; this
> > causes about a 1-1/2 minute delay.  I see no reason for this, since
> > the system is halted by "(Start)->Shut Do..."  Here is an extract
> > from the system log with inserted comments.
> 
> A long time ago I remember having a problem like this, and it was
> because the kernel had a resume on the command line, telling it to try
> an ancient hibernation on a swap partition.  When I removed that, it
> went away.  You could interrupt the boot and look at the kernel command
> line, and if it is there remove it before booting to see if that is the
> cause.

Interesting!  Did you remove the "resume=/..." from the command line,
or the ancient hibernation from the swap partition?  If the
hibernation, how did you remove it?

-- 
Many Thanks - Jonathan Ryshpan 

Honesty may not be the best policy, 
but it is worth trying once in a while.
--Richard Nixon
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[389-users] Re: Replica's nsslapd-referral uri is ldap: instead of ldap:

2021-07-01 Thread Mark Reynolds

Hi Brian,

You can just change nsslapd-referral attribute to use ldaps instead of 
ldap.


Now you "should" be able to do that in the console, but I just found out 
that there is a bug in the console where we don't actually grab the 
referrals from the mapping tree entry.   Glad I found it now 
because the cockpit console is going through a rewrite (to migrate to 
Patternfly 4).  So I will fix that, but it doesn't help you today.


So for now you will need to use ldapmodify to change the 
nsslapd-referral attribute.  I would say to use dsconf but it is also 
broken for properly setting referrals . Once I fix dsconf it 
would work like this:


#dsconf slapd-supplier1 backend suffix set userroot --del-referral 
ldap://localhost:636


#dsconf slapd-supplier1 backend suffix set userroot --add-referral 
ldaps://localhost:636


Right now dsconf updates the referral on the wrong entry :-( We'll get 
this all fixed up!


HTH,

Mark

On 7/1/21 6:04 PM, Collins, Brian (CAI - Atlanta) wrote:


Good day,

I am doing prep work for replacing our older 389 servers (1.3.8) 
running on RHEL 7 with newer ones on RHEL 8 and 1.4.4.


I have the two RHEL 7 boxes in a multi-master replication setup.

For this phase of testing I have one read-only replica on 1.4.4, as a 
consumer to the two current servers.  I set up a Linux client to login 
using SSSD, bound to the consumer. It works fine except when I want to 
change passwords.  I was getting "Operation requires a secure 
connection."  After a lot of digging, I think I found the culprit 
there: on the consumer, in "dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping 
tree,cn=config" the nsslapd-referral uri for my two current servers is 
ldap: instead of ldaps:.  Indeed, in the cockpit console, the Remote 
RUV list shows both servers as ldap:.


 But on the two suppliers, the old servers, the referral uri is ldaps.

When I set up the replication agreement for the new consumer, I did it 
just as I did for the current setup, so I don't feel like that's where 
I went wrong.


Thanks in advance for any pointers,

Brian Collins


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[389-users] Replica's nsslapd-referral uri is ldap: instead of ldap:

2021-07-01 Thread Collins, Brian (CAI - Atlanta)
Good day,

I am doing prep work for replacing our older 389 servers (1.3.8) running on 
RHEL 7 with newer ones on RHEL 8 and 1.4.4.

I have the two RHEL 7 boxes in a multi-master replication setup.

For this phase of testing I have one read-only replica on 1.4.4, as a consumer 
to the two current servers.  I set up a Linux client to login using SSSD, bound 
to the consumer. It works fine except when I want to change passwords.  I was 
getting "Operation requires a secure connection."  After a lot of digging, I 
think I found the culprit there: on the consumer, in "dn: 
cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" the nsslapd-referral uri 
for my two current servers is ldap: instead of ldaps:.  Indeed, in the cockpit 
console, the Remote RUV list shows both servers as ldap:.
 But on the two suppliers, the old servers, the referral uri is ldaps.

When I set up the replication agreement for the new consumer, I did it just as 
I did for the current setup, so I don't feel like that's where I went wrong.

Thanks in advance for any pointers,
Brian Collins

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: NM, wpa_supplicant flooding error log

2021-07-01 Thread Ed Greshko

On 02/07/2021 00:40, Jon LaBadie wrote:

On Thu, Jul 01, 2021 at 07:35:12AM -0300, George N. White III wrote:

On Thu, 1 Jul 2021 at 02:02, Jon LaBadie  wrote:


Laptop running F34 with an "Intel Cannon Point-LP CNVi [Wireless-AC]"
controller.


Every 10 seconds I get this error message (/var/log/messages):

   wpa_supplicant[78893]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22

A websearch shows this is not an uncommon problem though most
see it every 1 second, not 10 seconds.  I've tried numerous
suggested solutions that were all ineffective (reboot after
changes).  These included:

- downgrading wpa_supplicant (none available)
- downgrading NM (restored current)
- eliminating all NM interfaces except the active one
- eliminated the ethernet (wired) NM interface
- several .conf changes for NM and wpa_supplicant

Still the messages keep coming (200K+).

Any suggestions?



Have you seen ?
This indicates the messages are due to wpa_supplicant not properly handling
your wifi hardware, so you may want to check upstream.   This could
be an issue with the firmware version provided by Fedora.

My Fedora 33 system has wpa_supplicant messages in "the systemd(1)
journal as written by systemd-journald.service(8)."  so either Fedora 34 has
changed logging for wpa_supplicant or you have a local wpa_supplicant
version/configuration.

This sort of problem often appears across multiple linux distros, so it is
worth
checking for similar issues on other distros, in particular Ubuntu and
Arch.



My bugzilla-foo is weak, I overlooked that one.  Couple of things.

I'm not having connection problems at all.

Yes, most of the websearch results are Arch & Ubuntu
In that bugzilla report the messages the messages end with "retries=1",
as do most of the found reports.  Mine do not.

Logging to /var/log/message is just my old school habit.  systemD
journal gets them too.

wpa_supplicant is totally stock.  Never even tried to look at config
before.

Does wifi work if wpa_supplicant service is disabled?


Well, what I would do in this case is to first do "lspci -v" and compare my 
hardware specs and
driver in use with that reported in the BZ to see how they match up.  It is not 
inconceivable that
an error message may be the same while the underlying issue different than 
reported in a BZ.



--
Remind me to ignore comments which aren't germane to the thread.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: NM, wpa_supplicant flooding error log

2021-07-01 Thread Jon LaBadie

On Thu, Jul 01, 2021 at 07:35:12AM -0300, George N. White III wrote:

On Thu, 1 Jul 2021 at 02:02, Jon LaBadie  wrote:


Laptop running F34 with an "Intel Cannon Point-LP CNVi [Wireless-AC]"
controller.


Every 10 seconds I get this error message (/var/log/messages):

   wpa_supplicant[78893]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22

A websearch shows this is not an uncommon problem though most
see it every 1 second, not 10 seconds.  I've tried numerous
suggested solutions that were all ineffective (reboot after
changes).  These included:

- downgrading wpa_supplicant (none available)
- downgrading NM (restored current)
- eliminating all NM interfaces except the active one
- eliminated the ethernet (wired) NM interface
- several .conf changes for NM and wpa_supplicant

Still the messages keep coming (200K+).

Any suggestions?



Have you seen ?
This indicates the messages are due to wpa_supplicant not properly handling
your wifi hardware, so you may want to check upstream.   This could
be an issue with the firmware version provided by Fedora.

My Fedora 33 system has wpa_supplicant messages in "the systemd(1)
journal as written by systemd-journald.service(8)."  so either Fedora 34 has
changed logging for wpa_supplicant or you have a local wpa_supplicant
version/configuration.

This sort of problem often appears across multiple linux distros, so it is
worth
checking for similar issues on other distros, in particular Ubuntu and
Arch.



My bugzilla-foo is weak, I overlooked that one.  Couple of things.

I'm not having connection problems at all.

Yes, most of the websearch results are Arch & Ubuntu
In that bugzilla report the messages the messages end with "retries=1",
as do most of the found reports.  Mine do not.

Logging to /var/log/message is just my old school habit.  systemD
journal gets them too.

wpa_supplicant is totally stock.  Never even tried to look at config
before.

Does wifi work if wpa_supplicant service is disabled?

Jon

--
Jon H. LaBadie  jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread Tom Horsley
If you are never going to want to hibernate, do what I do
and remove the resume= from the kernel boot line in grub. Then
it won't even look for a device to resume from.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread Tim via users
On Thu, 2021-07-01 at 07:13 -0700, Jonathan Ryshpan wrote:
> The system always tries to restore from hibernation on startup; this
> causes about a 1-1/2 minute delay.  I see no reason for this, since
> the system is halted by "(Start)->Shut Do..." 

I was of the understanding that when a system fires up it looks to see
if it should be resuming, tries to, then just boots normally if it
can't.  It just seems to look for suitable resumption data in the swap
file, that's its test.  If it finds nothing useful there, it cold
boots.  If what's there has something wrong with it, it cold boots.

As has been pointed out by another poster, this attempt is quickly over
and done with (both in your logs, and in the normal run of things for
other people).
 
-- 
 
uname -rsvp
Linux 3.10.0-1160.31.1.el7.x86_64 #1 SMP Thu Jun 10 13:32:12 UTC 2021 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread stan via users
On Thu, 01 Jul 2021 07:13:38 -0700
Jonathan Ryshpan  wrote:

> The system always tries to restore from hibernation on startup; this
> causes about a 1-1/2 minute delay.  I see no reason for this, since
> the system is halted by "(Start)->Shut Do..."  Here is an extract
> from the system log with inserted comments.

A long time ago I remember having a problem like this, and it was
because the kernel had a resume on the command line, telling it to try
an ancient hibernation on a swap partition.  When I removed that, it
went away.  You could interrupt the boot and look at the kernel command
line, and if it is there remove it before booting to see if that is the
cause.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: System always "Resumes from hibernation" on startup

2021-07-01 Thread Greg Woods
I would bet that if you "cat /proc/cmdline" you will see a resume=
parameter, but even if not this may be the default. At any rate, it doesn't
look like your resume attempt is the reason for the delay, as the delay has
already occurred when the resume is attempted:

Jun 30 12:19:40 amito kernel: Console: switching to colour frame buffer
device 240x75

Jun 30 12:21:08 amito dracut-initqueue[526]: WARNING: D-Bus notification
failed: Transport endpoint is not connected

Note that delay has already occurred at this point.

Jun 30 12:21:08 amito systemd[1]: Found device /dev/mapper/fedora-swap.
Jun 30 12:21:08 amito systemd[1]: Starting Resume from hibernation using
device /dev/mapper/fedora-swap...
Jun 30 12:21:08 amito systemd-hibernate-resume[547]: Could not resume from
'/dev/mapper/fedora-swap' (253:1).

...and the resume failure is a second or less after the attempted resume
starts.

--Greg


On Thu, Jul 1, 2021 at 8:14 AM Jonathan Ryshpan  wrote:

> The system always tries to restore from hibernation on startup; this
> causes about a 1-1/2 minute delay.  I see no reason for this, since the
> system is halted by "(Start)->Shut Do..."  Here is an extract from the
> system log with inserted comments.
>
> Jun 30 12:19:38 amito dracut-initqueue[523]: inactive
> '/dev/fedora/windows' [400.00 GiB] inherit
> Jun 30 12:19:38 amito dracut-initqueue[523]: inactive
> '/dev/fedora/root' [100.00 GiB] inherit
> Jun 30 12:19:38 amito dracut-initqueue[523]: inactive
> '/dev/fedora/swap' [24.00 GiB] inherit
> Jun 30 12:19:38 amito dracut-initqueue[523]: inactive
> '/dev/fedora/home' [<1.31 TiB] inherit
> Jun 30 12:19:38 amito systemd[1]: Found device /dev/mapper/fedora-root.
> 
> Jun 30 12:19:38 amito systemd[1]: Reached target Initrd Root Device.
> Jun 30 12:19:40 amito kernel: fbcon: Taking over console
> Jun 30 12:19:40 amito kernel: Console: switching to colour frame buffer
> device 240x75
> 
> Jun 30 12:21:08 amito dracut-initqueue[526]: WARNING: D-Bus notification
> failed: Transport endpoint is not connected
> Jun 30 12:21:08 amito systemd[1]: Found device /dev/mapper/fedora-swap.
> Jun 30 12:21:08 amito systemd[1]: Starting Resume from hibernation using
> device /dev/mapper/fedora-swap...
> Jun 30 12:21:08 amito systemd-hibernate-resume[547]: Could not resume from
> '/dev/mapper/fedora-swap' (253:1).
> Jun 30 12:21:08 amito systemd[1]:
> systemd-hibernate-resume@dev-mapper-fedora\x2dswap.service: Deactivated
> successfully.
> Jun 30 12:21:08 amito systemd[1]: Finished Resume from hibernation using
> device /dev/mapper/fedora-swap.
> Jun 30 12:21:08 amito kernel: PM: Image not found (code -22)
> Jun 30 12:21:08 amito kernel: kauditd_printk_skb: 7 callbacks suppressed
>
> System configuration"
>Operating System: Fedora 34
>KDE Plasma Version: 5.22.2
>KDE Frameworks Version: 5.83.0
>Qt Version: 5.15.2
>Kernel Version: 5.12.13-300.fc34.x86_64 (64-bit)
>Graphics Platform: Wayland
>Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
>Memory: 15.5 GiB of RAM
>Graphics Processor: Mesa DRI Intel® HD Graphics 4600
>
> --
> Sincerely Jonathan Ryshpan 
>
> But what are all these mysteries to me,
>  2  Whose thoughts are full of indices and surds.
> X  +  7 X  +  53
> = 11 / 3.
> -- Lewis Carrol
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


System always "Resumes from hibernation" on startup

2021-07-01 Thread Jonathan Ryshpan
The system always tries to restore from hibernation on startup; this
causes about a 1-1/2 minute delay.  I see no reason for this, since the
system is halted by "(Start)->Shut Do..."  Here is an extract from the
system log with inserted comments.

Jun 30 12:19:38 amito dracut-initqueue[523]: inactive  
'/dev/fedora/windows' [400.00 GiB] inherit
Jun 30 12:19:38 amito dracut-initqueue[523]: inactive  
'/dev/fedora/root' [100.00 GiB] inherit
Jun 30 12:19:38 amito dracut-initqueue[523]: inactive  
'/dev/fedora/swap' [24.00 GiB] inherit
Jun 30 12:19:38 amito dracut-initqueue[523]: inactive  
'/dev/fedora/home' [<1.31 TiB] inherit
Jun 30 12:19:38 amito systemd[1]: Found device /dev/mapper/fedora-root.

Jun 30 12:19:38 amito systemd[1]: Reached target Initrd Root Device.
Jun 30 12:19:40 amito kernel: fbcon: Taking over console
Jun 30 12:19:40 amito kernel: Console: switching to colour frame buffer device 
240x75

Jun 30 12:21:08 amito dracut-initqueue[526]: WARNING: D-Bus notification 
failed: Transport endpoint is not connected
Jun 30 12:21:08 amito systemd[1]: Found device /dev/mapper/fedora-swap.
Jun 30 12:21:08 amito systemd[1]: Starting Resume from hibernation using device 
/dev/mapper/fedora-swap...
Jun 30 12:21:08 amito systemd-hibernate-resume[547]: Could not resume from 
'/dev/mapper/fedora-swap' (253:1).
Jun 30 12:21:08 amito systemd[1]: 
systemd-hibernate-resume@dev-mapper-fedora\x2dswap.service: Deactivated 
successfully.
Jun 30 12:21:08 amito systemd[1]: Finished Resume from hibernation using device 
/dev/mapper/fedora-swap.
Jun 30 12:21:08 amito kernel: PM: Image not found (code -22)
Jun 30 12:21:08 amito kernel: kauditd_printk_skb: 7 callbacks suppressed

System configuration"  
   Operating System: Fedora 34
   KDE Plasma Version: 5.22.2
   KDE Frameworks Version: 5.83.0
   Qt Version: 5.15.2
   Kernel Version: 5.12.13-300.fc34.x86_64 (64-bit)
   Graphics Platform: Wayland
   Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
   Memory: 15.5 GiB of RAM
   Graphics Processor: Mesa DRI Intel® HD Graphics 4600

-- 
Sincerely Jonathan Ryshpan 

But what are all these mysteries to me,
 2  Whose thoughts are full of indices and surds.
X  +  7 X  +  53
= 11 / 3.
-- Lewis Carrol
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: NM, wpa_supplicant flooding error log

2021-07-01 Thread George N. White III
On Thu, 1 Jul 2021 at 02:02, Jon LaBadie  wrote:

> Laptop running F34 with an "Intel Cannon Point-LP CNVi [Wireless-AC]"
> controller.
>
>
> Every 10 seconds I get this error message (/var/log/messages):
>
>wpa_supplicant[78893]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22
>
> A websearch shows this is not an uncommon problem though most
> see it every 1 second, not 10 seconds.  I've tried numerous
> suggested solutions that were all ineffective (reboot after
> changes).  These included:
>
> - downgrading wpa_supplicant (none available)
> - downgrading NM (restored current)
> - eliminating all NM interfaces except the active one
> - eliminated the ethernet (wired) NM interface
> - several .conf changes for NM and wpa_supplicant
>
> Still the messages keep coming (200K+).
>
> Any suggestions?
>

Have you seen ?
This indicates the messages are due to wpa_supplicant not properly handling
your wifi hardware, so you may want to check upstream.   This could
be an issue with the firmware version provided by Fedora.

My Fedora 33 system has wpa_supplicant messages in "the systemd(1)
journal as written by systemd-journald.service(8)."  so either Fedora 34 has
changed logging for wpa_supplicant or you have a local wpa_supplicant
version/configuration.

This sort of problem often appears across multiple linux distros, so it is
worth
checking for similar issues on other distros, in particular Ubuntu and
Arch.

-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: DNF not Installing all Updates?

2021-07-01 Thread Stephen Morris

On 29/6/21 07:37, old sixpack13 wrote:

On 28/6/21 10:18, Ed Greshko wrote:
I usually ignore the "nothing to do"
situation as well and just issue
the command again the next time I'm ready to put on updates again. It is
a bit disconcerting though when Discover reports there being, in my case
638MB of Fedora System Updates as opposed to application updates, right
from the first boot of F34 after a fresh install, and that calculation
of how many updates are available never changes irrespective of how many
updates are applied by dnf and how often. I've had F34 installed in the
vm for probably around 6 months, and Discover has never stopped
reporting 638MB of System Updates until I actually put them on.

regards,
Steve

what happens when you do in an terminal:
sudo flatpak update
and afterwards in your "software center" (discovery ?)
a refresh/new search for updates

???

I've seen similar about "~600 MB platform update" which stuck somehow on 
F34/F33 (?)
the above fixed it
I ran sudo flatpak update in the terminal and opened discover after the 
update finished and Discover said it had 129 updates to be applied.
I check dnf and it said it had 124 package updates and 4 installs, which 
I applied. After rebooting Discover still said it had 34 updates to put 
on, which are below.




regards,
Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Creating a user-level systemd unit - SOLVED

2021-07-01 Thread Patrick O'Callaghan
On Thu, 2021-07-01 at 08:53 +0800, Ed Greshko wrote:
> On 01/07/2021 05:56, Patrick O'Callaghan wrote:
> > Apologies for the noise and thanks to all who attempted to help.
> 
> Oh, that's OK.
> 
> Got me to start experimenting with writing user units and learning a
> bit about how they work.
> 
> So, some good came of the noise.  From my perspective anyway.  :-)

Ditto. I have some other uses for this.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure