Meeting started at 2025-09-24 17:00:22 UTC

The Meeting name is 'fedora-server '

I'll post the agenda in 2-3 minutes.

As usual, let's wait a moment for everybody to show up.

!hello

Emmanuel Seyman (eseyman) - he / him / his

Hi, Peter Boy (ServerWG, Docs)

Welcome Emmanuel Seyman

Well, I think we should start. nirik is lurking as every Wednesday.

Anything to add / to remove ?

OK, lets go.

Maybe the httpd config change

I could manage to make the PRs. Was too busy with the SBC stuff. So probably unter Open Floor? I'll do the PRs on Saturday latest.

I could manage to make the PRs. Was too busy with the SBC stuff. So probably unter Open Floor? I'll do the PRs on Saturday latest ?

Sure

OK, lets go for now

Regarding the action, nothing new. See

Announcements

https://forge.fedoraproject.org/server

Since today we have a new forge:

Woot 🎉

Currently, it's only me a member. But every member of Server WG will autmatically added to the member group upon first login.

indeed

We should make some planing how to structure the place. My idea so far is, to separagte or docs into 2 repos, usrdocs and wgdocs.

The workflow of both is too different.

and a separate repro for Ansible support scripts.,

And maybe another for WG-proceedings, or alike, Mainly the tracking issues.

Oh, Isee, Welcome Emmanuel Seyman !

TBH, I have no idea how forgejo works. I will need to read some documentation

There is a good (default) Forgejo documentation on their project site. Fedora did a lot to adopt it to our requirements. Most of it was uploaded into the main project.

You can explore the other teams and their repos as they set them up (as long as they aren't closed off): https://forge.fedoraproject.org/explore/repos

We'll just need to look into other things like the antora docs builder, etc.

currently, their is not that much to see :-)

Fedora is a bit special, as fas as I followed the discussion.

I'm not expecting any major hurdles. It's not like we were doing anything magical with pagure.

Agreed

Well, how do we want to discuss?

Quite true

Mailing list, Matrix using threading, discussion?

