16:52 <cy8aer> Glanzmann: I wonder if it would be worthwhile to put the dcp kernel on the debian-installer stick? With asahi_drm it should not have these text mode changing problems anymore.

16:57 <Glanzmann> cy8aer: I think I rather wait until it is in the asahi distribution, because it is still now very widely tested.

16:57 <Glanzmann> And I thought the font is big enough to read.

17:04 <Glanzmann> not*

17:09 <cy8aer> sounds reasonable

17:21 <Chainfire> thx @Glanzmann. Trying it now

17:26 <Glanzmann> Chainfire: Let me know, how it goes.

17:50 <Chainfire> @Glanzmann> works like a charm. Any plans to make a full desktop image a la what Debian has for amd64 ?

17:53 <Glanzmann> Chainfire: Not really, I mean you can just install the packages you want including the desktop environmnt. So I don't see the reason to do so.

17:54 <Glanzmann> Btw, I updated the Debian kernel to match the asahi one. Still no dcp or gpu. Someone requested that I publish all kernel packages. They can be found here: https://thomas.glanzmann.de/asahi/2022-12-04/

17:55 <Chainfire> oh yeah its just a mild inconvenience I have to do that manually the once every 6 months I use this haha. Thanks for your work on that, that's twice it saved my bacon

17:55 <Chainfire> So the reason the old version (made probably >6 months ago) stopped working is probably that m1n1 file?

17:58 <Glanzmann> Chainfire: The kernel need to match the device tree which is besides m1n1 and u-boot in the boot.bin file. So if the kernel is incompatible to the device tree it won't boot or do stupid things or does not detect hardware or god knows what.

17:58 <Chainfire> Gotcha

17:59 <Glanzmann> Chainfire: In the far future the device tree will hopefully stabilize and also be downward compatible, but currently it isn't.

18:21 <Chainfire> Glanzmann> suggestions: (1) change docs to include doing an 'apt update' before 'apt-get install' because it just failed without that (2) put the url to the docs in the login message

18:21 <Chainfire> and by docs I mean - https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/

18:27 <Glanzmann> Chainfire: I added the 'apt-get update' everywhere. When you log in there is a file called quickstart.txt which contains all information necessary.

18:46 <janrinze> Glanzmann: the issue with u-boot is that is scans for EFI partitions and does not know which was the intended one.

18:48 <janrinze> I solved my issues by using the same boot.bin and BOOTAA64.EFI on both EFI partitions. also needed to have the same grub version and files on ARCH and Debian partitions.

18:48 <janrinze> op top of that need to have the same kernel on both ARCH and Debian

18:50 <janrinze> makes me wonder if it's easier to have one EFI partition and use that for all Linux installations.

18:51 <janrinze> also that EFI partition could host the whole /boot directory..

18:51 <janrinze> just a thought..

18:54 <Glanzmann> janrinze: The general idea is to have on esp partitio. Asahi is special.

18:54 <janrinze> sidenote : ARCH and Debian can't share the same initrd.img because those work differently on each distribution.

18:55 <sven> there’s a reason we decided for multiple of those partitions, see https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-Macs

18:55 <Glanzmann> You can use the esp as /boot but most distributions do it differently.

18:57 <janrinze> sven: u-boot scanning for EFI partitions might not be compatible with the description in that link.

18:57 <sven> the one shipped with the official asahi installer?

18:57 <sven> I doubt that

18:59 <Glanzmann> janrinze: Jannau wrote a patch that tells u-boot for which esp to look for. I reverted that patch in the Debian installer.

19:00 <Glanzmann> janrinze: So with asahi boot.bin you're good with debian you aren't. Until you start shuffling parition numbers, because I think Debian as well as Asahi grub have the partition number (not uuid) hardcoded in the efi binary: strings /boot/efi/EFI/BOOT/BOOTAA64.EFI | tail -1 | pbot - > https://pbot.rmdir.de/h0Jz-cz3E9CeShztJLQ0jA

19:03 <Glanzmann> I updated the Debian kernel again - forgot to do a pull and ended up with an old version. All the other artefacts are also rebuild.

19:04 <janrinze> Glanzmann: yup.. so if after Asahi installation we should not resize the OSX partition again when installing another Linux OS.

19:04 <janrinze> Glanzmann: because that will reshuffle the partition numbering.

19:05 <mps> Glanzmann: replied, but forgot add 'fell free to ask for explanation about APKBUILDs'

19:06 <Glanzmann> mps: THanks.

19:07 <janrinze> sven: you are sure that PARTUUID/UUID is used throughout in Asahi Linux boot process?

19:08 <Glanzmann> janrinze: Exactly. When you add additional installations they need to be added behind the current installation, otherwise you need to install grub. In addition to that the u-boot that is shipped by me always picks the first esp. OpenBSD does the same.

19:08 <j`ey> https://github.com/AsahiLinux/u-boot/commit/300817d324f73c30c998a10435d5d830b58df894

19:10 <Glanzmann> janrinze: THe patch that j'ey just posted is used as the following m1n1.bin passes the part uuid of the esp to 'boot.bin aka m1n1 stage2' u-boot picks than the right esp. However if the partition numbers are shuffled than grub might pick the wrong boot partition. I know that marcan tried to use the partuuid by that. An Debian did that previously but currently nolonger does that (maybe because I use

19:10 <janrinze> j`ey: so the issue was that Debian install did not comply with that way of working for u-boot. Correct?

19:10 <Glanzmann> it wrong or differently than before).

19:11 <janrinze> Glanzmann: the patch is from july 11th, was that the one you reverted?

