00:53 <cy8aer> jannau: ok now I tried the direct booting from u-boot. It looks fine until "booti": Wrong Ramdisk Image format. Ramdisk image is corrupt or invalid. Are there different Ramdisk formats around u-boot cannot handle? This is a "standard" initrd from a debian dist.

00:53 <cy8aer> And now it is too late for me. I try it tomorrow again.

04:08 <BenTheTechGuy> I think this U-Boot was only built with support for gz and xz compression, so make sure your initrd isn't ZSTD compressed.

08:57 <cy8aer> BenTheTechGuy: hm, then it is no solution for me ☹️. Ok last chance is a live stick. But my stick does not start up and I guess this is the dtb problem. I use the https://tg.st/asahi-debian-live.tar and probably @Glanzmann does not build it every time a new kernel occurs. And then I have an older kernel not working with the actual m1n1/dtb combination.

09:01 <cy8aer> ... And I actual do not have the ressources to builld it on my own.

09:03 <cy8aer> And when this does not work I am completely stranded, because I would need the live stick for re-installation too because I only use crypted systems on my laptop and this does not work with the debian image of the standard installation image provided by the installer.

09:03 <mps> cy8aer: here is short guide and url to bootable usb https://arvanta.net/alpine/install-alpine-m1/

09:04 <mps> maybe you can use it to fix your installation

09:04 <mps> or take ideas from it

09:06 <cy8aer> mps: Thank you. This is a solution if my live stick does not work. I for myself only need a running linux system to rescue. And an alpine system will do too. Do you know if this stick starts up with the actual m1n1/dtb combination?

09:07 <cy8aer> Because that is what I have: a efi partition with the latest m1n1

09:07 <mps> I think so though didn't tested it in last month

09:08 <mps> I could build new one later today

09:08 <cy8aer> That should be an environment >= kernel 6.4.0-5 or so.

09:10 <cy8aer> But please do not put too much work in it.

09:10 <_jannau__> to make this work any "live" image should ship a boot.bin with matching dtbs which can be temporarily used for booting the live image

09:11 <_jannau__> cy8aer: if you can edit the command line of the non-booting debian live image, try adding "nomodeset"

09:11 <mps> cy8aer: it is script and don't require much work, just ./create-m1-img.sh

09:13 <cy8aer> _jannau__: yes that is a problem I found just with my crash. Recovery is a mess for someone with not too many skills. Ok, "nomodeset" reads like that the dtbs are needed for the frame buffer stuff only? Interesting.

09:14 <mps> cy8aer: just uploaded new image with latest asahi kernel, still didn't tested does it boots, hope will test it in hour or two

09:15 <_jannau__> there was a dtb change for the display device nodes which could explain boot problems. It should be avoidable by not loading the dcp driver (which nomodeset does, if the kernel is not very old)

09:16 <cy8aer> mps: Yes for me this will work, no problem but I am talking about people who crash their system like that and do not know anything about the mechanisms for booting up and try to recover. Thank you for the image. I will try that too (but please stay tuned, need to do some "real work" first 😉 )

09:52 <cy8aer> looks like I am not alone with these problems... https://www.reddit.com/r/AsahiLinux/comments/164arlm/fedora_no_longer_booting/?rdt=42534

09:53 <cy8aer> (other os, other circumstances, but same effect)

09:57 <mps> I can't remember but some of u-boot versions had a problem to boot from usb. not sure is this fixed in latest verified release

11:18 <cy8aer> Looks like the version of installer 6.4.0 does have a problem. I am not able to boot any of the images.

11:19 <cy8aer> from usb.

11:20 <cy8aer> So now I am stuck.

11:26 <cy8aer> Which components of grub should be on the efi partition? I know that the "classical" grub has components inside the file system. Is this the same for efi? Because those grub fragments I have try to scan nvm 0:4 and crash then but then there is only grub rescue and not the full grub system. Because with the full grub I could boot again...

