00:00 <n3ph> I got it! I was simply missing `usbmuxd`.. I always miss ount on it

00:00 <n3ph> *out

00:00 <n3ph> At least 13.6 is restoring now.

00:01 <n3ph> After this has been finished, I am going to test again if I can pump 15.2 straight into it

00:02 <n3ph> Regarding MacOS space, I wasn't thinking about using it anymore, so that's why I wasn't caring much about leaving space available

00:03 <n3ph> Maybe the installer could use some tweaks, preventing users from choking Mac OS, so upgrades keep working..

00:04 <n3ph> shrinking, btrfs, LUKS, partitions, moving to the back, growing APFS2 volumes... I can't get over it 😭

00:06 <chadmed> the problem is that macos updates keep growing and vary depending on how major the update is

00:07 <chadmed> sequoia downloaded like 18gb and then extraced to like triple that. i had to delete cs2 for it to update

00:07 <chadmed> and especially on 256gb machines its not really practical to be like "sorry leave 60% of your device to macos just in case you want to update it again"

00:07 <chadmed> the 256gb models need to just go away

00:08 <n3ph> True, but the scenario I went into is so heart breaking, I can't really tell how much I regret ATM

00:08 <n3ph> jeah, 256 is really not enough.. as well as 8gb ram

00:11 <n3ph> I remember discussions about out-of-band FW upgrades. Was this a hallucination?

00:12 <tpw_rules> it would be nice but it hasn't materialized yet. i haven't looked into what would be necessary in a while

00:13 <chadmed> at a minimum it will almost certainly require SEP

00:18 <jannau> n3ph: when did you install? I think the current installer is quite conservative about the amount of space it leaves for macos (something around 60 - 70 GB for a fresh macos)

00:19 <n3ph> jannau: looong ago, and I did choke it intentionally...

00:19 <n3ph> I just haven't thought of upgrades

00:24 <janrinze> chadmed: with those iso files the idea is that you can just boot from it and install? (awesome!)

00:24 <chadmed> janrinze: yup, just dd it onto a usb stick and boot it from u-boot

00:25 <n3ph> .. which means, you'll need a UEFI-only install already..

00:25 <chadmed> soonish the official gentoo arm64 install media will support apple silicon but as i said above theres still a couple of things to tie up before that can happen

00:25 <janrinze> yeah.. i see. Okay, was just dreaming ;-)

00:26 <chadmed> iboot simply does not support arbitrary usb boot. there will never be a way around needing the uefi-only install

00:26 <janrinze> But.. UEFI-only install could be very interesting to try out various distro's

00:27 <chadmed> well it installs everything up to u-boot and optionally lets you reserve some free space for your future rootfs

00:27 <janrinze> So: if I do UEFI-only install then It would be possible to boot an ISO for either a live OS on ISO or an installer on ISO.

00:27 <chadmed> it is intended specifically for allowing you to boot/install any distro that supports ebbr

00:28 <chadmed> yep, so long as it has the asahi infrastructure baked in

00:28 <chadmed> (kernel/initramfs, asahi-scripts, etc)

00:28 <janrinze> i don't know ebbr, Google said it's Brussels Airport :-D

00:28 <chadmed> arm reusing icao codes :p

00:28 <chadmed> its arm's embedded boot flow spec

00:29 <janrinze> Ah.. ARM has upgraded to four-letter acronyms

00:29 <chadmed> basically a lowest common denominator set of specs required to boot arm64. in a nutshell its basically just "your board must have a devicetree and uefi via u-boot"

00:30 <janrinze> Ah.. sounds great. Same as my chromebook.

00:30 <chadmed> theres a more full-fat version that mandates smbios/acpi and a bunch of other useless crap for servers but we dont care about that

00:31 <chadmed> but it gives OS/distro developers a common target for the platform and goes a decent way to solving one of the major problems with arm64 compared to wintel which is that you cant just shove a random boot disk in and expect it to boot exactly the same way on every machine

00:31 <janrinze> Hope more vendors will implement it. Then ports to those new devices will be much quicker.

00:31 <chadmed> most vendors do, but it wont help with porting speed. thats all drivers

00:32 <janrinze> chadmed: I have not yet seen a 'universal' ARM kernel. But we might get there with such boot load standards

00:33 <janrinze> chadmed: UEFI should give access to basic I/O and screen. (if implemented correctly)

00:34 <n3ph> Maybe that's a dumb question, but is there something similar to https://github.com/AsahiLinux/macvdmtool which works on linux?

00:34 <janrinze> chadmed: thanks for making the iso available!

00:34 <n3ph> I hate this procedure of getting into DFU while breaking your fingers. And: I can't reproduce it reliably, _again_

00:35 <chadmed> have you tried libidevicerestore

00:36 <n3ph> I am using it for pumping the ipsw file it the target

00:38 <n3ph> But I need to get the target into DFU mode first, which I fail for most of the times

00:43 <n3ph> If I make use of `--pwn` I can get it into recovery mode, but `idevicerestore` fails to send IBEC then.. It never worked for me that way.

01:00 <n3ph> Wow, after the 50th attempt.. I would really like to know how people do this reliably..

01:31 <n3ph> chadmed: So `min` is 38GB ATM... https://github.com/AsahiLinux/asahi-installer/blob/main/src/main.py#L14