03:14 <copticcurse> I wanted to ask a noob question, what is the difference between m3 and m2 that makes it hard to port linux to m3?

03:30 <rinOfTheStars> Hey all. Getting an error I've never seen before when trying to dnf upgrade my Asahi Linux install: Error: Transaction test error: installing package kernel-16k-core-6.11.8-400.asahi.fc40.aarch64 needs 64MB more space on the /boot filesystem

03:30 <rinOfTheStars> Looking at the /boot fs it is indeed very full; does it keep old versions of packages around or something, or do I need to allocate it more space from the main asahi linux partition?

03:36 <rinOfTheStars> looks like there's some old versions of the kernel lingering for some reason

03:37 <rinOfTheStars> that's probably the issue, huh

03:41 <rinOfTheStars> that was indeed the issue, there was just barely not enough space due to the two old verisons of the kernel mucking around, lmao

03:43 <rinOfTheStars> for posterity's sake, if anyone has this issue in the future and searches through the irc logs to find an answer for some reason: https://www.reddit.com/r/Fedora/comments/1anh07j/boot_filesystem_needs_more_space_when_updating/ has the instructions on how to fix this, but do remember that asahi linux uses kernel-16k-core instead of kernel-core

07:49 <fl0_id> copticcurse Afaik it doesn't make it harder, but there are enough differences that it isn't super quick, and the main developers decided to focus on improving existing support first, like for improved graphics, getting microphones working etc which will later benefit m3 and m4 too. Instead of each year of device updates being busy with only getting support for that in. F.e. the gpu on m3 (and m4) is quite different from m1 and m2

08:08 <jannau> rinOfTheStars: just removing the old kernels is not a solution. there are intentionally the last 3 kernels. This is a config issue on old (before the release) installations resulting in huge initramfs eating all the storage on /boot. see https://discussion.fedoraproject.org/t/128788/2 for instructions to fix this

08:33 <fl0_id> copticcurse see also: https://mastodon.social/@marcan@treehouse.systems/113424157737265838

08:34 <yuka> Hi there, i'm fiddling around with a not-yet-supported apple silicon chip trying to get some sign of life out of m1n1. So far, I have set up a secondary APFS container, and done the kmutil thingy with a BRINGUP build of m1n1. I have also (theoretically) connected to the debug uart with a second apple silicon device and macvdmtool. Practically, I'm not getting any output on the uart. The target device bootloops. I tried adding a busyloop in the beginning of...

08:34 <yuka> ... the "_start_c" function to see if that would make it just stay on instead of rebooting, but it's still bootlooping. Do you people have any ideas for what I could try?

08:38 <yuka> Is there any way to test the macvdmtool debug uart thing with a mac os installation instead of m1n1, just to be sure that that is working correctly?

08:42 <jannau> yuka: macos logs to the uart with nvram "boot-args=-v" set but I haven't seen output with macos 15 production kernels

08:52 <jannau> yuka: if this is for m4* crash causing the bootloop is in init_cpu() just return early from that function

08:53 <yuka> wonderful, thanks

08:53 <jannau> which chip_id and EARLY_UART_BASE do you use?

08:55 <jannau> yuka: https://gist.github.com/jannau/3c4514584c6d155b76a25e34ae451a1e was working and producing output on debug uart

08:59 <jannau> yuka: #asahi-dev is the better suited channel for this topic

09:00 <yuka> Fair, just joined it

09:01 <yuka> How did you obtain the uart base?

09:01 <yuka> Ah wait

09:01 <yuka> Let me switch to the dev channe

10:37 <chadmed> mrosorensen: yeah, i also have the buzzing sound intermittently. not sure what we are doing differently at this stage, other than maybe wifi 2.4ghz coexistence?