11:26 <cy8aer> Another question: If I have another system which is installed the same way and I "steal" the EFI partition from there: is there a chance to rescue the system then?

11:38 <mps> ah, yes. latest u-uboot have bug and can't boot from usb

11:38 <mps> just fixed it and it boots fine

11:39 <mps> here is a patch https://tpaste.us/kX81

11:41 <cy8aer> Ok somehow reassuring. But then I need to wait until the next installer version with the patch or for access tomy "twin" system for building a new boot.bin

19:15 <cy8aer> Hi there - back again. I needed to build the boot.bin offline on another (x86) machine with the patch of mps (thanks for that). The Glanzmann stick did not start the live image but - I had a full grub then. Booting twice, fighting with "grub-install" and everything is fine again.

19:16 <cy8aer> Thank you all for your help.

19:16 <mps> cy8aer: did you read #asahi-dev about booting usb with current u-boot

19:17 <mps> it could be booted by break u-boot and from cmdline type ` env set boot_efi_bootmgr ; run bootcmd_usb0`

19:17 <mps> I tested with current asahi u-boot without patch

19:19 <cy8aer> mps: no, I just used your patch. Hm, yes, same effect, less efford. But does not matter, I found a way.

19:19 <mps> so, no need to rebuild u-boot and install/updtad current boot.bin on ESP

19:19 <cy8aer> yes. simply disabling the new function in u-boot.

19:20 <cy8aer> Now I need my time to document the stuff...

19:20 <mps> (now I'm on the apple side view about EFI, don't like it)

19:21 <cy8aer> 😉

19:22 <mps> u-boot people works on something better

19:25 <cy8aer> The main point why I kicked my efi and the whole volume: I played around with the boot.bin and it did not work. Then I wanted to copy an old version on the apple side in the efi partition and accidently erased (!) my volume. Don't ask, I work with an ISO keyboard and wanted to find out the partition name of the efi partition and somehow it kicked the volume via diskutil (and I was already root) from the history. That was too late and too unfocused.

19:25 <mps> VPL - Verified Program Loader

19:26 <cy8aer> Some EFIs of the x86 machines are crazy too.

19:26 <cy8aer> (non-apple machines)

19:27 <cy8aer> Thinking about the secure boot stuff and switching it on with linux...

19:27 <mps> not advice but maybe it will be easier to simply reinstall

19:29 <cy8aer> would be, but it is my daily driver, I am not at home and restoring my stuff would take to long and I have a debian with a crypted file system - https://g3la.de/hedgedoc/buDIXGBuRzKMwUnYOpStuw - and for the reinstall a live image is needed too 😕

19:31 <cy8aer> This is a bit a chicken and egg problem.

19:31 <cy8aer> And when you can see your two partitions which still work...

19:32 <mps> maybe you can use qemu from macos to access your partitions

19:32 <cy8aer> And yes, do not play around when you not have all tools for recovery at your side.

19:32 <cy8aer> That works?

19:33 <mps> yes, it worked last time I tried

19:34 <mps> I was even tempted to create alpine image for help users to access linux partitions from macos

19:34 <cy8aer> I also thought about installing the standard asahi in space before my system - shrink macos a bit - and use this for rescuing. But I read about problems with two linuxes on one system.

19:35 <mps> but it can be done using live linux iso

19:35 <cy8aer> (before between macos and my partitions)

19:35 <cy8aer> yes

19:35 <cy8aer> but now everything is well and thanks again.

19:35 <mps> let me search backlog where I explained this

19:41 <mps> cy8aer: the 'trick' is to add something like ''-drive if=virtio,id=hd1,format=raw,file=/dev/disk0s6' to qemu cli

19:44 <mps> cy8aer: https://tpaste.us/O89d script I used to start qemu to access partitions from macos

19:44 <cy8aer> and macos loops that through? Wow

19:45 <mps> need to find time to document this and become famous ;)

19:46 <cy8aer> right so.

19:47 <cy8aer> (hm, sound german somehow)

19:47 <cy8aer> s/ound/ounds/g