We should definitely all get into the new forge site when we can. (I can't log into it from work for the time being.)

Migrating the git data will be interesting, only because I haven't done it before. Issues might have to be re-built at the new forge.

Given how many we are here, I would say mailing-list

Their are prepared steps for migration.

OK, let's try mailing list.

Anything else?

!Hello

Hi, mowest

Welcome mowest !!!!!!!

Tracking issue: !link https://pagure.io/fedora-server/issue/172

Discussion: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/AWJRNELVN7BW2VFQUTXZPAEYRZ7DUK4O/

The floor is open

This does look like it is getting some traction in Bugzilla. I'm still hoping for a positive change before release

I have already weighed in on this issue from my point of view. I don't think we should offer this image on our website unless we are willing to 1. Eliminate the issues that are causing issues with the install (for example if we eliminated the LVM and just installed to a root partition, a single partition would that work? or 2. Can get it to run well on SBC's that don't support UEFI booting, for example no one should try to use Fedora Server Edition on a RPi3 or below.

I think, there is a good chance to get i fixed. Neil already made a PR to cope with the firmware groth

Fedora is using u-boot for all images, that's kind of UEFI. So will not exclude any SBC because of lack or UEFI, but probably lack of OSS drivers.

That said, there's a strong link between SBCs homelabs in my mind. So I'm ok with targeting these with our homelab variant

And PI3 is not an issue regarding uefi, is is just too slow for the current expections.

A agree with the homelab bias-

Is there a way to simplify our SBC image to make it more "homelab" compatible? I would love to run Fedora Server on SBC's like the RPi4 and even the RPi3, but whereas Ubuntu Server seems to work fine on those SBC's Fedora is dog slow.

And we have a lot of homelab users.

I agree that we have a lot of homelab users, but we have some "enterprise" features in our build of Fedora Server that I don't see as necessary for the homelab.

Accordig to my explorations, there is no speed difference with headless varians to those distros.

There is some difference regarding GUI, because other distros accept binary propriarity blobs. We do not.

I found Ubuntu Server useable on the RPi3, not great but usable unlike Fedora Server. I run all my SBC's headless, actually all of my servers are headless.

I think, we should discuss the details, when we plan the homelab variant. For the moment we must decide the next move.

Regarding feature, The appeal of Fedora Server is that it makes features (security, stability, etc.) available for home labs as well.

If it can't be fixed before release, I say it gets removed from webpage, and not even built where it could be accidently downloaded and attempted to be installed by a new user.

I don't like the idea of having a non working image on our website or available for download.

Well, I mean that line of thought would eliminate all of the test builds, too. Heh.

i think it'll be fixed before release, but if i'm wrong the working group will have the option to not ship a broken image

We definitely want something built, we just need to make some smarter strategic decisions about what and how. The LVM/XFS thing being a huge one.

Proposal 1: !agreed: If the current problems are not fixed by the release date, no SBC version of the server should be released at all.

The performance thing may or may not be a matter of non-free firmware, too

Proposal 1: !agreed: If the current problems are not fixed by the release date, no SBC version of the Server should be released at all.

What about the proposal? ack from me

is it possible to do some A/B testing to see if this is true? As in, A and B are Fedora, but differ only in free vs non-free firmware?

+1 on Proposal

+1 from me

I don't know if Fedora will ship the non-free firmware even if we figured that part out.

cmurf: That would be interesting! But maybe a lot of work with Kiwi.

I'm fine with not shipping a release image (is Server release-blocking on SBC?), but we should definitely continue test composes.

i'm not suggesting new images, just some partition ninja stuff with someone who has hardware and expertise

Unless we just don't want to build one at all.

That's another proposal, how to proceed long term. (the next one)

!agreed: If the current problems are not fixed by the release date, no SBC version of the server should be released.

Zodbot, where are you?

Ah, withoujt colon.-

I do have a question. Is our layout of the partitions with XFS and LVM causing the issue, because I would be in favor of a simplified partition scheme for the SBC since I can't imagine why on a homelab SBC I would need to have the layout we use currently for Fedora Server x86.iso?

If we could simply switch to the partition and file system that is used in the other SBC images of Fedora that do work, I think that would be an easy fix.

It doesn't really make sense at all for SBC

seems to be that firmware gap was too small, I guess firmware for these boards is stuffed in a gap between the MBR (LBA 0) and the beginning of the 1st partition so the fix is to create a 16MiB gap instead of the default 1GiB gap

mowest: LVM works just fine with u-boot and SBC. But we can choose another filesystem for homelab, e.g. BTRFS Buit that is a separate discussion.

OK, next part.

I would like to receive SBC as a “real” alternative, especially for homelab. So with blocking status like the other server installation media. And we should try to coordinate this with the other editions.

Thanks cmurf clearly that is an issue that is over my head. I lack the knowledge of understanding SBC's and their unique hardware requirements. I appreciate your explanation. Thanks for that.

:Proposal 2: !agreed We will follow alternative 1 of the ticket 172.

I would like to keep SBC as a “real” alternative, especially for homelab. So with blocking status like the other server installation media. And we should try to coordinate this with the other editions.

And regarding the fix: the arm-image-installer is a matter of update. It is not a single shot as is the installation medium.

I don't see how making the Server on SBC release-blocking helps us

If anything it makes the overall release process worse

It helps us to prevent un-installable installation media.

The current decision it due to Workstation and KDE, which have the same issue, but their installation medium is blocking.

But release-blocking puts Server on SBC on the radar during the blocker review. It doesn't actually fix anything.

I don't know for sure the firmware gap issue will solve the failure to mount issue. I don't know details about how the image is created, if writing the firmware (inadvertently) overwrote part of the file system; and that resulted in the problem looking like it was LVM related. Just coincidence? (e.g. the LVM metadata might have been stepped on by firmware being written, and that prevented LVM from being activated, and hence the mount issue).

@cmurf: I guess, that the LVM issue is a follow-up of the size issue. The same arm-image-installer version works with older imagers (f39 f40) where is image was smaller.

But of course, the proof of the pudding .....

It makes for more pressure to fix things because the whole release, all variants, get delayed.

Right, but who's going to fix it? I mean, I know *I* can't. Not with my current knowledge.

But Folks discussion discipline! We have more delay as the Deutsche Bundesbahn.

Paul Maconi (Aggraxis): Neil already created a fix. We have to test it as soon as we have a built.

yeah the reason to make it release blocking is it's super important overall to the working group's strategy, mission, user base, therefore blocking is a necessity. But blocking is not a means by which things are more likely to get fixed, just by adding pressure.

OK, we still have: Proposal 2: !agreed WG will pursue alternative 1 of ticket #172.

ack from (surprise surprise :-) )