19:11 <Glanzmann> janrinze: I think you had two issues: 1) debian u-boot picks first esp. 2). You first installed asahi, than made macos smaller and installed Debian. By doing that you shuffled the partition numbers which made the asahi grub choke on.

19:12 <Glanzmann> janrinze: Yes. It is a patch that is only used by asahi. Upstream u-boot, bsd and Debian and Fedora version does not use it, don't know about the others.

19:12 <janrinze> Glanzmann: hard to remember if my Asahi install was older than the patch from j`ey. If it was there was no way this could be prevented.

19:13 <Glanzmann> The reason I don't use it because Debian was available before the the patch and I did not want to annoy existing users. But the patch from jannau is very careful. If no esp part uuid is specified or it can't find it it lets the user know what to do.

19:13 <janrinze> j`ey: in general Asahi Linux installations after the adoptin of your patch should not be having any trouble such as the one I experienced, right?

19:14 <Glanzmann> janrinze: It depends on if you installed before or after the alpha release.

19:14 <Glanzmann> The patch was added last minute to the alpha release.

19:14 <jannau> janrinze: it was just committed in that branch on july 11th, the change was included in every asahi release since the alpha release

19:15 <Glanzmann> janrinze: And you installed in the summer, so you already had the pathc.

19:15 <janrinze> jannau: and grub, did that have a ,gtp5 reference?

19:16 <Glanzmann> janrinze: Jannau pasted a strings from the grub.efi the other day. THere you could see two references. One ussing the uuid and one using the partition number.

19:16 <Glanzmann> Let me get my wifes notebook and reproduce what you did.

19:16 <jannau> commit has an author date of 20th february 2022

19:16 <janrinze> Glanzmann: make backups first ;-)

19:17 <mps> janrinze: not sure for debian grub but usually grub-install embeds partition in bootefi

19:17 <mps> BOOTAA64.EFI*

19:17 <janrinze> mps: seems it's inside grub binary as a sting

19:17 <janrinze> oop string

19:17 <janrinze> oops...

19:17 <mps> yes, grub-install set it

19:18 <janrinze> where do i find grub-install?

19:18 <mps> in grub pkg

19:18 <jannau> the problem is that the path to the config is using hte partition number

19:19 <Glanzmann> janrinze: This is why I use my wifes laptop, than I don't have to.

19:19 <janrinze> jannau: not just the config , the grub modules too

19:19 <janrinze> jannau: and if these modules don't match the version of grub then a lot more erros can be seen

19:20 <Glanzmann> janrinze: THank you for clarifying.

19:20 <janrinze> found out a lot of stuff.. can almost setup everything manually now ;-)

19:20 <mps> `grub-install --target=arm64-efi --efi-directory=/boot/efi --removable`

19:21 <Glanzmann> janrinze: Perfect. That is how it should be. I thought about making a video explaining how to troubleshoot the different issues (manually upgrading the stub, reinstalling grub, exchanging u-boot, reinstalling the kernel, etc.)

19:22 <mps> janrinze: this are my scripts to install alpine with asahi kernel on usb

19:22 <jannau> from what I remember from the strings it was just the config, could be that grub needs the config to find its modules

19:23 <Glanzmann> janrinze: Debian live system is you friend. I like the Debian live cd so much, that I build an amd64 version of it (optionally with my desktop config). So I can turn any machine into my machine running from RAM in 60 - 120 seconds. I use that everytime I need a live system as well as when delivering trainings in training centers.

19:24 <janrinze> jannau: there's no way how grub would know where to load the modules but from the search paths

19:24 <janrinze> jannau: unless, like u-boot, it receives a config from the party that started grub.

19:26 <janrinze> it's quite a complicated tree of dependencies. I might just have scratched the surface..

19:27 <Glanzmann> janrinze: Yes it is and unconvient. But the future will be bright. :-)

19:32 <janrinze> Glanzmann: a port of UEFI bootloader could befeasible for M1?

19:34 <j`ey> janrinze: u-boot is already UEFI

19:34 <Glanzmann> u-boot is out uefi boot loader.

19:34 <Glanzmann> our*

19:34 <janrinze> Glanzmann: then u-boot can start windows 11?

19:35 <j`ey> no because windows 11 doesnt support m2

19:35 <j`ey> *m1

19:35 <Glanzmann> janrinze: Yes, but not on apple silicon: git reset --hard asahi-v2022.10-1; git clean -f -x -d &> /dev/null

19:35 <Glanzmann> https://superuser.com/questions/1683814/loading-windows-os-using-mainline-u-boot-bootloader

19:37 <janrinze> j`ey: Aarch64 Win11 runs in QEMU on OSX M1 with cpu=native setting.

19:38 <Glanzmann> janrinze: The issue is that Windows 11 does not have any device drivers for apple silicon.

19:38 <janrinze> j`ey: probably QEMU uses some traps to keep everything running smooth

19:38 <j`ey> exactly

19:38 <janrinze> Glanzmann: that's the UEFI for

19:38 <janrinze> Glanzmann: sort of a HAL for the OS

19:38 <Glanzmann> janrinze: No, it isn't.

19:40 <j`ey> also qemu emulates normal peripherals, doesnt use the M1 hw

19:40 <janrinze> Glanzmann: the default 'devices' in QEMU are PC like devices?

19:41 <sven> qemu emulates a common arm64 machine and not whatever apple made up for the m1

19:42 <sven> you can’t run the normal apple silicon macOS inside there either

21:03 <janrinze> I've noticed a small performance increase with the latest kernels .. or am i imagining things? ;-)