ARM Enablement
https://pagure.io/fedora-asahi-remix-ostree/tree/f39 - I have put the stuff I am doing with fedora asahi remix on this repo
49 Replies
cc @jeefy @w8emv
My next step was going to be converting my asahi Linux system to ostree somehow
Also we will need aarch64 images and asahi specific in the end
@akdev I spent a weekend trying to do that following some of the stuff done in https://github.com/ublue-os/upgrade-tools and I never got it. Curious if this could have the missing piece.
GitHub
GitHub - ublue-os/upgrade-tools: Migration Tools
Migration Tools. Contribute to ublue-os/upgrade-tools development by creating an account on GitHub.
This looks exactly like what I need for testing
No fucking way it worked lmao
it worked on a VM at least
Okay so there’s only 1 point of variance in VM vs real HW which is that real HW boots using m1n1 > uboot chainload 🤔
I was reading today that ostree should support uboot natively so this should be easy hopefully
I could, through my sheer will of head-bashing into a brick wall, get it to work.
I am, also, not an actual linux nerd like @j0rge
But no joke if you manage to get something remotely working I'll test it on my m1 for validation within 24h
and your apps will be flatpaks, so like all your stuff will be up to date, you just won't be getting system updates but you know how to mitigate that already. I mean worse case ask alex to make you another one, but I bet ya'll will be done way faster
@jeefy, hey friend! I wrote this; happy to explain anything on it
Ayyyy! Hell yeah lmao
I killed my real asahi installation last night 😬
I wiped my Asahi ALARM install as well, looking forward to trying Asahi Fedora next month. Installed this in a VM in the meantime https://i.imgur.com/1sKsttT.png
Tried again and killed my install again
Following this process sadly doesn’t work on real HW 😦
Like I said I tried using it and lost about twenty hours of my life because I'm stubborn
But it's the closest thing to converting a regular install to ostree
I think the plan of attack will be to get two asahi installs going so I can compare them
It may ultimately be easier to figure out the way to make a payload for the installer
Fedora Discussion
Conformant GPU drivers and Remix updates
As of today, we’re happy to announce that Asahi Linux is fully conformant to OpenGL ES 3.1. This update is already available in the Fedora Asahi Remix, and existing systems can get by running dnf update (being mindful of the kernel-16k switch if you’re on an old install). We’d previously announced that we expected to officially release Fedora A...
I’ll switch out my container image to kernel-16k
using fedora asahi linux right now. it's quite challenging using it in a container-first way that silverblue would demand
many apps dont work ootb. even a lot of FOSS ones, like telegram not resolving an issue with jemalloc upstream because ???
back on arch you could recompile an app by pulling a pkgbuild from AUR and changing some settings so it would work on asahi. i guess you could do it in an arch distrobox but id rather have a flatpak
have you tried building the flatpak?
as such for asahi silverblue enablement i think a flatpak remote with fixed apps would be nice to have
pretty sure the intent is for flathub's flatpaks to work ootb on arm machines
ideally yes but some maintainers dont want to accommodate for asahi: https://github.com/telegramdesktop/tdesktop/issues/24564#issuecomment-1146508040
GitHub
Cannot start on Asahi Linux · Issue #24564 · telegramdesktop/tdeskt...
Steps to reproduce Try launching telegram-desktop. Expected behaviour TG should function on 16K page systems. Actual behaviour Crash immediately with the following error: <jemalloc>: Unsuppor...
yeah, the ecosystem will need to adapt and fix the issues, but that's always been the case with initial arm support for stuff
does that have something to do with the 16k page-size kernel they are now using instead of 4k?
It’s not the architecture that’s the problem, it’s the page size
try installing
kernel-4k to see if there's any differenceThat’s not recommended as that would mean things like USB ports don’t work
Asahi Linux only supports 16K page size really
GitHub
Compiled-in page size makes jemalloc binaries unportable · Issue #4...
I see that configure uses sysconf(_SC_PAGESIZE) at compile time to determine the page size. However, this can vary depending on kernel configuration, so a jemalloc compiled on one machine may have ...
It will never be fixed unless someone forks jemalloc is what I get
🍴
That fedora installation on my MacBook actually kinda boots
It gets to gdm and it freezes
So I think maybe the process actually worked but my container image is messed up? This is possible
Fedora Asahi Remix - Asahi Linux
Porting Linux to Apple Silicon
Back on my Arm laptop shenanigans for a bit, looking forward to getting Asahi on my MacBook Air and then somehow the next step involves ublue.
Is it likely for a bootable ISO to be published for an installer or that it will remain just
curl | sh?Apple Silicon doesn't support booting from USB AFAIK
According to https://support.apple.com/en-us/101578
By default no
“… If you're using a Mac with the Apple T2 Security Chip and you can't start up from the bootable installer, make sure that Startup Security Utility is set to allow booting from external or removable media”
Apple Support
Create a bootable installer - Apple Support
Use an external drive or secondary volume as a startup disk from which to install macOS.
T2 Security Chip is irrelevant for Apple Silicon
https://old.reddit.com/r/AsahiLinux/comments/187mhxv/installing_asahi_linux_on_external_ssd_or_usb/
Reddit
From the AsahiLinux community on Reddit
Explore this post and more from the AsahiLinux community
Oh yeah, of course T2 was for Intel chips and prior to M series
New in Fedora Asahi Remix - Asahi Linux
Porting Linux to Apple Silicon
Sorry all, I didn't realise there was a thread for ARM already.
ARM images are now being pushed to quay with the proper metadata, so this should be ready to start on again! Let's keep the conversation here, but below you can find the thread where we confirmed the arch is set correctly. https://discord.com/channels/1072614816579063828/1307078258805706842
ARM images are now being pushed to quay with the proper metadata, so this should be ready to start on again! Let's keep the conversation here, but below you can find the thread where we confirmed the arch is set correctly. https://discord.com/channels/1072614816579063828/1307078258805706842
:muscle_l:
If there’s a list of people you’re planning to ping at some point in the future when Apple Silicon support needs testing, please put me on it!
I'm about to do a clean asahi install, ublue still doesn't have working for aarch64 yet, right?
Nope. Waiting for GitHub builders
We expect to begin offering Arm runners for open source projects by the end of the year.https://github.blog/news-insights/product-news/arm64-on-github-actions-powering-faster-more-efficient-build-systems/ Have you heard anything since this about arm runner availability? The end of the year is right around the corner 😄
The new blog post after GitHub Universe said Q1 2025
ah, do you have a link?
also technically we don't have to wait for them
because we could use qemu in an x86 runner
but that would be a huge pain
Yeah - it's incredibly slow.
https://github.com/github/roadmap/issues/970
https://github.blog/news-insights/product-news/universe-2024-previews-releases/#:~:text=More%20compute%20resources%20and%20better%20insights%20for%20your%20workflows (expand the paragraph starting with "No matter what you're doing...")
ah i see, that "read more" link just looks like text