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
chadmed has joined #asahi-alt
r0ni has joined #asahi-alt
ma2 has joined #asahi-alt
ma has quit [Ping timeout: 480 seconds]
jamespmo_ has joined #asahi-alt
jamespmorgan has quit [Ping timeout: 480 seconds]
mps_ has joined #asahi-alt
mps has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-alt
chadmed_ has quit [Remote host closed the connection]
<janrinze>
The boot entries 'Debian' and 'Asahi Linux' get mixed up. 'Asahi Linux' will boot Debian and the 'Debian' entry will hang with some 'Proxy' message.
<_jannau_>
janrinze: which partition does the debian install use now as /boot or /boot/efi
<janrinze>
the partition numbers have changed during the new install but the UUIDs still are correct
<_jannau_>
can you describe how you installed debian? did you resize you macos partition to create free space?
<janrinze>
yes I resized macos partition to create free space
<janrinze>
it looks like the boot entries are connected to the partition numbers instead of the partition UUIDs
<janrinze>
all old partitions are still there (same old UUIDs) and seem to be unchanged (content not changed)
<_jannau_>
m1n1 and u-boot should use the partition uuids but grub maight have problems with renumbered partitions
<_jannau_>
but that doesn't explain why asahi in the boot picker boots debian and the debian boot picker is broken
<janrinze>
let me check grub..
<tobhe>
if it is using a older u-boot version those used to just always pick the first ESP
<janrinze>
the older install has an old u-boot so that might explain why it picks up Debian
<janrinze>
So the Debian boot entry (from MacOS recovery) goes into proxy mode apparently.
tobhe_ has joined #asahi-alt
<janrinze>
anyone here running the latest Debian install?
tobhe has quit [Ping timeout: 480 seconds]
<_jannau_>
the asahi u-boot installs since the first alpha release use the esp uuid
<janrinze>
there is another strange hint.. kernel is Linux debian 6.0.0-rc5-asahi-00001-gc62bd3fe430f #1 SMP Sun Sep 18 18:07:57 CEST 2022 aarch64 GNU/Linux
<janrinze>
The Debian installer supposedly was updated nov. 23
<janrinze>
makes me wonder if the installer is at debit.
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
jamespmorgan has joined #asahi-alt
jamespmo_ has quit [Ping timeout: 480 seconds]
<janrinze>
lacking USB3 it is a huge undertaking to create a backup of the partitions.
<jannau>
a current kernel should have usb3
<janrinze>
yet another indication that something is off
<janrinze>
the old install has the UUID in the BOOTAA64.EFI appended. the new install does not have that. Is it still required?
janrinze has quit [Remote host closed the connection]
andi has joined #asahi-alt
andi is now known as Guest468
Guest468 is now known as ashi
<ashi>
Oh wow, drm-asahi finally not crashing on Air M2 since todays commits, yay.... now... mesatime
janrinze has joined #asahi-alt
<janrinze>
interestin observation: copying the old BOOTAA64.EFI of ARCHlinux to the boot/efi dir of Debian allows me to boot ARCHlinux from the Asahi Linux boot selection. this confirms that the Asahi Linux now points to the wrong partition.
<janrinze>
however the debian entry will hang at 'Running proxy'
<mps_>
janrinze: BOOTAA64.EFI embeds partition on which it searches for grub, usually. and I think debian has patched it work differently
<cy8aer>
> there is another strange hint.. kernel is Linux debian 6.0.0-rc5-asahi-00001-gc62bd3fe430f #1 SMP Sun Sep 18 18:07:57 CEST 2022 aarch64 GNU/Linux
<cy8aer>
@Glanzmann did not build the new kernels into a deb package. But m1-debian (https://git.zerfleddert.de/git/m1-debian) allows to compile the new kernel on your running debian "dcp.sh" and it will then installed.
<mps_>
janrinze: look at result of `strings /boot/efi/EFI/BOOT/BOOTAA64.EFI | grep gpt`
<cy8aer>
Multi linux dists is a art of it's own.
<janrinze>
it finds the correct grub and boots the correct kernel. which is a strange coincidence
<jannau>
janrinze: please post partition table with partition uuids and the output of `strings /proc/device-tree/chosen/asahi,efi-system-partition`
<cy8aer>
"fdisk /dev/nvme0n1" - press "p" (and "q" for quit)
<cy8aer>
are the partitions there listet in the right order?
<scardracs>
chadmed: I'm looking on your script... Can't you use the shell file provided by asahi linux? ':)
<janrinze>
Device Start End Sectors Size Type
<janrinze>
/dev/nvme0n1p1 6 128005 128000 500M Apple Silicon boot
<janrinze>
/dev/nvme0n1p2 128006 107549957 107421952 409.8G Apple APFS
<janrinze>
/dev/nvme0n1p4 108160262 108285445 125184 489M EFI System
<janrinze>
/dev/nvme0n1p3 107549958 108160261 610304 2.3G Apple APFS
<janrinze>
/dev/nvme0n1p5 108285446 122198277 13912832 53.1G Linux filesystem
<janrinze>
/dev/nvme0n1p6 122198278 122808581 610304 2.3G Apple APFS
<janrinze>
/dev/nvme0n1p7 122808582 122930693 122112 477M EFI System
<janrinze>
/dev/nvme0n1p8 122930694 152389893 29459200 112.4G Linux filesystem
<janrinze>
/dev/nvme0n1p9 152390144 242965550 90575407 345.5G Linux filesystem
<janrinze>
/dev/nvme0n1p10 242965551 244276259 1310709 5G Apple Silicon recovery
<jannau>
janrinze: please use a pastebin in the future
<janrinze>
jannau: sure, sorry about that.
<scardracs>
janrinze: you can use wgetpaste ;)
<janrinze>
I'm far too old-school ;-)
<cy8aer>
yeah looks good. There are situations where the order is mixed up and then the wrong partition can be selected. This is not the problem (and sorry for not warn about pasting)
<jannau>
janrinze: to which partition did you copy BOOTAA64.EFI ?
<janrinze>
it's now on /dev/nvme0n1p4
<janrinze>
when you see the start positions you can see that p4,p5 and p6 are the newer partitions created during Debian install
<jannau>
that suggests the partuuid selection in u-boot chainloaded from /dev/nvme0n1p7 doesn't work
<janrinze>
p7 is the EFI for ARCHLinux
<janrinze>
p4 is the EFI for Debian
<janrinze>
Debian needs to select p4 but ends up selecting p7. That probably explains why it can't find the firmware for USB3 because the old ARCH install does not have that firmware.
<janrinze>
my lazy solution would be to just copy everything from p4 to p7 and see if that solves the problem.
janrinze has quit [Remote host closed the connection]
<jannau>
has /dev/nvme0n1p4 or /dev/nvme0n1p7 a ubootefi.var file
janrinze has joined #asahi-alt
<janrinze>
setting up p7 with the files from p4 rendered an unbootable situation for both Debian and ARCHLinux.
<janrinze>
need to fix that first.
ashi has joined #asahi-alt
<ashi>
Wow, mesa works also, fully accelerated gnome on debian testing, yay :)
<ashi>
M2 Air
<scardracs>
janrinze: I'd suggest to restart from zero
<janrinze>
scardracs: yes, but preferably with a backup of my home partition (>200GB)
<janrinze>
which is why I hoped to have USB3 working ;-)
<jannau>
janrinze: is your asahi install up to date?
<janrinze>
jannau: nope.
<janrinze>
I'm going to make backups from OSX. Let's see how that goes :-)
<jannau>
do you known which kernel version it has?
<janrinze>
jannau: no idea, doesn't boot either anymore so backups first.
<jannau>
do you have enough free space for another small asahi install?
<janrinze>
sure
<janrinze>
can do that from OSX or 1TR?
<jannau>
both
ashi has quit [Quit: Leaving]
<janrinze>
jannau: I'd like to backup first though.
<jannau>
I think that would easiest option to repair your installs
<janrinze>
sounds good.
<janrinze>
doing dd in OSX to a fast USB3 drive. hope it doesn't take too long.
Glanzmann has joined #asahi-alt
<Glanzmann>
janrinze: So the Debian u-boot does not have the chosen.asahi,efi-system-partition patch. That means if you have multiple installations, the Debian will always pick the first efi partition.
<Glanzmann>
janrinze: The easiest way to recover, after you made backups of course, is that you delete the stub partition and recreate it using the asahi installer.
<janrinze>
Glanzmann: the second efi partion appears to be chosen. Perhaps it iterates through the partition table and choses the last found?
<Glanzmann>
Than you boot using debian live system and reinstall grub, m1n1 and a matchting kernel. And you're good to go.
<Glanzmann>
janrinze: IIRC it chooses the first efi partition.
<Glanzmann>
Anyhow, if you want I can build you a second stage m1n1 u-boot with the choosen patch not reverted and you can use that and than it does exactly what you want.
<janrinze>
neither debian nor ARCH boots at the moment. Backups running at 319MB/s :-)
<Glanzmann>
I choose not to use it because a lot of people installed Debian before the choosen efi partition patch was introduced and I would annoy them during the boot process, so I decided to back out the patch, same as OpenBSD.
<jannau>
Glanzmann: please post a large warning that the Debian installer is not suitable for installs with more than one other linux/*bsd installtion
<Glanzmann>
jannau: Or I just rebuild it with the choosen patch.
<Glanzmann>
jannau: OpenBSD does the same btw.
<jannau>
I don't think it's the problem here as the partition layout should avoid problems
<Glanzmann>
jannau: I don't understand. I tested the choosen patch immediately after you posted it and I tested it also with asahi installation and Debian installation.
<jannau>
looks more like asahi might had u-boot build which missed support for it
<Glanzmann>
jannau: Maybe we have two problems.
<jannau>
I don't think we did that but I have problems to explain the error in another way
<Glanzmann>
jannau: First one, Debian u-boot picks the first esp partition and newer versions of the Debian grub hard code the parition instead of the partuuid.
<jannau>
Glanzmann: I don't understand. does the u-boot installed by debian have the patch or not
<Glanzmann>
jannau: Nope, it does _not_ have the patch.
<Glanzmann>
So I use the asahi release tag and revert the specific patch.
<Glanzmann>
janrinze: Just to figure out what went wrong is the following correct: You installed Debian in July this year. You still have macos. Today you shrinked macos further to install the official asahi distribution?
<jannau>
not using the patch should only cause problems for that specific system if the system is not using the first efi system partition
<Glanzmann>
So your partition layout looks like <macos> <asahi> <debian>
<jannau>
no, first asahi and today debian
<Glanzmann>
jannau: Exactly.
<janrinze>
jannau: exactly.
<jannau>
partition layout is <macos> <debain> <asahi>
<Glanzmann>
jannau: Unless asahi harcodes the nvme partition in the grub config and does not use the nvme uuid.
<janrinze>
asahi actually chose the new EFI partition to boot from.
<Glanzmann>
jannau: I see but then I think what happens, is that when you boot asahi, it laods m1n1/u-boot from asahi and than stage1 grub tries to load stage2 grub from Debian and crashes.
<jannau>
the error description was asahi started debian and debian didn't work at all
<janrinze>
nope, Asahi would use Debian EFI and subsequently asahi EFI for u-boot etc.
<Glanzmann>
janrinze: Can't be.
<Glanzmann>
janrinze: I think what happens is m1n1(stage1) > m1n1(esp asahi) > u-boot (esp_asahi) > grub stage1 (asahi) > grub stage 2(Debian) big screwup.
<jannau>
I don't think we can now reconstruct error since both efi system partition are already manually changed
<janrinze>
well.. after the backups are finished ( not too long now ) we can investigate further.
<Glanzmann>
Yep.
<janrinze>
jannau: small changes that can be reverted.
<Glanzmann>
I would like to reproduce it but problem is that I'm in Kaiserslautern with only a lte+ internet connection.
<Glanzmann>
janrinze: But we get everything back. If the Debian is fresh, we can just kill it and than get the m1n1 of Asahi back and you should be good to go.
<janrinze>
Debian boot would hang in Proxy mode
<Glanzmann>
janrinze: Happens if it does not find m1n1 stage2.
<Glanzmann>
I really have to test it. I don't know when I'm back but latest Monday.
<Glanzmann>
janrinze: m1n1 stage1 has a the partition id of the esp for m1n1 stage 2.
<janrinze>
that would be visible as a string in the BOOTAA64.EFI ?
<jannau>
no, in the 1st stage m1n1
<janrinze>
where is the 1st stage m1n1?
<jannau>
or from the device tree in u-boot / linux
<Glanzmann>
jannau: I put a big fat warning.
<Glanzmann>
janrinze: 1st stage m1n1 is installed by the installer.
<janrinze>
so probably 1st stage m1n1 of debian is at fault here.
<Glanzmann>
janrinze: Can't be I stole it from the official asahi installer.
<Glanzmann>
It's not from me.
<janrinze>
1st stage m1n1 of Asahi Linux can be convinced to boot debian..
<Glanzmann>
janrinze: I'm actually using the official asahi installer from the asahi cdn ...
<Glanzmann>
I only provide my own configuration file.
<janrinze>
we're not looking to blame anyone here.. Hope you don't feel that way.
<Glanzmann>
I don't. I would like to know what is going on.
<Glanzmann>
And than fix it.
<janrinze>
makes two of us..
<Glanzmann>
janrinze: So my best guess is that by installing Debian the asahi installer loads the wrong grub stage2 and than goes boom.
<janrinze>
1st stage m1n1 of Debian can't boot Asahi Linux either,
<janrinze>
Glanzmann: yes, that seems to be the case
<Glanzmann>
janrinze: I did not install the official asahi for a long time. But if my theory is correct. Than you should find a grub.cfg which has a partition number hardcoded and not its uuid.
<jannau>
I think the 1st stage m1n1 from the debian installtion fails to chainload the 2nd stage m1n1
<jannau>
I suppose it prints that to the display
<Glanzmann>
jannau: But than this has to be a recent incompatibility between m1n1 stage1 asahi and m1n1 stage2 Debian.
<jannau>
janrinze: you can check "Finish Installation.app/Contents/Resources/boot.bin" on the asahi/debian apfs stub partitions (from macos or 1tr)
<janrinze>
jannau: it just uses the asahi linux u-boot and thus may cause issues with the newer kernel.
<janrinze>
jannau: at OSX a.t.m. so will check.
<janrinze>
jannau: which is the right stub partition? I have Asahi Linux - Data, Asahi Linux, Debian - Data, Debian
<jannau>
janrinze: can record a video from booting debian install. if you have a smartphone with slow motion camera? use that
<janrinze>
got a frame grabber, not sure if that would work..
<Glanzmann>
jannau: Could you please run on an asahi install the following commands and paste the output: find /boot -name \*.cfg; strings /boot/efi/EFI/BOOT/BOOTAA64.EFI | grep gpt
<Glanzmann>
jannau: Should be fast enough.
<Glanzmann>
janrinze: ^
<janrinze>
jannau: found the boot.bin in the stubs
<Glanzmann>
jannau: The last line could be an indicator for the issue we're seeing. On the other hand the second from last looks like that it used the partuiid.
<janrinze>
two lines is okay for not using pastebin, right?
<Glanzmann>
yep.
<janrinze>
seems to be the correct Debian EFI partition..
<Glanzmann>
janrinze: Yes, but u-boot in Debian ignores it, so no dice.
<Glanzmann>
It will use the first esp partition that it finds, which in you case should be the right one.
<Glanzmann>
janrinze: After the Debian install, what did you modify?
jamespmo_ has joined #asahi-alt
<janrinze>
password, users added, home directory mount point to have the old home available. then a reboot and if failed to boot
<Glanzmann>
janrinze: So you installed Debian, Debian rebooted once by itself. Than you were able to log in. And than you rebooted after adding a mountpoint and it stopped working?
<Glanzmann>
Because after the first boot it does not touch grub anymore. Strange. And when you boot Debian currently, what happens?
<janrinze>
yup.. second boot failed.
<janrinze>
I don't think grub is the cause.
<janrinze>
It never reaches grub..
<Glanzmann>
janrinze: Have you tried making the debian usb stick?
<Glanzmann>
And booting from that?
<Glanzmann>
janrinze: So what does the Debian boot reach? m1n1 stage 1, m1n1 stage 2, u-boot?
<janrinze>
which ever one that is waiting at the Proxy mode.
jamespmorgan has quit [Ping timeout: 480 seconds]
<Glanzmann>
janrinze: That would be stage1. But that does not make much sense to me.
<Glanzmann>
janrinze: I can reproduce it when I'm back home.
<Glanzmann>
janrinze: Probably the best plan of action, unless jannau has a better idea, is to wipe both asahi and debian. Than reinstall your distribution of choice and restore from the backups.
<Glanzmann>
janrinze: Of course you could also manually install m1n1 stage1, if you want to try that. But I don't understand why after the second boot it can't find m1n1 anymore.
<Glanzmann>
Because if you booted twice into Debian than it does not make sense to me.
<Glanzmann>
Unless of couse you deleted /boot/efi/m1n1/boot.bin
<Glanzmann>
But you say it is there, isn't it?
<janrinze>
I have restored both EFI partitions to their old state. Yes they are there.
<janrinze>
after restoration the Asahi Linux boot entry in 1TR boots.. Debian.
<janrinze>
the Debian kernel reports from strings /proc/device-tree/chosen/asahi,efi-system-partition the EFI partition of Asahi Linux.
<Glanzmann>
janrinze: That would support my theory stage stage1-asahi-grub loads stage2-debian-grub.
<janrinze>
is it possible that the Debian 1st stage m1n1 is using UUID instead of PARTUUID?
<Glanzmann>
Because of the hardcoded parition.s
<Glanzmann>
janrinze: No, because I use the asahi installer from the asahi cdn.
<Glanzmann>
That means, that when marcan updates the installer, the debian installer is using that updated installer from the asahi cdn.
<janrinze>
Current situation : can boot into Debian with the Asahi 1TR choice.
<janrinze>
i can try to use the debian 1TR choice again.
<Glanzmann>
One moment.
<Glanzmann>
janrinze: Can you please paste the output of 'blkid' as root?
<Glanzmann>
jannau: I assue you install multiple 'asahis' all the time. You probably never saw that one asahi picks up the grub of another asahi?
<janrinze>
nope.. only one time install.. rebuilt a lot of kernels though
<janrinze>
this is the first time i install a secondary Linux. Chose to have debian.
<Glanzmann>
janrinze: No, but I want to know from __jannau__ is, if he has ever seen one asahi grub-stage1 booting the grub-stage2 from another asahi. Because jannau tests a lot of releases and probably has often install multiple asahis at the same time on one machine.
<Glanzmann>
janrinze: Can you please paste the 'blkid' output?
<janrinze>
will use pastebin..
<janrinze>
duh.. no network now on the debian machine.
<Glanzmann>
janrinze: wrong device tree.
<Glanzmann>
janrinze: Whcih interfaces do oyu see: ip -br link show
<janrinze>
yup.
<Glanzmann>
janrinze: You can write the output to the esp parition and grab it from osx.
<Glanzmann>
janrinze: I'll try to reproduce your issue next week and report back if I was successfull.
<Glanzmann>
janrinze: You're running the asahi desktop variant, I assume?
<janrinze>
yes.. that works. rebooting and selecting a different boot takes up quite some time..
<janrinze>
Glanzmann: currently running debian
<janrinze>
Glanzmann: only lo and wlp1s0f0 with ip -br link
<Glanzmann>
But that is fine.
<Glanzmann>
That means you have wlan.
<Glanzmann>
You just need edit /etc/wpa_supplicant/wpa_supplicant.conf
<Glanzmann>
and do a ifdown wlp1s0f0;ifup wlp1s0f0
<Glanzmann>
janrinze: Did you now try the Debian boot entry or are you still using the asahi?
<janrinze>
asahi. I can try the debian agian.
<Glanzmann>
The result will probably the same as before.
<Glanzmann>
Anyway, how do you want to proceed?
<Glanzmann>
Because it is getting late here and I'm way beyond bedtie.
<janrinze>
same here.
<Glanzmann>
janrinze: Probably, back up your data again.
<Glanzmann>
Than wipe linux of the system and install the distribution to go forward.
<janrinze>
I think deleting all partions except for the home partition and reinstalling Debian would be a good try.
<Glanzmann>
I'll try to reproduce the issue as soon as I have decent internet connection. This will probably be next week. Depeneding on how much more time I spend in Kaiserslautern.
<Glanzmann>
janrinze: I would wipe everything.
<Glanzmann>
But of course not without taking a backup first. But yes, keeping the home partition should work.
<janrinze>
Glanzmann: all is backed-up.
<janrinze>
i'll have a look at how to clean up everything.
<Glanzmann>
janrinze: My current working theory is, that Debian u-boot always boots the first esp parition and asahi grub hardcodes paritions after a grub update, which becomes a problem if the paritions a reassigned, but maybe I'm wrong.
<Glanzmann>
That theory does not explain why your Debian installation does not boot.
<Glanzmann>
janrinze: There is a script.
<Glanzmann>
But backup your linux stuff before and discconect the backup drives.
<Glanzmann>
janrinze: I'll reproduce the issue next ween and report back here. If you want you can drop me an email at thomas@glanzmann.de
<Glanzmann>
And than I'll also write you an email with my findings.
<janrinze>
thanks. have a good nights rest.
<Glanzmann>
you, too.
Glanzmann has quit [Quit: n8]
<janrinze>
the file you linked is smaller than the size in pastebin, the size is 1800901 (same as the old boot.bin) and your pastebin says 1954667. so i think you uploaded the wrong file.