ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
zerdox has quit [Remote host closed the connection]
hightower3 has joined #asahi-alt
hightower2 has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
<zerdox>
MichaelLong did you encounter `thread 'main' panicked at '"ftrace_branch_data_union_`? I am trying to compile the kernel finally. I found one guy in rust-for-linux zulip chat, he met this error 2 months ago. and i also googled some email from 5 april mentioning my error
<chadmed_>
zerdox: at runtime?
<zerdox>
chadmed_: trying to genkernel
<chadmed_>
i dont think genkernel really supports rusty kernels atm, youll have to do it manually
<chadmed_>
its not that hard
<zerdox>
do i need to do something different in asahi case? instead of --all-ramdisk-modules
<chadmed_>
so youve built the kernel already and youre just trying to make an initramfs?
<zerdox>
chadmed i have not yet built anything
<zerdox>
it doesn't matter if i run genkernel or make LLVM=1. i get thread panicked while compiling kernel
<chadmed_>
hm so the compiler is panicking interesting
<chadmed_>
did you install rust-bin or rust
<zerdox>
rustup
<chadmed_>
ah so you followed the quick start guide
<chadmed_>
hmmm
<chadmed_>
can you paste the entire build log somewhere
<zerdox>
nothing interesting in logs actually. i am using default asahi kernel config just with rust enabled. my rustc and bindgen versions are exact required. i am using 16 llvm
<chadmed_>
is bindgen in your PATH?
<chadmed_>
also just building the config in /proc/config.gz wont enable the gpu or dcp. you need to go and set those options in menuconfig.
<zerdox>
of course. /home/user/.local/share/bin/bindgen
<chadmed_>
??? it should be in $HOME/.cargo/bin
<zerdox>
i don't like littering my $HOME
<zerdox>
i changed CARGO_HOME and RUSTUP_HOME
<zerdox>
that's normal case. lol
<chadmed_>
right ok
<chadmed_>
does seem like a bindgen issue at the very least
<chadmed_>
what version of rustc have you set for the kernel source tree
<zerdox>
how can i see it? i've pinned rustc version as in quick start and then added rust-src component
<chadmed_>
rustc --version from inside /usr/src/linux
<chadmed_>
also
<chadmed_>
you should mirror this as root, idk if genkernel tries to build the kernel as root
<chadmed_>
but as a standard user you dont have write perms to /usr/src so ofc its gonna fail writing bindings there
<zerdox>
yeah i am as root
<chadmed_>
yeah so youll need to set up the rust stuff as root and source $CARGO_HOME/env as root
<zerdox>
rustc 1.66.0 (69f9c33d7 2022-12-12)
<zerdox>
i've already set all this up. running make rustavailable as root gives me "rust is available "
<chadmed_>
just running through the possibilities
<chadmed_>
it does look like youve misconfigured bindgen somewhere along the line though
<chadmed_>
since its panicking in a dependency of bindgen
<zerdox>
i haven't done any configurations to bindgen
<zerdox>
i'll try to reinstall it...
<chadmed_>
yeah i mean the install process
<chadmed_>
you should probably just install all of this as root instead of trying to kludge its CARGO_HOME to your local user tbh
<chadmed_>
like i said from the outset it becomes very hard to offer support to people when they start doing weird nonstandard things and stuff starts breaking
<zerdox>
wdym?... cargo_home is in user's hom directory by default
<chadmed_>
when you install as root it should install it to the root's home directory, not yours
<chadmed_>
the fact that its trying to call into bidngen from your own home dir instead of /root/.cargo/ suggests you have not set any of this up properly
<zerdox>
ok. one moment
<zerdox>
which rustc: /root/.cargo/bin/rustc
<zerdox>
which bindgen: /root/.cargo/bin/bindgen
<zerdox>
rustc --version: rustc 1.66.0
<zerdox>
bindgen --version: bindgen 0.56.0
<zerdox>
everything is the same. same panick. i'll now cleanup my root...
<chadmed_>
try bindgen 0.62
<zerdox>
sure
<zerdox>
no Cargo.lock file published in bindgen v0.62.0
<zerdox>
there is nothing to install in bindgen because it has no binaries. cargo install is only for installing programs, and can't be used with libraries
<zerdox>
yay. it's doing something... i will try to login to my user now and continue the work with the newer bindgen. could you please share which settings do i need to change so my gpu would work properly?
<chadmed_>
youll be able to find the config options in menuconfig by searching for them
<chadmed_>
you already have dracut installed which has the appropriate firmware and driver hooks set up from the install script, so instead of using genkernel to generate an initramfs use dracut --kver $(make -s kernelrelease)
cylm has joined #asahi-alt
<zerdox>
chadmed_: ty. i successfully compiled and applied new kernel. but as soon as i boot in, see some linux init logs and login prompt, screen goes black. nomodeset "fixes" it
<zerdox>
idk why i am so unlucky but everything on my machine goes unexpected. sorry
<chadmed_>
oh yeah thats an xorg/dcp thing
<chadmed_>
xorg relies on features that are not present in the hardware because its not 100 quadrillion years old
<zerdox>
xorg? i thought it's some stuff for graphical environment, like wayland
<chadmed_>
your display manager (i assume sddm) probably uses xorg so when openrc goes to start it, it causes issues
<chadmed_>
wayland works perfectly
<zerdox>
nah
<zerdox>
its just tty
<zerdox>
nothing xorg or wayland
<zerdox>
no DMs to
<chadmed_>
oh interesting
<zerdox>
too*
<chadmed_>
is that reproducible
<chadmed_>
like does it happen every time you boot
<zerdox>
prob i need to get some logs
<zerdox>
yea i got it twicr
<chadmed_>
can you check to make sure that the display-manager service is not in any runlevel
<zerdox>
i have not even installed any
<chadmed_>
okay
<zerdox>
like i barely installed this system and trying to get hyprland work with my gpu
<chadmed_>
so before, when you booted, the system just greeted you with a tty
<chadmed_>
you didnt have hyprland starting automatically or anything
<zerdox>
yes
<chadmed_>
cool
<chadmed_>
did you install the kernel manually or use genkernel
<zerdox>
tty goes bye-bye when driver module gets loaded. seems like it
<zerdox>
manually
<chadmed_>
and you ran make modules_install right
<zerdox>
yeah
<chadmed_>
hmmm
<zerdox>
i will try to do it again actually
possiblemeatball has quit [Quit: Quit]
<chadmed_>
the output of asahi-diagnose would be cool pasted somewhere
<chadmed_>
and your dmesg
<chadmed_>
ill get around to patching asahi-diagnose for gentoo at some point
<zerdox>
how can i do it?
<chadmed_>
assuming you didnt nuke the old kernel and initramfs grub should still have a boot option for it under advanced settings
<chadmed_>
so you can boot back into a working system
<zerdox>
i can boot back to the new kernel with nomodeset option
<zerdox>
and yeah i can still load to the old kernel
<zerdox>
currently i am booted with nomodeset
<chadmed_>
oh yeah then just run asahi-diagnose and paste the output somewhere
<chadmed_>
you can write a little shell function/alias to pipe the output of some command into tpaste
<chadmed_>
do the same with dmesg since asahi-diagnose looks for journalctl and not dmesg
<zerdox>
for the context by black i mean i get no backlight. like it's completely off, when you turn down brightness to zero on macos
<zerdox>
is it possible that my backlight level is set to zero? just in case...
<chadmed_>
thats what i was thinking
<chadmed_>
you can try change it with the sysfs variables in ssh
<zerdox>
chadmed_: i can't really find exact file for that
<chadmed_>
itll be in /sys/class/backlight somewhere
<zerdox>
yeah.. but is a bunch of folders which are symlinked to each other
<zerdox>
i've installed `light` package and it says 33.33 on apple-panel-lb and 100.00 on gpio-bl. so this is not the case
chadmed_ has quit [Remote host closed the connection]
zerdox has quit [Read error: Connection reset by peer]
zerdox has joined #asahi-alt
cylm has quit [Ping timeout: 480 seconds]
jn has quit [Read error: No route to host]
ktz_ has joined #asahi-alt
jn has joined #asahi-alt
<ktz_>
hello, on the conversation we had on #asahi, I mounted esp on /boot/efi and installed m1n1 and u-boot-asahi, when restarting I've had the exact problem I described when the same thing happened from an alarm update. I can get to boot and get to my DE but everything is incredible sluggish and I can't even use it. I'm currently booted from alarm now
<ktz_>
my problem is that alarm at least didn't entirely replace boot.bin, it was also leaving a boot.bin.old behind which I could replace the new one with and boot back normally, but alpine doesn't do that so I need to find some other way to fix it
<ktz_>
on a positive note I'm getting no errors on dmesg and a different one when trying to start an ap on alarm. keyboard and mousepad are also working as expected
<mps>
ktz_: so you have alarm and alpine installed iiuc
<ktz_>
mps: correct
<mps>
this is 'calling for troubles'
<ktz_>
I'm using alpine mainly, I've got the alarm installation for situations like these just for debugging
<ktz_>
I haven't had any of those problems for months to this point and I've always had both installed
<mps>
kernels are different and by this dtb is not same
<ktz_>
on two separate machines as well
<ktz_>
should that really be a problem since there are two different esps separate for each one?
<mps>
how do you select which ESP is read on boot?
<ktz_>
that's a good question, I assumed its correctly mapped to the corresponding one up to this point
<mps>
i.e. which second stage m1n1 is used
<mps>
`cat /proc/device-tree/chosen/asahi,efi-system-partition` will show which ESP is used
<mps>
also `cat /proc/device-tree/chosen/asahi,m1n1-stage2-version`, filename tells
<ktz_>
okay I'll reboot into alpine and check it out
ktz_ has quit [Remote host closed the connection]
ktz has joined #asahi-alt
<ktz>
mps: both alarm and alpine use the same partition
<mps>
ktz: that could be why you have problems
<ktz>
yes, thanks for helping me find out. is there anything I can do to fix it?
<mps>
use just one ESP, i.e. remove one you don't need
ktz has quit [Remote host closed the connection]
<mps>
on alpine you should have something like 'PARTUUID=... /boot/efi auto auto' in /etc/fstab
ktz has joined #asahi-alt
<jannau>
do you have two entries for alpine and asahi in the macos boot picker you get when you keep the power button pressed?
ktz_ has joined #asahi-alt
<ktz_>
jannau: yes, I do
<jannau>
then you should get different values in /proc/device-tree/chosen/asahi,efi-system-partition for alarm and alpine
<ktz_>
mps: no I haven't..
<ktz_>
mps: this is likely the answer to the dtbs problem
<mps>
ktz_: you should mount proper ESP for /usr/sbin/update-u-boot-asahi to work properly
<mps>
with PARTUUID in /etc/fstab you could have proper ones mounted for alpine and alarm
<mps>
i.e. different ESPs for different OS
<ktz_>
on alarm I'm getting contradicting output or I'm missing something?
<ktz_>
nvme0n1p9 is alpinelinux and nvme0n1p5 is alarm
<jannau>
you have a mismatch. UUID of 80281940-c4e6-40d8-b83f-f509a98c9338 is 8860-08F1
<ktz_>
should fstab contain both entries?
<jannau>
you should be fine if you change "UUID=F7C9-0138" to "PARTUUID=80281940-c4e6-40d8-b83f-f509a98c9338" in fstab
<ktz_>
this is on alarm (nvme0n1p5) shouldn't it point to nvme0n1p4 instead? the one you suggested is nvme0n1p7 instead, alpine's esp
<ktz_>
thanks for trying to help in any case
<jannau>
/proc/device-tree/chosen/asahi,efi-system-partition is what m1n1 cares about. if the OS doesn't match it will cause problems. can you verify that it differs between alarm and alpine
<ktz>
jannau: /proc/device-tree/chosen/asahi,efi-system-partition looks the same
ktz has quit [Remote host closed the connection]
ktz has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
<ktz>
mps: any idea at least on how to fix my alpine installation? its unusable as of now after adding u-boot-asahi and m1n1 packages and having m1n1 upgraded
<mps>
ktz: no idea for stable solution. you could mount proper ESP and /usr/sbin/update-u-boot-asahi
<mps>
run*
<mps>
and copy m1n1/boot.bin to alarm ESP
<mps>
to have same boot.bin on both ESP
<ktz>
I just ran /usr/sbin/update-u-boot-asahi, I'll try to boot on alpine
ktz has quit [Remote host closed the connection]
<mps>
but my real advice is 'use alpine only', not because alpine is perfect (it is not) but other distros are worse (sorry if I offend someone)
<_jannau_>
that doesn't help if both first stage m1n1 set te same "asahi,efi-system-partition"
<mps>
or other advice is stick with one prefered distro until m1n1 can select proper ESP
<_jannau_>
no idea how that could have happened without manually breaking things
<_jannau_>
m1n1 does that. the only problems we had where distro packaging unpatched u-boot which doesn't use the slected ESP
ktz has joined #asahi-alt
<ktz>
so the way to fix my issue is having alarm deleted? that won't really bring back the boot.bin version which makes my boot functional in the alpine esp, am I wrong?
<ktz>
the m1n1 is lastly updated via alpine so even if both use it, it should likely be fine with alpine I suppose
<mps>
as jannau told, maybe patched u-boot could help
<_jannau_>
running /usr/sbin/update-u-boot-asahi on alpine should produce a working boot.bin
<ktz>
yes but it doesn't as I just mentioned
<_jannau_>
a patched u-boot will not help as long as both installs report the same "asahi,efi-system-partition" when selected through the macos boot picker
<mps>
ktz: if you want you can install linux-asahi-edge and mesa-asahi for alpine from my private repo
<mps>
I'm sure this combo works very fine on m1 and m1pro macbooks
<ktz>
I hadn't booted each one via macos tho, I did run distro_bootcmd to boot in alarm instead
<mps>
(time for coffee break)
cylm has joined #asahi-alt
<_jannau_>
ktz: that can not work and probably explains your problems. you have to use the macos boot picker for multi alternative os support
<ktz>
okay, good to know thanks. I'll try mps' edge kernel and hopefully this fixes the issues on my alpine installation
<mps>
marcan: I ported PKBUILDs for asahi-scripts and asahi-fwextract from asahi to alpine APKBUILD. but I'm not sure what to do with 'Maintainer' field. on one side all credits belongs to you because porting was easy
<mps>
but on other side it is not good to report to you issues for alpine
<mps>
don't know what to do with this field
stipa is now known as Guest10828
stipa has joined #asahi-alt
Guest10828 has quit [Read error: Connection reset by peer]
<chadmed>
mps: i assume the convention is the maintainer of the package, not the maintainer of the code
<chadmed>
at least thats how it is with gentoo ebuilds
ktz has quit [Remote host closed the connection]
<mps>
chadmed: I agree, but because PKGBUILD and APKBUILD are nearly same I though it would be polite to ask author (marcan) of these two PKBUILDs
<chadmed>
oh right the files themselves are similar
<chadmed>
two maintainers i guess :P
<mps>
heh
<mps>
alpine allow only one maintainer
<mps>
and many 'Contributor: '
jamespmorgan has joined #asahi-alt
<_jannau_>
I'd sugest to take the maintainership and add a comment that it is based on the asahi PKGBUILD
<_jannau_>
the original author doesn't maintain your copy
ktz has joined #asahi-alt
<mps>
_jannau_: this sounds reasonable to me, I thought to do this but again wanted to ask original author
<ktz>
I still face the same issue, boots, can open my wm but everything is unusably slow
<ktz>
I was missing dri-gallium but I don't that's the cause, its related to m1n1
<psykose>
you would need all of the mesa-asahi-* packages as overrides, in that case you are missing mesa-asahi-dri-gallium
<mps>
oh, you have both mesa and mesa-asahi installed, this should be possible
<psykose>
don't think it is
<mps>
psykose: rihgt, I meant to write 'not possible'
<ktz>
yes I see mesa-glapi-23.0.2-r2 aarch64 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed], let me replace it with the asahi version and I'll try to boot again
<psykose>
you need mesa-asahi-dri-gallium to have anything work pretty sure :p
<psykose>
you also don't have to reboot, just restart whatever you had the session in
<ktz>
I'm booted from alarm now
<ktz>
and chrooted in alpine
<mps>
ktz: you are messing my mind, never sure when you are talking about alpine or alarm
<ktz>
always alpine, I only use alarm when I can't boot into alpine, and when booted on alarm I'm talking alpine chroot so alpine
<mps>
but I see from your dmesg that you booted alpine
<_jannau_>
generally don't expect graphics to work from the alpine chroot
ktz has quit [Remote host closed the connection]
<j`ey_>
_jannau_: you've said before that DCP is slow without the GPU right? So I guess that's what they're seeing
<mps>
j`ey_: also I think so
<mps>
few days ago when I upgraded to mesa with changed UAPI version it was slow
ktz has joined #asahi-alt
<_jannau_>
it slower than software rendering but not 2 seconds to launch foot slow. that could the subotimal kmsro behavior people where seeing on fedora with many kmsro drivers enabled
<ktz>
okay thank you all guys, at least I'm back on my system
<ktz>
everything works properly
<mps>
ktz: alpine or alarm
<ktz>
with the edge kernel and all the mesa-asahi packages
<ktz>
alpine as always hehe
<mps>
ok, you now have GPU working
<ktz>
only thing, still missing keyboard on wm, while it works on tty
<mps>
then input devices should work out of the box
<j`ey_>
ktz: yeah that's normal
<j`ey_>
it tries diffferent firmware names in a row, to get the right one
<mps>
yes, same on my machines
<mps>
ktz: do you external usb keyboard
<mps>
use*
ktz has quit [Remote host closed the connection]
<mps>
ktz: btw, you now have asahi-scripts and asahi-fwextract in my apk repo
ktz has joined #asahi-alt
<ktz>
mps: yes I use an external one but I'm trying to get the builtin one functioning as well so its portable, same for mousepad, not sure whats wrong with them
<ktz>
mps: should I run any of those?
<mps>
have no idea, internal keyboard and touchpad works for me from the beginnig (year and a half ago) without problems
<ktz>
yes its strange, even the other firmware errors are gone from dmesg now... but still no luck. Maybe its something to do with wayland/sway in the end
<mps>
ktz: you could try to install linux-asahi-edge-dev and fix this to use it and then try to build
<mps>
do the wayland need some config file for libinput to work
<mps>
i have something in sway config
<ktz>
it used to work perfectly for my previous m1 air, same sway config...
<marcan>
mps: maintainer != author, you're the maintainer for the APKBUILD, not me
<marcan>
feel free to note the origin of the script if you want, though I personally don't particularly care
<mps>
marcan: ok, thank you
<marcan>
I don't think we have a license on that repo explicitly, we probably should, but I basically consider everything in there (except for patches subject to upstream licensing) public domain for any distro to adapt as they wish
<mps>
that is also issue for alpine APKBUILD files
<marcan>
if we didn't have derivative PKGBUILDs in there I would add a blanket MIT-0 to the repo
<marcan>
let me add something
<chadmed>
hopefully the patched packages go away at some point
<marcan>
well this includes uboot-asahi which won't
<marcan>
and linux-asahi and mesa-asahi which will probably live forever as downstream bleeding edge packages if nothing else
<jannau>
ack for my contributions as far as they aren't derivative
<marcan>
was about to ask
<marcan>
and the remaining contributions are few and very trivial, so I think I can just do this
<jannau>
also questionable if they fall at all under copyright (depending on the legislation). not much freedom to express them differently and still have working packages
<marcan>
yeah, agreed
<marcan>
but I might as well clarify in case someone thinks they do