Fedora Info

Friday, April 26, 2024

[389-users] Re: [Freeipa-users] Fedora 40: new warning in ipa-healthckeck

Cross-posting this on the 389-users list.

rob

Jochen Kellner via FreeIPA-users wrote:
>
> Hi,
>
> I've upgraded my freeipa server to Fedora 40 (the system was installed
> several releases ago). After the upgrade I get the following new warning
> from ipa-healthcheck:
>
> {
> "source": "ipahealthcheck.ds.backends",
> "check": "BackendsCheck",
> "result": "WARNING",
> "uuid": "875db8e3-029c-46f7-87e5-bf9a216d9637",
> "when": "20240426184431Z",
> "duration": "0.031642",
> "kw": {
> "key": "DSBLE0005",
> "items": [
> "nsslapd-dbcachesize",
> "nsslapd-db-logdirectory",
> "nsslapd-db-transaction-wait",
> "nsslapd-db-checkpoint-interval",
> "nsslapd-db-compactdb-interval",
> "nsslapd-db-compactdb-time",
> "nsslapd-db-transaction-batch-val",
> "nsslapd-db-transaction-batch-min-wait",
> "nsslapd-db-transaction-batch-max-wait",
> "nsslapd-db-logbuf-size",
> "nsslapd-db-page-size",
> "nsslapd-db-locks",
> "nsslapd-db-locks-monitoring-enabled",
> "nsslapd-db-locks-monitoring-threshold",
> "nsslapd-db-locks-monitoring-pause",
> "nsslapd-db-private-import-mem",
> "nsslapd-db-deadlock-policy"
> ],
> "msg": "Found configuration attributes that are not applicable for the configured backend type."
> }
> },
>
> According to
> https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html the
> bdb backend is deprecated. The system was installed with
> 389-ds-base < 1.4.4.9-1.fc33.x86_64 (I see the upgrade to that version
> in /var/log/dnf.rpm.log*. Since 3.0 new installations should use LMBD as
> the backend. Is that true for new installations?
>
> What is the desired action that I should take?
>
> I can remove the options from the dirsrv configuration. Should I?
>
> Shall I switch to lmdb manually? Or is that something that
> ipa-server-upgrade should be doing?
>
> Otherwise I can suppress the message in ipa-healthcheck for now. But I
> guess I should fix my installation before the deprecated support really
> gets dropped... Is deploying a new replica and decommisioning the old
> server we the preferred action?
>
> Jochen
>
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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, report it: https://pagure.io/fedora-infrastructure/new_issue

Thursday, April 25, 2024

[fedora-arm] Issues with RPi4 and newer kernels

I have a couple of Raspberry Pi 4 systems running Fedora 39 (as headless
servers), but I'm now hitting kernel update issues with both of them.
I've opened RHBZs on both but haven't gotten any response (they're niche
issues on a somewhat niche platform, so probably not much attention). I
was wondering if anybody here might have any suggestions for working on
getting these fixed.

One issue started with kernel 6.7 on one Pi - about 30-60 seconds after
boot, it crashes back to a uboot screen (had to hook up a monitor to see
it). I have netconsole set up but it doesn't show anything. This Pi
has a GPS HAT set up with PPS for a time source... I suspect it may be
related to that? The boot-to-crash delay is probably around the time
that it takes for the GPS/PPS to start up after boot. Kernel 6.6.13
still works fine.

https://bugzilla.redhat.com/show_bug.cgi?id=2264560

The other issue started with kernel 6.8 on another Pi - this one loses
the ability to connect to a WPA3-PSK wifi network. It can still connect
to a WPA2-PSK network, and kernel 6.7 can connect to WPA3-PSK. I have
other (x86_64) Fedora systems that can connect to the WPA3-PSK network
with kernel 6.8.

https://bugzilla.redhat.com/show_bug.cgi?id=2275835
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@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/arm@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Wednesday, April 24, 2024

[fedora-arm] Re: Lenovo X13s Firmware Load Issues on Kernel 6.8.7-300

Thanks Dennis,

I created the file with the following contents

install_items+=" /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcvss8280.mbn "

The last one is the video firmware described here (https://github.com/jhovold/linux/wiki/X13s#userspace-dependencies) which I manually added from the windows cabs. Not sure if this is needed for mainline kernel or just for the WIP branches but included just incase.

I think I could have included the firmware in compressed xz form but extracted it (unxz) as was unsure exactly how compressed firmware is handled. And then ran dracut --force to regenerate.

USB devices were partially working without the firmware, but as I wasn't booting from USB device I don't know if they were being reset during boot.

Thanks again for your help. Battery level is back working (and so is external monitor).

Andrew Spooner

From: Dennis Gilmore <dennis@ausil.us>
Sent: 23 April 2024 20:29
To: Andrew Spooner <spoonerandrew@hotmail.com>
Cc: arm@lists.fedoraproject.org <arm@lists.fedoraproject.org>
Subject: Re: [fedora-arm] Lenovo X13s Firmware Load Issues on Kernel 6.8.7-300

The move from dracut 059 to 060 led to some additional modules being
in the initrd. A workaround is to add a dracut config snippet that
includes the firmware in the initrd. after putting the file in
/etc/dracut.conf.d/ you will need to rebuild the initrd. ideally the
driver should try and reload the firmware once the root filesystem
becomes available. a side effect of the modules being included in the
initrd is that USB booting should work without the need blacklist
qcom_q6v5_pas as it is what has been included and works here. What is
not clear to me currently is if usb would work correctly without the
firmware.

Dennis

On Tue, Apr 23, 2024 at 11:28 AM Andrew Spooner
<spoonerandrew@hotmail.com> wrote:
>
> Hi all,
>
> I have been using Fedora 40 Beta on my Lenovo X13s (followed instructions on https://fedoraproject.org/wiki/Thinkpad_X13s, thanks for those, very helpful).
>
> However, last couple of kernel updates have brought regressions which I think are due to failing to load firmware.
>
> dmesg has lines like : -
>
> [ 2.596550] remoteproc remoteproc0: Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn failed with error -2
> [ 2.606506] remoteproc remoteproc1: Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn failed with error -2
>
> This has the impact that the power monitor doesn't seem to be able to pull battery status (pd-mapper is installed and running)
>
> Rebooting and selecting kernel 6.8.4-300.fc40.aarch64 and this issue disappears. Is this happening to any other X13s owner? Any help a debugging the issue/resolving it without downgrading kernel would be appreciated.
>
> Thanks
>
> Andrew Spooner
> --
> _______________________________________________
> arm mailing list -- arm@lists.fedoraproject.org
> To unsubscribe send an email to arm-leave@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/arm@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora 41 Rawhide 20240424.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event
for Fedora 41 Rawhide 20240424.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/41

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240424.n.0_Security_Lab

Thank you for testing!
--
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
_______________________________________________
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave@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/test-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Tuesday, April 23, 2024

[fedora-arm] Re: Lenovo X13s Firmware Load Issues on Kernel 6.8.7-300

Hello, you may want to ask also on IRC, OFTC server, #aarch64-laptops channel
--
_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@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/arm@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Lenovo X13s Firmware Load Issues on Kernel 6.8.7-300

Hi all,

I have been using Fedora 40 Beta on my Lenovo X13s (followed instructions on https://fedoraproject.org/wiki/Thinkpad_X13s, thanks for those, very helpful).

However, last couple of kernel updates have brought regressions which I think are due to failing to load firmware.

dmesg has lines like : -

[ 2.596550] remoteproc remoteproc0: Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn failed with error -2
[ 2.606506] remoteproc remoteproc1: Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn failed with error -2

This has the impact that the power monitor doesn't seem to be able to pull battery status (pd-mapper is installed and running)

Rebooting and selecting kernel 6.8.4-300.fc40.aarch64 and this issue disappears. Is this happening to any other X13s owner? Any help a debugging the issue/resolving it without downgrading kernel would be appreciated.

Thanks

Andrew Spooner
--
_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@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/arm@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue