Thursday, June 20, 2024

Re: Internal Server Error trying to add host

On Fri, Jun 14, 2024 at 01:51:54AM GMT, Starburst Services SysOp Team via Mirror-admin wrote:
> Can we post the info here, to add an additional host to our account?
>
> Still trying to add an additional host, still getting:
>
>
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and was unable
> to complete your request.
>
> Please contact the server administrator at webmaster@fedoraproject.org to
> inform them of the time this error occurred, and the actions you performed
> just before this error.
>
> More information about this error may be available in the server error log.
>
> ------------------------------------------------------------------------
> Apache Server at mirrormanager.fedoraproject.org Port 443

This was reported in https://github.com/fedora-infra/mirrormanager2/issues/351

Per the last comment there, can you try again now?

kevin

[fedora-arm] Re: Raspberry Pi 4 issues with Fedora Rawhide

On Thu, 20 Jun 2024 at 16:50, Frantisek Zatloukal <fzatlouk@redhat.com> wrote:
>
>
> Hey Peter,
>
> On Thu, Jun 20, 2024 at 5:41 PM Peter Robinson <pbrobinson@gmail.com> wrote:
>>
>> > * gsk: vulkan renderer breaks gtk4 apps on Raspberry Pi 4 and 400 [1]
>> > GSK now defaults to vulkan and it causes problems on RPi, I initially
>> > encountered crashing gnome-initial-setup (and later that all GTK4 apps are
>> > crashing upon startup). Thus I proposed it as a F41 Beta blocker. This
>> > crashing on app startup will be resolved in the next GTK release, the fix is
>> > already merged.
>> > However, there are still issues with GTK4 apps [2], all related to vulkan
>> > renderer [3] [4] [5]. It is not yet clear if the problems are bugs in GTK or
>> > mesa. In the end, if proven difficult to fix, we could always switch back to
>> > older renderer as suggested by Adam during F40 cycle [6].
>>
>> What is GSK? Was there an official Fedora change for the switch to Vulkan?
>
>
> That would be the GTK Scene Graph Kit (part of the rendering pipeline in GTK?) . It's an upstream change, so I am not sure if a change is needed (I am not saying it's not, just don't know). They've (GTK upstream) made a change from gl to ngl renderer in Fedora 40 [0] (there was an issue on RPI 4 caused by it that got resolved before the GA [2]), and the current devel version of GTK 4 in rawhide changed that once again from ngl to vulkan.

That should definitely be a change in Fedora.

> [0] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6809
> [1] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7153
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2269412
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
--
_______________________________________________
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] Re: Raspberry Pi 4 issues with Fedora Rawhide


Hey Peter,

On Thu, Jun 20, 2024 at 5:41 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> * gsk: vulkan renderer breaks gtk4 apps on Raspberry Pi 4 and 400 [1]
> GSK now defaults to vulkan and it causes problems on RPi, I initially
> encountered crashing gnome-initial-setup (and later that all GTK4 apps are
> crashing upon startup). Thus I proposed it as a F41 Beta blocker. This
> crashing on app startup will be resolved in the next GTK release, the fix is
> already merged.
> However, there are still issues with GTK4 apps [2], all related to vulkan
> renderer [3] [4] [5]. It is not yet clear if the problems are bugs in GTK or
> mesa. In the end, if proven difficult to fix, we could always switch back to
> older renderer as suggested by Adam during F40 cycle [6].

What is GSK? Was there an official Fedora change for the switch to Vulkan?

That would be the GTK Scene Graph Kit (part of the rendering pipeline in GTK?) . It's an upstream change, so I am not sure if a change is needed (I am not saying it's not, just don't know). They've (GTK upstream) made a change from gl to ngl renderer in Fedora 40 [0] (there was an issue on RPI 4 caused by it that got resolved before the GA [2]), and the current devel version of GTK 4 in rawhide changed that once again from ngl to vulkan.

[0] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6809 
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2269412

--

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat

[fedora-arm] Re: Raspberry Pi 4 issues with Fedora Rawhide

Hi Lukas,

Sorry for the delay in reply, it got lost in the mess of my inbox.

> I am writing this email to raise awareness well ahead of the F41 branching
> on August 6 about the bugs I found while running Fedora Rawhide on the RPi 4.
> I have proposed these bugs as blockers for the F41 release:
>
> * gnome-initial-setup: Choosing avatar results in SetIconFile call failed for
> unknown reason [0]
> I proposed this as F41 Final blocker, but this is fairly minor bug and I can
> imagine that we would waive it if not fixed and create a common issue.

TBH that doesn't look RPi specific, does it work if you set SELinux to
permissive? It seems like a perms/access problem to me.

> * gsk: vulkan renderer breaks gtk4 apps on Raspberry Pi 4 and 400 [1]
> GSK now defaults to vulkan and it causes problems on RPi, I initially
> encountered crashing gnome-initial-setup (and later that all GTK4 apps are
> crashing upon startup). Thus I proposed it as a F41 Beta blocker. This
> crashing on app startup will be resolved in the next GTK release, the fix is
> already merged.
> However, there are still issues with GTK4 apps [2], all related to vulkan
> renderer [3] [4] [5]. It is not yet clear if the problems are bugs in GTK or
> mesa. In the end, if proven difficult to fix, we could always switch back to
> older renderer as suggested by Adam during F40 cycle [6].

