J
j0rgeโข50d ago
@bsherman the reason I ask is I asked timothee about Fedora but on coreOS streams instead of releases but no one's working on that.
I was thinking of experimenting with running CoreOS kernels since they're less aggressive
B
bshermanโข50d ago
makes sense
J
j0rgeโข50d ago
so then I was like "maybe we don't need to rebuild the whole thing", I wonder if you can just use the coreOS kernel on fedora silverblue
B
bshermanโข50d ago
yeah, it's the same kernels, it's just that the release cadence is different, and they have a manifest for building their base images with specific pacakges pinned
and since all updates are rpm-ostree based, there's no "oops, I did
dnf update
and got a newer kernel"J
j0rgeโข50d ago
yeah, it appealed to me on a quality level
like the extra stuff they test for
B
bshermanโข50d ago
i mean, i very much think that the coreOS release model makes more sense long term... but... it would be hard to do since it's also built around the F39/F40 releases with manual delay on the only the specific pacakges deemed important for the CoreOS use case
hard for us i guess
or... not TOO hard... if we rewrote our "main" images to replace current kernel with whatever coreos stable uses
i dunno
J
j0rgeโข50d ago
yea that's why I was like "I wonder if there's just a copr"
B
bshermanโข50d ago
put this on the "ideas to have Benjamin test someday" list ๐
N
Noelโข50d ago
I don't think Bazzite would want to use the CoreOS kernel, but realistically I don't think it would affect things given Bazzite replaces the kernel anyway when it builds?
F
fiftydinarโข50d ago
I'm curious on what kind of testing they perform on CoreOS kernel that they don't on Fedora kernel
CoreOS kernel might have less regressions in some areas
J
j0rgeโข50d ago
nah this would be for bluefin
B
bshermanโข50d ago
there IS no CoreOS kernel
it's just an older Fedora kernel
we can definitely identify the current CoreOS kernel and swap to it in a build
mostly it should "just work"
N
Noelโข50d ago
The issue I could see for Bluefin is if it's an older kernel, there will be less hardware enablement out of the box I would think.
B
bshermanโข50d ago
the main problem I imagine is when Silverblue moves to F40, but CoreOS stable is still on F39... so the stable kernel would likely not swap into F40 cleanly
J
j0rgeโข50d ago
these are still pretty aggressive
B
bshermanโข50d ago
๐ how old do you think "old" is here:? ๐
J
j0rgeโข50d ago
6.7.7
two point releases behind F39 right now
N
Noelโข50d ago
does RPM fusion build it's stuff for CoreOS?
B
bshermanโข50d ago
it doesn't, because it's just Fedora
exactly, it's not old enough to worry about hardware enablement, it's just delayed to avoid crashing servers by giving more time for bugs to be caught in the wild
N
Noelโข50d ago
I guess I'm not trying to just nack this idea outright, I'm just trying to name some potential implications of the change.
J
j0rgeโข50d ago
I'm not talking about changing anything
F
fiftydinarโข50d ago
I had bugs with Intel ethernet driver, where it would need re-plug on every boot to work
Since CoreOS cares about internet stuff, It would be beneficial for me to use CoreOS kernel to avoid these issues
B
bshermanโข50d ago
i just want to make it really clear... the "CoreOS kernel" is literally, the exact same package which had been installed in Fedora XX few weeks back... i could downgrade my current Fedora 39 silverblue machine to this kernel if i wished without adding/swapping repos.
J
j0rgeโข50d ago
I'll experiment with it in my custom branch, but that'll be after you give me a lightweight fork thing
M
M2โข49d ago
ucore as a whole has my interest right now
J
j0rgeโข49d ago
heh
P
p5โข38d ago
Not too sure what the status of this thread is, but have been playing around with this a little.
It's fairly simple to track CoreOS' kernel in our images if those kernel versions are being built for all Fedora versions we are using.
For example, I have current CoreOS :stable kernel installing in FC39, but it's not being built for FC40 so we wouldn't be able to track it for F40. https://github.com/rsturla/eternal-main/pull/106/files
For example, I have current CoreOS :stable kernel installing in FC39, but it's not being built for FC40 so we wouldn't be able to track it for F40. https://github.com/rsturla/eternal-main/pull/106/files
B
bshermanโข38d ago
this thread is a placeholder
https://discord.com/channels/1072614816579063828/1222558445212012624/1222567447073128529
yep
I'm not sure if I also said this elsewhere or in voice chat, but tying ourselves to CoreOS kernel releases would also mean whatever we tie to that (say bluefin), that "product/image" needs to more or less tie its release to CoreOS's stable, so bluefin wouldn't promote to F40 until coreos:stable is on F40
P
p5โข38d ago
I guess that might be fine for the "gts" image (rather than tracking Fedora versions, track CoreOS releases), but not for people who want to use the latest releases
J
j0rgeโข38d ago
right
therein lies the rub
B
bshermanโข38d ago
so what's the target? people who just want machines to work? or people who want bleeding edge and to change their DE and care about all that junk
P
p5โข38d ago
In reality, what new kernel features are there that people would have asked for in the past year? I can't really think of any.
GTS is the default, and should be easy to track CoreOS. Latest could be for bleeding edge users, and don't restrict the kernel
B
bshermanโข38d ago
honestly, i'd like to table the whole CoreOS kernel discussion, maybe put in the planning backlog, but we have other stuff that needs doing, i have things which need to get added there
J
j0rgeโข38d ago
understood.
I'll go restart the Flatcar-Bluefin discussion and tag you.
j/k
B
bshermanโข38d ago
jerk ๐
J
j0rgeโข31d ago
So I'm having more thoughts about this
And I'm leaning towards waiting for this and not going ga with bluefin this cycle. If every kernel release is going to be going through all this then I'm not digging that
Maybe the play is coreos kernel with weekly releases for GTS to slow it down. We keep the client checking every day but only publish on a weekly cron and when we need to like the security fix. Thoughts?
B
bshermanโข31d ago
i like this...
and from a "fast kernel updates break some kmods" perspective... i think the worst kmod break we've seen was the jump to 6.8 for F38/F39 and how it broke v4l2loopback, but even that was at most a week before they got it fixed.
so a GTS with weekly updates, even without coreos kernel, already starts to fit this pattern
M
M2โข31d ago
Is v4l2loopback fixed?
B
bshermanโข31d ago
OMG, i need to check... i prepped the PR LOL
thank you @M2 for calling me out... i am wrong in my statement of how long
v4l2loopback
was (is still) not in our imagesJ
j0rgeโข31d ago
Coreos is in 6.7.7 still
So things like loopback would have more time to bake
B
bshermanโข31d ago
yup
J
j0rgeโข31d ago
And they're still supported, so it's not like we'd be moving to something wacky
Plus also other thing
If bluefinrora and ucore are more low touch then keeping bazzite up to date spreads out the workload
When a new kernel comes out we only have skew and jank in bazzite to fix instead of everything
M
M2โข31d ago
And Bazzite is on 6.7.7 right now. They just added an fsync-lts yesterday
J
j0rgeโข31d ago
Then later in Aurorafin we get the same kernel, it's just a month later or whatever
Right
Lol the quest for the Ubuntu sweet spot
I'll write this up on GitHub, I'm mostly shower thinking on the plane
Anyway I wanted to run this by people since I'll be hanging with a ton of people with opinions on this all week and asking for ideas
Don't worry I won't come back with crazy ideas
Like redoing the entire silver blue compose on top of coreos . ๐๐๐๐๐
M
M2โข31d ago
I've considered that.... But it has fedora server defaults instead of workstation
J
j0rgeโข31d ago
Also I haven't thought about builder use for this, which is pretty epic now since we added aurora
M
M2โข31d ago
I have an idea in bluefin to reduce builder use for our images
M
M2โข31d ago
GitHub
Split -dx and base Containerfiles and Workflows ยท Issue #1134 ยท ubl...
Currently our -dx images build the base image in the process of building them. With the reusable build workflow we can possible have -dx built directly from the just built base image.
J
j0rgeโข31d ago
I like this idea!!
Each pr currently fires off 59 builders
P
p5โข31d ago
My concern was it will (nearly?) double the time we are waiting to merge PRs, but if you're not bothered, I'm not
M
M2โข31d ago
I think it should be about the same amount of time. Since -dx builds base as well
Maybe a little slower due to second start.
Currently the pain is that the merge queue keeps failing on a single item
And it's just the usual stutter
N
Noelโข31d ago
We should definitely get retries in Bluefin and Bazzite like we do in main.
J
j0rgeโข31d ago
I think if we can come up with a reasonable facsimile we may be able to prove it's a good idea
M
M2โข31d ago
There are a few ignition files that people have done.
J
j0rgeโข31d ago
Then maybe when the coreos folks and us have time it'd be a neat thing to try sometime down the line
Then we do everything together
P
p5โข31d ago
How many problems do you think we'd have if we installed the CoreOS kernel from the older Fedora repo onto a more modern version of Fedora?
E.g. CoreOS uses F39 kernel. We can install the kernel from the F39 repos onto a F40 image.
B
bshermanโข31d ago
dependency problems
M
M2โข31d ago
Firmware and ?
B
bshermanโข31d ago
i'm actually running into a problem right now... i can't find the old kernels to install ๐
found em
https://github.com/coreos/fedora-coreos-config/blob/testing-devel/fedora-coreos-pool.repo
J
j0rgeโข26d ago
GitHub
User CoreOS kernels for :gts ยท Issue #1151 ยท ublue-os/bluefin
The 6.8 release hit F38 as fast as F39 so we ended up with broken v42loopback and stuff. I'd like to investigate a slower cadence for kernels. The CoreOS kernels are Fedora kernels, they just u...
J
j0rgeโข26d ago
moving to github
P
p5โข25d ago
My attempt at tracking the CoreOS kernel, and it's looking promising so far.
https://github.com/rsturla/eternal-main/pull/116/files
All I did was added a GitHub Action step to extract the kernel version string from a CoreOS container (6.7.7-200.fc39), and the version of the repo that kernel is coming from (39). I then pass the repo version into the FEDORA_VERSION build arg so the Containerfile can use that as a base.
During the build, I am reading the kernel version string from the CoreOS build arg and installing that same version.
If GTS can move from being latest-1 to instead track the CoreOS repos used, it should be fairly simple to implement in Bluefin. This means GTS would currently be on F39.
M
M2โข25d ago
Maybe we can turn on the repo for the kernel install and then turn it off?
Like what we do with negativio17?
Kernel dependencies should be limited to firmware + kernel itself
J
j0rgeโข25d ago
Does this have Nvidia implications?
M
M2โข25d ago
It would likely mean using the akmods for uCore
Which would be another complication since I believe we only build a subset of kmods compared to the main akmods repo
J
j0rgeโข25d ago
Ok so we wouldn't fall behind on drivers?
Oh ok
M
M2โข25d ago
It would mean recreating a good portion of akmods, or (more likely) adding this as another kernel variant there
P
p5โข24d ago
๐
For UBlue, we need to build akmods, hwe and main with the new kernel, but otherwise not too much hacking
B
bshermanโข24d ago
I think this should definitely wait until ublue akmods have switched to negativo17 since we had some blocking issues in that PR right @M2 ?
And yeah I have thoughts about how we handle the addition kernel variant.
At minimum we just build like we do today, adding the new coreos stable kernel version.
J
j0rgeโข21d ago
Fedora Discussion
Fedora CoreOS Community Meeting Minutes 2024-04-24
#meeting-1:fedoraproject.org: fedora_coreos_meeting Meeting started by @siosm:matrix.org at 16:30:59 UTC Meeting summary roll call (@siosm:matrix.org, 16:31:19) Action items from last meeting (@siosm:matrix.org, 16:35:53) LINK: h...
J
j0rgeโข21d ago
UKI kernel notes might be interesting
J
j0rgeโข3d ago
J
j0rgeโข3d ago
6.9 incoming at some point
heh they even put 6.8.9 in F38 lol
4.4KMembers
View on DiscordWant results from more Discord servers?
More PostsCan't access port 8080Does bazzite (or silverblue) come with some default firewall? I'm trying to access the CEF remote debazzite nvidia driver issuetoday my nvidia driver somehow failed and it went back to llvmpipe. i checked ptyxis and it told me Wifi network found, but cant connect to internetI just installed Bazzite on my Lenovo Legion Go for the first time. It can see my wifi network, but Legion Go - Fixed GPU clock not working with Simple DeckyTDPI have a Legion Go with SimpleDeckyTDP isntalled. If I enable it to overwrite the normal Steam TDP cNumLock on logon screenHi I'm new to Linux and decided try bazzite.
I have a problem where I have to turn on NumLock everyHow do I disable the Bazzite splash screen when opening a terminal.I'm using bazzite as my main desktop os and I want to disable the spash screen I see every time I opTDP limit not working?Probably just me doing something wrong but whenever I set the tdp to say 15 or 18, the graph still s(bazzite-gnome-nvidia) Gnome DE night light freezing Wayland immediately after loginGnome under Wayland is unusable if Night Light is enabled, instantly freezes the desktop when it begROG Ally back paddlesWould anyone be able to walk me through how to map the M1 and M2 buttons on the back of the ally to Waydroid window shows up, then closesWLRoot window opens with a black screen then instantly closesRules & Known Issues# Rules
1: Do not argue with those helping you, they are doing so out of their own good will and areHow do I activate batterylimit.service in bazzite (Legion Go)? I'd like it to only charge up to 80%:bazzite:launch waydroid app from game modebazzite-deck-gnome:stable | lenovo legion go
Waydroid launches fine from game mode, but I can't figissues installingIโm installing bazzite on a desktop and it keeps getting stuck here. Any guidance?audio cuts out on some games under loadMy audio (via HDMI from an AMD GPU) cuts out every so often on some games under load. I specificallylegion Go Desktop Resolution errorI changed the desktop resolution to 800p and now anytime I swap to desktop mode the screen is just abazzite installer won't boot up on surface book 2 (Nvidia)it just gets stuck on this screenBazzite-nvidia (KDE) keeps freezingHi,
I want to try switching to Bazzite as my OS so Iโve installed it on my secondary NVMe drive forAre there any plans to port brew toAre there any plans to port brew to ublue-os/config?looking at the brew pr in configlooking at the brew pr in config