anything i can lend a hand with? seems like there are some PRs stacked up, but look like they are ho
anything i can lend a hand with? seems like there are some PRs stacked up, but look like they are holding on some upstream builds
Bappreciate the offer... hard to give much feedback right now.
in general:
in general:
- we're trying to cleanup a few issues (metadata and build reliability) in akmods
- trying to update the nvidia drivers (though that's on hold for some testing, but i need to cleanup PRs)
- it's not really written down anywhere, but after the metadata cleanup is done, i want to split our akmods so some of the current "extras" and new submissions can be built separate from our current "core" kmods.
MI can take a stab at the last one (extra) if that isn't already in the works somewhere? I can make an issue to track if it doesn't exist and draft up a PR. Were you thinking an image variant like with bluefin/dx?
MThinking about that a little more, it could be very similar to how you currently handle packages with the packages.json files. "core"/"extra" and then include/excludes for the kernel variants and/or fedora major versions
MI would like to add clevis-dracut to our builds. Clevis is already on disk. This will enable Tang Decryption on our builds as part of initramfs and matches what coreOS has by default
MGitHub
Clevis is another scheme for supporting LUKS decryption via tpm2 and/or a network based decryption scheme. Clevis is already included in our images; however, clevis-dracut is not. We've recentl...
IGotta say, I just finished getting an Alma Linux server up two weeks ago, running with clevis-dracut + TPM on boot decryption and it was cake. I like the experience soooo much better than without clevis-dracut
Ijust a thought from a rando
K
KAnyone else deal with this?
Byeah, i know its been discussed a bit, i think its related to other non-writeable paths which have causes issues for @jstone (and others) building F40 custom images
specific to the wget issue... one solution is switching to curl
specific to the wget issue... one solution is switching to curl
Kcoo, ez
Kthanks
Bmy pleasure, i'm kind of on a mission to standardize all the downloads in our akmods/main/hwe builds to only use curl, but it's definitely a back burner project
and mostly it's because it's a bit simpler than wget and i just want a single way to do it
and mostly it's because it's a bit simpler than wget and i just want a single way to do it
JI've had to work around
tar by splitting up the rpmspec sources https://github.com/joshua-stone/rose-os/commit/df0b7a8befd38aee1ac48169544b5a49f69f94f6#diff-3f44fdb366926104d6c798e448a2a403b3efb543e86c93ef1da13767e52fe578L12BI haven't created an issue yet... and I'm sorry don't feel like i have a bunch of time for it at the moment...
the idea i'm trying to communicate is more akin to how akmods already has "common" and "nvidia" builds split... I imagined another split "extras" which has things which are used in bazzite, but not bluefin, for example, while "common" is the smaller set which are in both and which were in the past, included in our main images
the idea i'm trying to communicate is more akin to how akmods already has "common" and "nvidia" builds split... I imagined another split "extras" which has things which are used in bazzite, but not bluefin, for example, while "common" is the smaller set which are in both and which were in the past, included in our main images
Badded the ticket, i owe everyone at least a small bit of documentation around the idea https://github.com/ublue-os/akmods/issues/176
GitHub
The more kmods we add to Containerfile.common the longer builds take, and, the more likely we break downstream builds for Aurora/Bluefin and others. Specifically, there are a number of kmods which ...
MYepp. /root isn't writable in the build container.
MIt appears harmless right now for our use in bluefin. But I would also like to move away from wget to curl to avoid noise.
Bi welcome PRs in akmods/main/hwe for this 
Bthis is new - from
ujust updatehmm. rpm-ostree requires sudo, I thought we had a polkit somewhere that enabled that.
Bit requires sudo if you ssh in, not if you are in a DE
Bi'm in ptyxis on localhost
B(this is bluefin 40 - maybe something changed upstream?)
Bmaybe... i haven't run 40 yet... but topgrade is weird to me... it could be piping stuff through ssh for all i know 
it could be piping stuff through ssh for all i know Bit's my new AMD gpu isn't it? I knew it couldn't be that simple
MAurora 40 could update earlier today without sudo
Bon a brighter note, I got ollama running with minimal fuss and it's awesome. I expected slow but it's really fast.
Bsuddenly my 2TB nvme drive feels small
Bwhat's next 4TB or jumping straight to 8TB?
Ti guess you could mount /root as tmpfs to get around this
TRUN --mount=type=tmpfs,target=/root or something
Tshould work
Tcurl seems a bit better tho LOL
KYeah curl it is
FWhere it uses an image for the base , am I able to install something like cclang and kvm ?
FI tried that with microOS and I was told it's more or less an awful idea.
Bmultiple drives in RAID? I think I'll surivive on the 2tb with some judicious pruning lol
NI got it running via this as well https://github.com/ericcurtin/podman-ollama
GitHub
Contribute to ericcurtin/podman-ollama development by creating an account on GitHub.
NI just ran the ./podman-ollama command on Bazzite and it pulled down a model and loaded it onto my 6900XT
Bi used ujust ollama - mayube the same underlying command
NI used that necessarily because Bazzite which is what I use on my gaming rig doesn’t ship with the ujust command afaik
NBut it uses the same docker image for sure lol
FI used curl, got burned by it when it downloaded corrupted file once, switched to wget, no problems ever since
Fbut this is just a personal experience
Xin my experience curl is more reliable, so i'm not sure what was up with our curl issue earlier
Nmore random yafti stuff...
Cthis is what the ujust command does:
C