What is GSK? Was there an official Fedora change for the switch to Vulkan?

> * Raspberry Pi 4 won't wake up from suspend [7]
> Although we don't have a criterion for suspend, I proposed this as a blocker
> bug. I cannot login every time I keep Raspberry Pi idling for 15 minutes and
> I have to restart it, this could also lead to loss of data. This is something
> different compared to the x86_64 situation. On x86_64 we probably wouldn't
> block on suspend on some particular hardware configuration, but I think we
> should block here since we support only a handful of ARM boards.
> Also, suspend on Raspberry Pi OS is disabled, so I'm not sure if suspend on
> Raspberry Pi is something we even want in Fedora.

I am absolutely against blocking on suspend for RPi or any specific
platform, this is completely out of our control and it's not supported
even on downstream kernel forks, it's dependent on issues with closed
FW which is completely out of our control. There's reasons we don't
block on suspend on x86 so I am unsure why we'd explicitly decide to
torture arm maintainers with that.

Peter
--
_______________________________________________
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] Re: Questions to Fedora on Rock 5B

On Tue, 11 Jun 2024 at 19:43, Andreas Reschke <arm_ml@rirasoft.de> wrote:
>
> Hello
> 1. Audio
>
> on this side
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md
>
> is shows Headphone Jack Playback is enable with 6.4-rc1
> What does this mean?
>
> I didn't found any soundcard on my device
> root@rockpi5:~# inxi -A
> Audio:
> Message: No device data found.
> API: ALSA v: k6.10.0-0.rc2.20240607git8a92980606e3.28.fc41.aarch64
> status: kernel-api
> Server-1: PipeWire v: 1.1.82 status: active

Running the following gives me sound via a headset:

alsaucm -c rk3588-es8316 reset reload set _verb HiFi list _devices set
_enadev Headphones set _enadev Headset
aplay /usr/share/sounds/alsa/Front_Left.wav

Can you provide more details of your configuration? Desktop etc.

I suspect there's a ucm profile missing to do this automatically. I'll
add it to my (very long) todo list to look at some point.

> root@rockpi5:~#
>
> 2. GPU
> I know the GPU isn't complete at the moment, how to load the kernel
> driver panthor at boot time ?

This is working for me with the Fedora 6.10-rc4 build.
--
_______________________________________________
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, June 19, 2024

[fedora-arm] Re: Fedora 40 Minimal

Hi Tim,

> I tried using the arm-image-installer to create a bootable sd card for my rockpro 64 using the fedora 40 minimal image 40-1.14.
>
>
>
> It completed ok but did not boot, dumped me into a uboot environment. When I put the card in a different machine to look at the partitions the first one would not mount with an error of "doesn't seem to have a valid NTFS". So I created an valid file system with mkdosfs, mounted it and copied the appropriate efi files to it.
>
>
>
> Tried to boot again and got absolutely nothing. As if the uboot was not there. So I put the car back into the other machine and did a update-uboot with the proper uboot file.
>
>
>
> Tried to boot and got the same thing as the original attempt to boot. Put the card back into the other machine and the first partition would not mount again same issue with not a valid NTFS.
>
>
>
> It seems to me that the writing the uboot is stepping on the first partition.

We leave 8Mb on the the minimal image, the Rockpro64 image must have
grown above this, will need to take a look.

You could just put the firmware on the SPI flash on that device and
then it's out of the way.

The other way, a little bit more involved is to write the image with
--target=none then shrink the first partition a little, then use
update-uboot to write the FW out.

> I tried the workstation image and it did not have this problem.

Which is strange because the Workstation image has 1Mb, it could just
be writing it to the middle of the partition and by some chance
missing things like grub.

> Does it make any sense that when the arm-image-installer writes the uboot for the rockpro64 that it could be stepping on the first partition that it has previously written?

Yes, if the FW is too big it could do that.

Peter
--
_______________________________________________
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

Tuesday, June 18, 2024

[fedora-arm] Fedora 40 Minimal

I tried using the arm-image-installer to create a bootable sd card for my rockpro 64 using the fedora 40 minimal image 40-1.14.

 

It completed ok but did not boot, dumped me into a uboot  environment.  When I put the card in a different machine to look at the partitions the first one would not mount with an error of “doesn’t seem to have a valid NTFS”. So I created an valid file system with mkdosfs, mounted it and copied the appropriate efi files to it.

 

Tried to boot again and got absolutely nothing.  As if the uboot was not there.  So I put the car back into the other machine and did a update-uboot with the proper uboot file.

 

Tried to boot and got the same thing as the original attempt to boot.  Put the card back into the other machine and the first partition would not mount again same issue with not a valid NTFS.

 

It seems to me that the writing the uboot is stepping on the first partition.

 

I tried the workstation image and it did not have this problem.

 

Does it make any sense that when the arm-image-installer writes the uboot for the rockpro64 that it could be stepping on the first partition that it has previously written?

 

Tim Krantz