So this is "drop the image and possibly publish a note on our documentation on the download page"?

No, it is: We will propose the SBC Server image as release blocking. OK, alternative 1 is much more. So:

Proposal 2: !agreed WG proposes the Server SBC installation medium as release blocking. Details to be coordinated with other editions.

I'm unsure if I want to do this if it would affect all of Fedora Editions and their release.

Given that arm32 was blocking, it doesn't sound absurd

The earliest it could become blocking would be for 44, right?

mowest: Well, thats vice versa true as well. And i think, it is good for Fedora as a whole.

Paul Maconi (Aggraxis): yes.

I just don't feel that our SBC image is widely used enough to make it release blocking for all the editions. I'm going to go -1 from me.

+1 from me

Who decides this? QA? FESCO?

It's a good question. I don't know off hand if working groups can decide their own release blocking images, or if it is a system wide change proposal that fesco approves.

I don't know the exact procedure, either. We just have to try and to ask. I think Adams knows what to do.

I guess it's QA since they were the lead on the recent scope reduction

+1 to ask QA if they are willing to make our SBC image release-blocking

Emmanuel Seyman: what do we do it it is not QA bug FESCo?

I think we have to submit a change proposal

+1 to ask the relevant team if they are willing to make our SBC image release-blocking

Since this will be reviewed by FESCO, I'm fine with +1

They'll tell us if we're nuts.

To get to release blocking, one raises a bug in Bugzilla, and then files for a release blocking request on the apropriate page, which gets discussed at release blocker meetings of QA

Ok, so far we have +3,0,-1

I'm sorry, I have to leave

Yeah whether it's QA or FESCO telling us we're nuts, as long as there's another sanity check I'm fine.

Be back in 20 minutes if you're still around

https://qa.fedoraproject.org/blockerbugs/milestone/43/final/buglist

!hi

Mat H (theprogram)

MatH: yes, that is the way to decide it an existing bug qualifies as a release blocker. But it is to define a decision criteria-

it kinda makes sense there'd be a system wide change proposal because it affects other teams like infra and qa; but ultimately the working group's stake holders for that image need to step up and say you want it and are willing to be on the hook. Like it isn't a way to get extra resources it's a way to put yourselves on 24/7 on call during go-go no weeks. It adds work 🙂 not least of which is there's a long list of release criteria that gets attached to the release blocking images. So you know, standards.

You might want to "pretend" to have a release blocking image for maybe two releases and see how it goes before making it official. But sure ask QA about how to go about it, pros and cons.

cmurf: thanks for the info!

Well still +3,0,-1 anyone to change their mind?

!agreed WG proposes the Server SBC installation medium as release blocking. Details to be coordinated with other editions.

Hm Zodbot sleeping?

!agreed: WG proposes the Server SBC installation medium as release blocking. Details to be coordinated with other editions.

aggraxis gave a cookie to cmurf. They now have 6 cookies, 1 of which were obtained in the Fedora 42 release cycle

OK., agreed without zodbot :-)

We are out of time. Let's skip to

Anything here?

No, just thank you for running another weekly meeting and keeping us all on task.