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
lynndotpy has quit [Quit: bye bye]
lynndotpy has joined #asahi-alt
lynndotpy has quit []
lynndotpy has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
tobhe_ has joined #asahi-alt
cylm has quit [Quit: WeeChat 4.7.1]
tobhe has quit [Ping timeout: 480 seconds]
<craftyguy> is it 'normal' for udisks to complain about "No transport address for 'apple-nvme'" (the nvme cli tool also complains about this)
<mps> craftyguy: you managed to install and run pmOS?
<mps> craftyguy: nvme-cli doesn't work on alpine with apple nvme in last year or two. earlier it worked but only for some command. I guess this is because there is no apple plugin in it
nst has quit [Ping timeout: 480 seconds]
<sven> that sounds like a bug tbh
nst has joined #asahi-alt
chadmed has quit [Quit: Konversation terminated!]
pjakobsson has quit [Remote host closed the connection]
pjakobsson has joined #asahi-alt
n3ph has joined #asahi-alt
<mps> sven: bug in nvme-cli or kernel?
<sven> no idea, could be either
<sven> someone needs to figure out where that error message comes from
<sven> it’s probably some place in nvme-cli but it might just be an error propagated from the kernel
<mps> I will look at nvme-cli
<chaos_princess> whether a bug or not, it always did that
n3ph has quit [Ping timeout: 480 seconds]
<sven> it sounds like it’s trying to use some fabric code path
<sven> I guess they might hardcode a check for pcie somewhere and assume it’s NVMe over network otherwise
maettu1025 has joined #asahi-alt
maettu102 has quit [Ping timeout: 480 seconds]
maettu1025 is now known as maettu102
n3ph has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
<craftyguy> mps: yeah I've been booting pmOS from external storage. I'm working on adding support to our installer for the macbook, the installer uses udisks to enumerate target storage devices and udisks not finding nvme (because of that transport error) is a problem :P
john-cabaj has joined #asahi-alt
<sven> probably needs an additional strncmp(transport, "nvme-apple", 10) there
n3ph has joined #asahi-alt
<sven> and then possibly at other places too since it might just fail for the same reason later on then
<craftyguy> Ooooh ok I'll see if I can hack my way through it. I haven't had a chance to poke around yet
kode545 has joined #asahi-alt
kode54 has quit [Read error: Connection reset by peer]
<mps> craftyguy: I didn't used udisks so idk what is the solution
opticron has quit [Read error: Connection reset by peer]
opticron has joined #asahi-alt
<sven> fix libnvme :D
<sven> everything that uses libnvme right now won't work with the apple controller
<sven> because it assumes that it needs an address (think nvme over ethernet) for anything that's not pcie
* craftyguy working on fixing libnvme
<craftyguy> Or, at least trying 🙃
<sven> want me to write you the patch?
<sven> it's really just adding strncmp(transport, "nvme-apple", 10) to that if clause above
<craftyguy> I already did that, and nvme list now works
<sven> nice, should be fine then
<craftyguy> I was trying to understand the rest of libnvme to see if I need to also patch something else 🤷‍♂️
<sven> ideally create a PR on that project so that it's fixed for everyone :)
<craftyguy> Yeah of course :)
<sven> i quickly read through the code, i think that's the only place required
<sven> it's just trying to guard against later errors from the kernel from what i can tell
<mps> is BTI kernel config work on apple silicon
<mps> craftyguy: when you finish patch please post url, I want to add it to alpine
<craftyguy> thanks, that was going to be my next move 😛
<mps> craftyguy: thanks. iiuc you will add it to alpine?
<craftyguy> Amazing, now udisks finds the local nvme 🥳
<sven> probably needs a singed-off-by and maybe an explanation why that changes fixes it
<craftyguy> mps: ya I was going to
<craftyguy> sven: I don't fully understand why it it shows as "apple-nvme", because apple silicon doesn't use pcie or ?
<sven> yeah
<sven> it's a platform device there with a separate driver called "apple-nvme"
n3ph has quit [Ping timeout: 480 seconds]
<craftyguy> Ok I'll attempt to explain that heh
<craftyguy> K, done. Thanks for the help Sven :)
<craftyguy> mps: I'll send the patch to Alpine after I have some breakfast
<mps> craftyguy: please create MR for it
<craftyguy> Of course 😛
n3ph has joined #asahi-alt
<noisycoil[mds]> sven: is the driver responsible for that already in the upstream kernel?
<sven> yes, for a long time
<noisycoil[mds]> Nice, thanks
chadmed has joined #asahi-alt
<noisycoil[mds]> Works for me on Debian too
<vimproved> heads up, mesa-asahi-flatpak is triggering lib protection on the update to libxml2 2.14.6: https://paste.gentoo.zip/qBJIwqCZ
<jannau> time to purge it with fire?
<vimproved> perhaps
seb_ has quit [Quit: Konversation terminated!]
<chadmed> im not sure how we would force portage to remove it automatically
<chadmed> i think ill just write a news file
<mps> craftyguy: nice, now nvme-cli works on alpine
<jannau> we can't mask packages from the overlay?
<vimproved> chadmed: yeah no idea either
<chadmed> i think if we mask it portage will just quit and tell you that you have installed masked packages right
<vimproved> portage wont quit in that case, it will just ignore the package and keep going
<vimproved> but if you mask the package and remove it as a dependency from asahi-meta, then it'll just depclean
<vimproved> er, it will get removed with a depclean
<vimproved> my bad, it's not a dependency of asahi-meta in the first place
<vimproved> but if you mask it will just show the user they have masked packages installed with the mask reason, and continue on
<vimproved> won't actually prevent portage from working
<chadmed> okay cool yeah like what md4sum just did last week
seb_ has joined #asahi-alt
seb_ has quit [Read error: Network is unreachable]
<craftyguy> so... uh... Do I need a macbook with apple silicon to do the dfu recovery thing on an M2?
<jannau> no, https://docs.fedoraproject.org/en-US/fedora-asahi-remix/troubleshooting/#dfu-fedora and ignore that the instructions are written for fedora
<jannau> you need an snapshot of idevicerestore though
<craftyguy> snapshot?
<jannau> the latest release is (or was) too old to support apple silicon macs
<craftyguy> ahh ok. thanks for the pointer, I was starting to ask around for a friend with a macbook 😅
<jannau> partitioning mishap?
<craftyguy> yeah :P
<mps> there is idevicerestore 1.0.0 on alpine. don't know if it works
<craftyguy> yeah that version is 5years old. I'm building it from git now
<chadmed> 1.0.0 is too ol
<chadmed> d
<chadmed> even the latest release on gh is too old, just build from main
<craftyguy> ya that's what I meant by "from git", building from main :)
<jannau> 1.0.0 is the latest release on github
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
<craftyguy> k it picked up the macbook and seems to be downloading 15.6.1 for it
<chadmed> its actually a pretty good bit of kit. i used it to back up my phone before coming to britain
<chadmed> just wish they actually did releases and such :p
<craftyguy> is there some stated reason why they don't?
<chadmed> not that i have seen
<craftyguy> dang, seems to just get stuck at 'Waiting for device to enter restore mode...' after it downloads, verifies, and sends some stuff(?) to it
<jannau> are you sure the device is the the correct mode? is the display black?
<craftyguy> it was in DFU mode when I started the tool, then while the tool was running the laptop rebooted(?) and showed an apple with an empty status bar under it for a bit. and just now it rebooted to the "support.apple.com/mac/restore" screen and the tool is still stuck on that message ^^
<craftyguy> ah it just now failed with "Device failed to enter restore mode."
<jannau> might be an issue with usbmuxd, not sure if that would fail earlier
<craftyguy> hmm ok. The tool does see the macbook and recognize the type and that it's in DFU mode when it first runs
<jannau> is usbmux running when you connect the macbook in dfu mode (and no other apple devices connected). I'm not sure if the DFU usb product id activates it
<jannau> is usbmuxd running now?
<tpw_rules> craftyguy: i have some notes on the process here but they haven't been tested in a while: https://github.com/nix-community/nixos-apple-silicon/blob/main/docs/uefi-standalone.md#recovering-from-boot-failure-with-idevicerestore
<tpw_rules> you can manually run usbmuxd with like sudo usbmuxd &
<tpw_rules> according to my notes your problem indeed sounds like usbmuxd is not running right
<craftyguy> oh gosh, usbmuxd wasn't even installed. packaging fail. installed it and started it, and now it seems to be getting further
kode545 is now known as kode54
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #asahi-alt
<craftyguy> restore successful, thanks for the help y'all :)
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #asahi-alt
<craftyguy> was the UEFI-only image updated to have a recent m1n1 binary in it?
<craftyguy> If not, is there a patch I could send somewhere to do that? :)
<craftyguy> oh yeah I guess it's still installing an old one, "os_package: uefi-only-20231220-1.zip"
WoC has quit [Remote host closed the connection]
WoC has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
john-cabaj has quit [Ping timeout: 480 seconds]
nela5 has joined #asahi-alt
nela has quit [Ping timeout: 480 seconds]
nela5 is now known as nela