Re: Microphone trouble
On 06/11/2020 11:36 PM, Samuel Sieb wrote: This is the internal laptop mic or the headset mic. Either way, all the following suggestion about recording it locally for a test and checking the levels is also good. This is the internal one. The headset one only worked if one jack was plugged into the right place, the other one wasn't plugged in and the jack connecting the headset to the Y connector wasn't plugged completely in. ___ 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
Re: Microphone trouble
On 6/11/20 10:17 PM, Joe Zeff wrote: On 06/11/2020 10:15 PM, Tim via users wrote: On Thu, 2020-06-11 at 21:25 -0600, Joe Zeff wrote: However, I'm told that there's so much static from my mic that the host mutes me before I can even say one, single word. This is the internal laptop mic or the headset mic. Either way, all the following suggestion about recording it locally for a test and checking the levels is also good. Try recording yourself to a file (e.g. use Audacity). Does it sound clear? If not, check your mike gain isn't wound up excessively high, wiggle leads and connectors, see if you can find a fault with your mic that you can make come and go. That right there may be the problem, cranking it up too high. I don't know about xfce, but in the Gnome sound control panel, there's an indicator showing the microphone level. If not, then audacity works maybe even better. It has a live indicator as well. If it's hitting the top, then the level is too high. And you can immediate record and playback testing. I know you said you're not in a position to buy a new mic, but it might be worth buying a $2 cheapy as an experiment. You don't have to use a headset, you can use separate mikes and headphones. It's not that I can't afford to buy another mic, it's the principle of the thing. I've had lots and lots of people suggest that I throw money at a problem, but in my 70 years, I've only once had somebody offer to throw their own money at a hardware problem. And, I don't really need a headset, my laptop's speakers work Just Fine. A headset works way better. You avoid echo and feedback issues and usually a headset microphone will have better sound than the built-in one. ___ 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
Re: DMESG Output Indicating Potential CPU Errors?
On 6/11/20 8:46 PM, Gordon Messmer wrote: On 6/11/20 3:09 PM, Patrick O'Callaghan wrote: It relates to competition in the sense that keeping host and guest to disjoint sets of cores avoids them competing for the same cores and hence contaminating the respective caches. That's all I mean. Don't read too much into it. Clearly the whole set is still being scheduled by the host system. Oh, now I see what you're getting at. If I'm wrong, I hope someone chimes in to correct me: Setting the CPU affinity of a process in Linux (which is what we're talking about) will cause the scheduler to always schedule the process on those CPUs, but it doesn't prevent the kernel or any other process from using those CPUs. That is, it doesn't reserve those CPUs for the exclusive use of the process that you're setting the affinity for. So, it's not minimizing competition in the way that you think it is, if I understand what you're getting at. You can also specify that certain cores are dedicated to certain processes and the kernel won't schedule anything else on them. ___ 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
Re: Microphone trouble
On 06/11/2020 10:15 PM, Tim via users wrote: On Thu, 2020-06-11 at 21:25 -0600, Joe Zeff wrote: However, I'm told that there's so much static from my mic that the host mutes me before I can even say one, single word. Try recording yourself to a file (e.g. use Audacity). Does it sound clear? If not, check your mike gain isn't wound up excessively high, wiggle leads and connectors, see if you can find a fault with your mic that you can make come and go. That right there may be the problem, cranking it up too high. If your recordings sound clear, then you may be experiencing a transmission issue over the internet. What people call "static" is wrong in the first place, and misleading in that they call all sorts of different things by the same name. That won't be it because my sister and I share a house and her voice comes through fine. I know you said you're not in a position to buy a new mic, but it might be worth buying a $2 cheapy as an experiment. You don't have to use a headset, you can use separate mikes and headphones. It's not that I can't afford to buy another mic, it's the principle of the thing. I've had lots and lots of people suggest that I throw money at a problem, but in my 70 years, I've only once had somebody offer to throw their own money at a hardware problem. And, I don't really need a headset, my laptop's speakers work Just Fine. ___ 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
Re: Microphone trouble
On Thu, 2020-06-11 at 21:25 -0600, Joe Zeff wrote: > However, I'm told that there's so much static from my mic that the > host mutes me before I can even say one, single word. Try recording yourself to a file (e.g. use Audacity). Does it sound clear? If not, check your mike gain isn't wound up excessively high, wiggle leads and connectors, see if you can find a fault with your mic that you can make come and go. If there's a fault with the connectors on the computer, that's harder to deal with, though often it's just a grotty connection that will clear up if you rotate the jack in the socket a little bit. If your recordings sound clear, then you may be experiencing a transmission issue over the internet. What people call "static" is wrong in the first place, and misleading in that they call all sorts of different things by the same name. If you're experiencing packet loss, you can get crackles and pops. And some codecs are garbage (a friend's mobile phone garbles the first syllable of almost every word he says). I know you said you're not in a position to buy a new mic, but it might be worth buying a $2 cheapy as an experiment. You don't have to use a headset, you can use separate mikes and headphones. -- uname -rsvp Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 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
Re: DMESG Output Indicating Potential CPU Errors?
On 6/11/20 3:09 PM, Patrick O'Callaghan wrote: It relates to competition in the sense that keeping host and guest to disjoint sets of cores avoids them competing for the same cores and hence contaminating the respective caches. That's all I mean. Don't read too much into it. Clearly the whole set is still being scheduled by the host system. Oh, now I see what you're getting at. If I'm wrong, I hope someone chimes in to correct me: Setting the CPU affinity of a process in Linux (which is what we're talking about) will cause the scheduler to always schedule the process on those CPUs, but it doesn't prevent the kernel or any other process from using those CPUs. That is, it doesn't reserve those CPUs for the exclusive use of the process that you're setting the affinity for. So, it's not minimizing competition in the way that you think it is, if I understand what you're getting at. ___ 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
Microphone trouble
My laptop is running F 31 and Xfce, fully updated. I'm trying to use Zoom to participate in meetings of a club I belong to but am having trouble with the microphone. If I use a headset and mic, I can usually hear OK, but nobody can understand what I'm saying. If I use the internal speakers and mic, the sound is sometimes OK, sometimes not. However, I'm told that there's so much static from my mic that the host mutes me before I can even say one, single word. Does anybody have an idea as to how to correct this without throwing money at it? Buying a new mic right now is out of the question, especially as I can't try it before I buy it. ___ 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
Re: Btrfs out of space - but plenty of space is available
After I wrote the question here, I realized what that I didn't google for the condition well enough Long story short, turns out sometimes btrfs reserves the space but doesn't use it -- in this case, a good 40+% of the drive :( Anyway, after a "btrfs balance" I think it's actually resolved. # btrfs fi us / Overall: Device size: 476.94GiB Device allocated: 279.98GiB (before the rebalance, "allocated" was also ~476GiB) ~cheers On 6/11/20 16:38, Konstantin Svist wrote: > Looks like I'm having a problem with my btrfs partition, it thinks > it's out of space. > Thing is, the drive is 500G and usage according to df and btrfs df is > ~250G > I removed a couple of snapshots as a workaround but hit the problem > again pretty quickly.. > I also ran fstrim & btrfs check --clear-space-cache (both v1 and v2) > and still no luck. > > Is there some limitation on number of files? I'm not doing anything > crazy there, just haven't checked yet ___ 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
Re: DMESG Output Indicating Potential CPU Errors?
On Thu, Jun 11, 2020 at 5:10 PM Patrick O'Callaghan wrote: > > On Wed, 2020-06-10 at 16:14 -0700, Gordon Messmer wrote: > > On 6/10/20 9:36 AM, Patrick O'Callaghan wrote: > > > > On 6/10/20 2:56 AM, Patrick O'Callaghan wrote: > > > > > In KVM/QEMU you can also pin specific cores to your VM to prevent > > > > > competition between the host and guest (mainly by avoiding cache > > > > > pollution as I understand it). > > > https://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-4-our-first.html > > > > > > (search for vcpupin partway down the page). This doesn't relate to NUMA > > > systems but to cache efficiency (also mentioned in your second > > > reference), though it may be a matter of terminology. Perhaps I should > > > have said "avoid" or "mitigate" rather than "prevent". > > > > I don't see anything there that suggests that CPU affinity is related to > > competition between the host and the guest. > > It relates to competition in the sense that keeping host and guest to > disjoint sets of cores avoids them competing for the same cores and > hence contaminating the respective caches. That's all I mean. Don't > read too much into it. Clearly the whole set is still being scheduled > by the host system. > > poc The original poster said that they gave the vm 8 cores, how many cores does the underlying host have (cores and hyperthreads). If the underlying host system only has 8 cores/threads then it is going to be pretty hard for the vm to ever get the 8 it needs at one time that it needs to be allowed to run. ___ 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
Re: Btrfs out of space - but plenty of space is available
This happened to me before. It's something similar to running out of inodes. Just do some googling and you should find the solution (unfortunately I don't recall it). On Thu, Jun 11, 2020 at 7:38 PM Konstantin Svist wrote: > Looks like I'm having a problem with my btrfs partition, it thinks it's > out of space. > Thing is, the drive is 500G and usage according to df and btrfs df is ~250G > I removed a couple of snapshots as a workaround but hit the problem again > pretty quickly.. > I also ran fstrim & btrfs check --clear-space-cache (both v1 and v2) and > still no luck. > > Is there some limitation on number of files? I'm not doing anything crazy > there, just haven't checked yet > ___ > 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 > -- *Those who don't understand recursion are doomed to repeat it* ___ 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
Re: Btrfs out of space - but plenty of space is available
On Thu, Jun 11, 2020 at 6:38 PM Konstantin Svist wrote: > Looks like I'm having a problem with my btrfs partition, it thinks it's > out of space. > Thing is, the drive is 500G and usage according to df and btrfs df is ~250G > I removed a couple of snapshots as a workaround but hit the problem again > pretty quickly.. > I also ran fstrim & btrfs check --clear-space-cache (both v1 and v2) and > still no luck. > > Is there some limitation on number of files? I'm not doing anything crazy > there, just haven't checked yet > This may be over simplistic, but I know btrfs needs free space because it's a COW (Copy On Write) file system, but 250GB seems excessive. Thanks, Richard ___ 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
Btrfs out of space - but plenty of space is available
Looks like I'm having a problem with my btrfs partition, it thinks it's out of space. Thing is, the drive is 500G and usage according to df and btrfs df is ~250G I removed a couple of snapshots as a workaround but hit the problem again pretty quickly.. I also ran fstrim & btrfs check --clear-space-cache (both v1 and v2) and still no luck. Is there some limitation on number of files? I'm not doing anything crazy there, just haven't checked yet ___ 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
[389-users] Re: [EXTERNAL] Re: Re: Re: Re: new server setup hanging
> On 12 Jun 2020, at 03:12, Crocker, Deborah wrote: > > What is it about this newer version compared to the old where this is > happening. Is it that our setup is not quite the same? We try to bring all > settings forward (except now it is auto-tuning cache) but it is possible we > missed something. It's hard to tell. Unindexed searches like this will always hurt performance. Unindexed searches have a tendancy to blow your cache out through evicts/includes. You should check also your db monitor to see if there are many cache evictions. That would tell you that autotuning is too low. We had to develop the cache auto-tune to work with FreeIPA in mind, and so by default it uses 10% of the system ram (25% as of 1.4.4 I think ). FreeIPA comes with a lot of other daemons like dogtag and co, and they are are memory hungry, so DS has to "share the playground" with them. There were also issues with glibc fragmenting our address space, and that caused us to "appear" to leak (We have since improved this situation of course). When autotuning was added, DS would ship with out of the box, I think 100MB of entry cache only, and some people went to production with this. Auto tuning isn't designed to be perfect, it's designed to be "better than before". And yes we'll keep improving that, but sometimes you need to tweak it to use more of the resources you have for your workload. As yet, I haven't thought of a good way to make it so that a pure 389-ds instance gets more memory, but we tune for less in freeipa to share You could find that changing it to 25% or 40% will improve your situation, especially if you are seeing lots of inclusions and evictions. https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/performance_tuning_guide/memoryusage#DB_and_entry_cache_RAM_usage And again, you *really really* should index all the attributes in that query, because any query that is "notes=F|A|U" is going to be bad, and you should configure SSSD to "play nice" ie ignore_group_members=true and enumerate=false to reduce load on your directory servervs, but also to improve your client login times (it used to take 5 minutes for me to sudo at my old workplace until I set ignore_group_members=true). Hope that helps, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 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
Re: DMESG Output Indicating Potential CPU Errors?
On Wed, 2020-06-10 at 16:14 -0700, Gordon Messmer wrote: > On 6/10/20 9:36 AM, Patrick O'Callaghan wrote: > > > On 6/10/20 2:56 AM, Patrick O'Callaghan wrote: > > > > In KVM/QEMU you can also pin specific cores to your VM to prevent > > > > competition between the host and guest (mainly by avoiding cache > > > > pollution as I understand it). > > https://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-4-our-first.html > > > > (search for vcpupin partway down the page). This doesn't relate to NUMA > > systems but to cache efficiency (also mentioned in your second > > reference), though it may be a matter of terminology. Perhaps I should > > have said "avoid" or "mitigate" rather than "prevent". > > I don't see anything there that suggests that CPU affinity is related to > competition between the host and the guest. It relates to competition in the sense that keeping host and guest to disjoint sets of cores avoids them competing for the same cores and hence contaminating the respective caches. That's all I mean. Don't read too much into it. Clearly the whole set is still being scheduled by the host system. 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
Re: DNF Upgrade of F31 to F32 did not Update Grub
Tue, 9 Jun 2020 21:18:12 +1000 Stephen Morris : > Hi, > After eventually getting 'dnf system-upgrade download > --releasever=32' to download and reboot the system, when the upgrade > had finished the system booted into sddm. When I selected KDE to > start into all it did was display a black screen. If I selected > Gnome, that did exactly the same thing. To try to work around this I > booted into recovery mode to see if I could identify why this was > happening. Looking at /boot I found that an F32 kernel had been > installed, and when I looked at /boot/efi/EFI/fedora/grub.cfg I found > that there was no entry for the F32 kernel. To circumvent this I > issued the command grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg, > and rebooted via the F32 kernel entry, which then enabled KDE and > Gnome to both start successfully. Has anyone else seen the issue of > the F32 upgrade not updating grub? Mine went fine on several machines, You should have it logged into: dnf history dnf history info [thalatestnumber] -- Łukasz Posadowski ___ 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
Re: keeping debuginfo in sync?
On Thu, 11 Jun 2020 13:57:46 -0600 Jerry James wrote: > Edit /etc/dnf/plugins/debuginfo-install.conf and set "autoupdate=1". > Then dnf will check for updates automatically. That looks like it. Thanks! ___ 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
Re: What is backup_vg-backup? Can it be so big?
On 6/11/20 11:34 AM, Beartooth wrote: Yesterday, I Beartooth wrote: The whole PC is now a backup; so I'd have no hesitation to DBAN it, install F32, and recopy data from my present #1 machine. I did think it seemed to have surprisingly little storage when I did that df -h; but if I understand better now, that 1.7T is real -- and, I hope, available for other uses. Is that so? Maybe I don't need to wipe it? Lish me wuck. My old DBAN medium failed in five seconds flat on interactive, and failed again in five more on autonuke. So I burned a medium for F32 netinstall, and booted from that. There was no need to wipe it before anyway. As usual, I missed some boneheaded thing, and couldn't get Anaconda to accept any manual partitioning I tried; so I eventually just let it go automatic. It finished all right, and I'm adding apps. Check how it did the partitioning. I have no idea what it will do when there are two drives. Custom or blivet partitioning would have been much better for your case. ___ 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
Re: keeping debuginfo in sync?
On Thu, Jun 11, 2020 at 1:54 PM Tom Horsley wrote: > Is there a trivial way to insure debuginfo files I have installed > stay in sync with the libraries when they get updated? > > I manually updated all my debuginfo packages, then found > I also needed to update debugsource packages. Edit /etc/dnf/plugins/debuginfo-install.conf and set "autoupdate=1". Then dnf will check for updates automatically. -- Jerry James http://www.jamezone.org/ ___ 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
keeping debuginfo in sync?
Is there a trivial way to insure debuginfo files I have installed stay in sync with the libraries when they get updated? I manually updated all my debuginfo packages, then found I also needed to update debugsource packages. ___ 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
Re: What is backup_vg-backup? Can it be so big?
Yesterday, I Beartooth wrote: >> The whole PC is now a backup; so I'd have no hesitation to DBAN it, >> install F32, and recopy data from my >> present #1 machine. I did think it seemed to have surprisingly little >> storage when I did that df -h; but if I understand better now, that >> 1.7T is real -- and, I hope, available for other uses. Is that so? >> Maybe I don't need to wipe it? Lish me wuck. My old DBAN medium failed in five seconds flat on interactive, and failed again in five more on autonuke. So I burned a medium for F32 netinstall, and booted from that. As usual, I missed some boneheaded thing, and couldn't get Anaconda to accept any manual partitioning I tried; so I eventually just let it go automatic. It finished all right, and I'm adding apps. Beforehand, last night and this morning, I had copied my whole home directory to a thumb stick. Then this morning I merged it into the home directory of my #1 machine, which I'm using now. And I'm in process of merging it into #3. When that's done, I'll copy it back, knowing it works. Many, many thanks to all hands, and especially to Samuel Sieb, for all the help! -- Beartooth Staffwright, Not Quite Clueless Power User Remember I know little (precious little!) of where up is. ___ 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
[389-users] Re: [EXTERNAL] Re: Re: Re: Re: new server setup hanging
What is it about this newer version compared to the old where this is happening. Is it that our setup is not quite the same? We try to bring all settings forward (except now it is auto-tuning cache) but it is possible we missed something. Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.croc...@ua.edu -Original Message- From: William Brown Sent: Wednesday, June 10, 2020 6:56 PM To: 389-users@lists.fedoraproject.org Subject: [EXTERNAL] [389-users] Re: Re: Re: Re: new server setup hanging > > We have a number of linux hosts authenticating to ldap. Some of them > using SSSD had "enumerate=true", Yeah, you need to disable enumerate=true, because SSSD will do paged searches and that will get around some search limits that normally would block that. As well, you probably should look at turning on "ignore_group_members=true", because if you don't have that set, then SSSD will enumerate your whole directory too. > which means they run a search for everything every five minutes. Just one of > those will tie up the host. The search is: > filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(uaNetgroupLinuxGid=*))" > only uaNetgroupLinuxGID is unindexed. Again, this causes no problem on our > existing setup. > ... > > Thread 49 (Thread 0x7fce91cb8700 (LWP 2176)): > #0 0x7fcf0b3929ff in comp_cmp (s1p=, > s2p=s2p@entry=0x55955e6fa140 "uaUDCid") at > ldap/servers/slapd/attr.c:88 > #1 0x7fcf0b392bc9 in slapi_attr_type_cmp > (a1=a1@entry=0x55945a2b7b90 "uaee121Shell", a2=0x55955e6fa140 > "uaUDCid", opt=opt@entry=2) at ldap/servers/slapd/attr.c:122 > #2 0x7fcf0b3944ff in attrlist_find_ex (a=, > type=type@entry=0x55945a2b7b90 "uaee121Shell", > type_name_disposition=type_name_disposition@entry=0x0, > actual_type_name=actual_type_name@entry=0x0, > hint=hint@entry=0x7fce91cb2488) at ldap/servers/slapd/attrlist.c:176 > #3 0x7fcf0b3b7211 in test_presence_filter (pb=pb@entry=0x0, > e=e@entry=0x55955e6ee300, type=0x55945a2b7b90 "uaee121Shell", > verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb25c0) at > ldap/servers/slapd/filterentry.c:355 > #4 0x7fcf0b42997e in vattr_test_filter (pb=pb@entry=0x0, > e=e@entry=0x55955e6ee300, f=f@entry=0x55947509ab80, > filter_type=FILTER_TYPE_PRES, type=) at > ldap/servers/slapd/vattr.c:753 > #5 0x7fcf0b3b6ec4 in slapi_vattr_filter_test_ext_internal > (pb=pb@entry=0x0, e=0x55955e6ee300, f=0x55947509ab80, > verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb2684) at > ldap/servers/slapd/filterentry.c:823 > #6 0x7fcf0b3b7ba6 in slapi_vattr_filter_test_ext > (pb=pb@entry=0x0, e=, f=, > verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0) at > ldap/servers/slapd/filterentry.c:771 > #7 0x7fcf0b3b7bf8 in slapi_vattr_filter_test (pb=pb@entry=0x0, > e=, f=, > verify_access=verify_access@entry=0) at > ldap/servers/slapd/filterentry.c:715 > #8 0x7fcf01599e02 in acl__resource_match_aci > (aclpb=aclpb@entry=0x559474f16000, aci=aci@entry=0x55947509a880, > skip_attrEval=skip_attrEval@entry=0, > a_matched=a_matched@entry=0x7fce91cb2bd0) at > ldap/servers/plugins/acl/acl.c:2422 > #9 0x7fcf0159b280 in acl__scan_for_acis (err=, > aclpb=0x559474f16000) at ldap/servers/plugins/acl/acl.c:1974 > #10 0x7fcf0159b280 in acl_access_allowed (pb=, > e=e@entry=0x55955e6ee300, attr=attr@entry=0x5595925e2ea0 "uid", > val=, access=access@entry=2) at > ldap/servers/plugins/acl/acl.c:568 > #11 0x7fcf015ae9f7 in acl_access_allowed_main (pb=, > e=0x55955e6ee300, attrs=, val=, > access=2, flags=, errbuf=0x0) at > ldap/servers/plugins/acl/aclplugin.c:371 > #12 0x7fcf0b3f0cbc in plugin_call_acl_plugin > (pb=pb@entry=0x559475874000, e=e@entry=0x55955e6ee300, > attrs=attrs@entry=0x7fce91cb2d10, val=val@entry=0x0, > access=access@entry=2, flags=flags@entry=0, errbuf=errbuf@entry=0x0) > at ldap/servers/slapd/plugin_acl.c:62 > #13 0x7fcf0b3b638d in test_filter_access > (pb=pb@entry=0x559475874000, e=e@entry=0x55955e6ee300, > attr_type=, attr_val=attr_val@entry=0x0) at > ldap/servers/slapd/filterentry.c:956 > #14 0x7fcf0b3b7082 in slapi_vattr_filter_test_ext_internal > (pb=pb@entry=0x559475874000, e=e@entry=0x55955e6ee300, > f=f@entry=0x559475f39000, verify_access=verify_access@entry=1, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb2de4) at > ldap/servers/slapd/filterentry.c:855 > #15 0x7fcf0b3b6d31 in vattr_test_filter_list_and (ftype=160, > access_check_done=0x7fce91cb2de4, only_check_access=0, > verify_access=1, flist=, e=0x55955e6ee300, > pb=0x559475874000) at
Re: DNF Update this morning -
On Thu, Jun 11, 2020 at 10:27:14AM -0600, Jerry James wrote: > > On Thu, Jun 11, 2020 at 10:08 AM Bob Goodwin wrote: > > No, not that I can see. > > > > [bobg@Workstation-1 ~]$ sudo rpm --rebuilddb > > [sudo] password for bobg:password > > [bobg@Workstation-1 ~]$ > > > > Strange, no indication of any action at all? > > Sorry, I wasn't paying attention. The error is on a dnf database, not > an rpm database. See if this sounds like your case: > > https://bugzilla.redhat.com/show_bug.cgi?id=1669824 > > The database dump and restore described there might help you. I'd be interested in seeing the output of: echo 'PRAGMA integrity_check;' | sudo sqlite3 /var/lib/dnf/history.sqlite It should just return: ok -- Jonathan Billings ___ 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
Re: No DNF updating again today -
On 6/11/20 4:50 AM, Bob Goodwin wrote: Error: SQLite error on "/var/lib/dnf/history.sqlite": Reading a row failed: database disk image is malformed Somehow your dnf history database is corrupted. The easy fix is to delete it or move it somewhere else. Otherwise you could try to find an sqlite database fixer. ___ 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
[389-users] Re: [EXTERNAL] Re: Re: Re: new server setup hanging
> > We have a number of linux hosts authenticating to ldap. Some of them using > SSSD had "enumerate=true", Yeah, you need to disable enumerate=true, because SSSD will do paged searches and that will get around some search limits that normally would block that. As well, you probably should look at turning on "ignore_group_members=true", because if you don't have that set, then SSSD will enumerate your whole directory too. > which means they run a search for everything every five minutes. Just one of > those will tie up the host. The search is: > filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(uaNetgroupLinuxGid=*))" > only uaNetgroupLinuxGID is unindexed. Again, this causes no problem on our > existing setup. > ... > > Thread 49 (Thread 0x7fce91cb8700 (LWP 2176)): > #0 0x7fcf0b3929ff in comp_cmp (s1p=, > s2p=s2p@entry=0x55955e6fa140 "uaUDCid") at ldap/servers/slapd/attr.c:88 > #1 0x7fcf0b392bc9 in slapi_attr_type_cmp (a1=a1@entry=0x55945a2b7b90 > "uaee121Shell", a2=0x55955e6fa140 "uaUDCid", opt=opt@entry=2) at > ldap/servers/slapd/attr.c:122 > #2 0x7fcf0b3944ff in attrlist_find_ex (a=, > type=type@entry=0x55945a2b7b90 "uaee121Shell", > type_name_disposition=type_name_disposition@entry=0x0, > actual_type_name=actual_type_name@entry=0x0, hint=hint@entry=0x7fce91cb2488) > at ldap/servers/slapd/attrlist.c:176 > #3 0x7fcf0b3b7211 in test_presence_filter (pb=pb@entry=0x0, > e=e@entry=0x55955e6ee300, type=0x55945a2b7b90 "uaee121Shell", > verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb25c0) at > ldap/servers/slapd/filterentry.c:355 > #4 0x7fcf0b42997e in vattr_test_filter (pb=pb@entry=0x0, > e=e@entry=0x55955e6ee300, f=f@entry=0x55947509ab80, > filter_type=FILTER_TYPE_PRES, type=) at > ldap/servers/slapd/vattr.c:753 > #5 0x7fcf0b3b6ec4 in slapi_vattr_filter_test_ext_internal > (pb=pb@entry=0x0, e=0x55955e6ee300, f=0x55947509ab80, > verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb2684) at > ldap/servers/slapd/filterentry.c:823 > #6 0x7fcf0b3b7ba6 in slapi_vattr_filter_test_ext (pb=pb@entry=0x0, > e=, f=, verify_access=verify_access@entry=0, > only_check_access=only_check_access@entry=0) at > ldap/servers/slapd/filterentry.c:771 > #7 0x7fcf0b3b7bf8 in slapi_vattr_filter_test (pb=pb@entry=0x0, > e=, f=, verify_access=verify_access@entry=0) at > ldap/servers/slapd/filterentry.c:715 > #8 0x7fcf01599e02 in acl__resource_match_aci > (aclpb=aclpb@entry=0x559474f16000, aci=aci@entry=0x55947509a880, > skip_attrEval=skip_attrEval@entry=0, > a_matched=a_matched@entry=0x7fce91cb2bd0) at > ldap/servers/plugins/acl/acl.c:2422 > #9 0x7fcf0159b280 in acl__scan_for_acis (err=, > aclpb=0x559474f16000) at ldap/servers/plugins/acl/acl.c:1974 > #10 0x7fcf0159b280 in acl_access_allowed (pb=, > e=e@entry=0x55955e6ee300, attr=attr@entry=0x5595925e2ea0 "uid", > val=, access=access@entry=2) at > ldap/servers/plugins/acl/acl.c:568 > #11 0x7fcf015ae9f7 in acl_access_allowed_main (pb=, > e=0x55955e6ee300, attrs=, val=, access=2, > flags=, errbuf=0x0) at ldap/servers/plugins/acl/aclplugin.c:371 > #12 0x7fcf0b3f0cbc in plugin_call_acl_plugin (pb=pb@entry=0x559475874000, > e=e@entry=0x55955e6ee300, attrs=attrs@entry=0x7fce91cb2d10, > val=val@entry=0x0, access=access@entry=2, flags=flags@entry=0, > errbuf=errbuf@entry=0x0) at ldap/servers/slapd/plugin_acl.c:62 > #13 0x7fcf0b3b638d in test_filter_access (pb=pb@entry=0x559475874000, > e=e@entry=0x55955e6ee300, attr_type=, > attr_val=attr_val@entry=0x0) at ldap/servers/slapd/filterentry.c:956 > #14 0x7fcf0b3b7082 in slapi_vattr_filter_test_ext_internal > (pb=pb@entry=0x559475874000, e=e@entry=0x55955e6ee300, > f=f@entry=0x559475f39000, verify_access=verify_access@entry=1, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb2de4) at > ldap/servers/slapd/filterentry.c:855 > #15 0x7fcf0b3b6d31 in vattr_test_filter_list_and (ftype=160, > access_check_done=0x7fce91cb2de4, only_check_access=0, verify_access=1, > flist=, e=0x55955e6ee300, pb=0x559475874000) at > ldap/servers/slapd/filterentry.c:980 > #16 0x7fcf0b3b6d31 in slapi_vattr_filter_test_ext_internal > (pb=pb@entry=0x559475874000, e=0x55955e6ee300, f=, > verify_access=verify_access@entry=1, > only_check_access=only_check_access@entry=0, > access_check_done=access_check_done@entry=0x7fce91cb2de4) at > ldap/servers/slapd/filterentry.c:885 > #17 0x7fcf0b3b7ba6 in slapi_vattr_filter_test_ext > (pb=pb@entry=0x559475874000, e=, f=, > verify_access=verify_access@entry=1, > only_check_access=only_check_access@entry=0) at > ldap/servers/slapd/filterentry.c:771 > #18 0x7fcf0b3b7bf8 in slapi_vattr_filter_test > (pb=pb@entry=0x559475874000, e=, f=, >
Re: How do I change the grub kernel boot parameters in F32 ?
On 2020-06-09 8:11 p.m.Stephen Morris wrote if in /etc/default/grub you have the entry GRUB_ENABLE_BLSCFG=true that inserts a line into the grub processes to use the new BLS standard,=20 in which case grub2-mkconfig and possibly grubby do nothing until that=20 entry is set to false. I have always use grub2-mkconfig because I have=20 never liked what grubby generated, and what BLS generates appears to be=20 the same as what grubby does, and I found that I had to set that entry=20 to false for grub2-mkconfig to continue to work. THANKS FOR THAT, Steve! I could not get grub2-mkconfig to actually change the grub.cfg file. Now I know why ( but not why such a dangerously misdescriptive switch would be hidden away in a default file). In the past I would just edit the damn file, but the new motherboard uses EFI, and such hands-on fixing might lead to an undesired result! Geoff ___ 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
Re: DNF Update this morning -
On Thu, Jun 11, 2020 at 10:08 AM Bob Goodwin wrote: > No, not that I can see. > > [bobg@Workstation-1 ~]$ sudo rpm --rebuilddb > [sudo] password for bobg:password > [bobg@Workstation-1 ~]$ > > Strange, no indication of any action at all? Sorry, I wasn't paying attention. The error is on a dnf database, not an rpm database. See if this sounds like your case: https://bugzilla.redhat.com/show_bug.cgi?id=1669824 The database dump and restore described there might help you. -- Jerry James http://www.jamezone.org/ ___ 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
Re: DNF Update this morning -
On 2020-06-11 10:46, Jerry James wrote: On Wed, Jun 10, 2020 at 4:44 AM Bob Goodwin wrote: DNF failed first try, I ran clean metadata and re-tried, got same result: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: SQLite error on "/var/lib/dnf/history.sqlite": Reading a row failed: database disk image is malformed I have no idea why this happening, have done nothing unusual? *Bob* Does running "sudo rpm --rebuilddb" get you back to a good state? ° No, not that I can see. [bobg@Workstation-1 ~]$ sudo rpm --rebuilddb [sudo] password for bobg:password [bobg@Workstation-1 ~]$ Strange, no indication of any action at all? -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD FEDORA-32/64bit LINUX XFCE Fastmail POP3 ___ 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
Re: How to install Wifi firmware so it's not overwritten?
On 6/10/20 7:54 AM, Richard Shaw wrote: So one thing I am wondering is what is the naming convention for these files? Could I just save it as board-2.bin and it work? Is there some sort of search hiearchy? That is up to the kernel driver. Most have only one specific filename they're looking for. ___ 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
Re: How to install Wifi firmware so it's not overwritten?
On Wed, Jun 10, 2020 at 11:27 AM George N. White III wrote: > On Wed, 10 Jun 2020 at 11:55, Richard Shaw wrote: > >> So the short version... >> >> The current linux firmware package doesn't work with the Wifi on the MS >> Surface GO, and the instructions to copy the downloaded board.bin and copy >> over firmware-4.bin were incorrect. It actually saw the Wifi adapter after >> I did that and it tried scanning for wireless networks but never got any >> further. >> >> Since the Killerwifi board.bin and the linux firmware board.bin were the >> exact same size (whereas the firmware files were orders of magnitude >> larger), I tried replacing board.bin instead and can report after rebooting >> that the Wifi now works. >> > > Did you try a newer file from the githhub link? Are there any license > restrictions on Killerwifi's board.bin that prevent you from sending the > link to the upstream URL I posted. > Not yet but I can. No clue on the license. Killerwifi provides a direct link to the board.bin file. Thanks, Richard ___ 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
No DNF updating again today -
It looks like my best hope is for FC33beta to arrive soon, need to check on that. Today I tried "clean all" still the same error message. The only thing that comes to mind is that I added SeaMonkey via dnf. I would not expect a problem due to that, but maybe? It is more reliable for opening a web page I visit often. Any suggestions how to fix appreciated, Bob --- Total 4.8 MB/s | 130 MB 00:27 Delta RPMs reduced 132.2 MB of updates to 129.9 MB (1.1% saved) Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: SQLite error on "/var/lib/dnf/history.sqlite": Reading a row failed: database disk image is malformed -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD FEDORA-32/64bit LINUX XFCE Fastmail POP3 ___ 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
Re: DMESG Output Indicating Potential CPU Errors?
On 6/10/20 9:36 AM, Patrick O'Callaghan wrote: On 6/10/20 2:56 AM, Patrick O'Callaghan wrote: In KVM/QEMU you can also pin specific cores to your VM to prevent competition between the host and guest (mainly by avoiding cache pollution as I understand it). https://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-4-our-first.html (search for vcpupin partway down the page). This doesn't relate to NUMA systems but to cache efficiency (also mentioned in your second reference), though it may be a matter of terminology. Perhaps I should have said "avoid" or "mitigate" rather than "prevent". I don't see anything there that suggests that CPU affinity is related to competition between the host and the guest. Setting CPU affinity correctly does improve cache use, and reduces the frequency of a guest running on a CPU with a different path to memory pages on NUMA systems, but scheduling the guest still requires that the CPUs are available for scheduling. As guests are assigned more cores (both when they're assigned all or nearly all of the system cores, or when multiple guests are assigned a number of cores collectively greater than the system total), you'll often see longer times between the guest being scheduled to run (that is, greater CPU steal time). I still don't know if that's the issue that is the subject of this thread, but that's my suspicion. ___ 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
Re: DNF Update this morning -
On Wed, Jun 10, 2020 at 4:44 AM Bob Goodwin wrote: > DNF failed first try, I ran clean metadata and re-tried, got same result: > > Running transaction check > Transaction check succeeded. > Running transaction test > Transaction test succeeded. > Running transaction > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: SQLite error on "/var/lib/dnf/history.sqlite": Reading a row > failed: database disk image is malformed > > I have no idea why this happening, have done nothing unusual? *Bob* Does running "sudo rpm --rebuilddb" get you back to a good state? -- Jerry James http://www.jamezone.org/ ___ 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
