<kode54>
kettenis: Ubuntu provides Desktop iso for arm64 too, with a live environment and graphical installer
<kode54>
the 21.xx series even have Plymouth already enabled, not sure about 20.04
<kode54>
the 20.04.2 preinstalled hard drive image that Parallels provides for download has Plymouth disabled and also does verbose boot, so huge text scroller spill on every boot and shutdown/reboot
<_alice>
I think it'd be a good idea to make the u-boot EFI environment similar enough that existing SystemReady ISOs can boot with a device tree (instead of ACPI)
<_alice>
it'd be the path of least friction for adopting a standard-ish way to install Linux that would also be user-friendly for people coming from x86 PCs
<marcan>
sven: I think so, yeah
<marcan>
I think it's by design...
<marcan>
dottedmag: the installer won't be setting up LUKS for you
<marcan>
I'm interested in secureboot/FDE-by-default stuff, but that at the very least needs to wait until we figure out the SEP properly
<marcan>
_alice: that is the plan
<marcan>
that's why we're using u-boot EFI
<marcan>
it should work for anything supporting device tree
kov has quit [Quit: Coyote finally caught me]
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
rkt has left #asahi-dev [#asahi-dev]
rkt has joined #asahi-dev
<agraf>
marcan: So, what if you're just treating the distro disk image as what it is: A container with partitions and some meta information
<agraf>
marcan: Your installer would do the following:
<agraf>
1) Shrink system macOS APFS container
<agraf>
2) Inject 2nd OS (Linux) APFS container right after
<agraf>
3) Copy all partitions from the disk image after that 2nd OS APFS container
<agraf>
5) Copy U-Boot / edk2 into 2nd OS APFS container as kernel
<marcan>
we're not using edk2 :p
<agraf>
For step 3: It would copy contents as well as PARTUUID and GUID of these partitions of course
<agraf>
Yes, not today :)
<marcan>
lol
<agraf>
You'd also want to make sure that U-Boot searches the ESP per GUID rather than hardcoded "first partition" - not sure that's there yet
<marcan>
so the other thing is we need to resize the data partition to the user specified size
<marcan>
we'll deal with u-boot, that's not a problem
<agraf>
"resize the data partition": The already existing one?
<marcan>
but the issue with copying the PARTUUID/GUID as-is is that it breaks with dual-boot, and gets really confusing if you have external disks with installs too
<marcan>
I mean whatever the distro rootfs partition is
<marcan>
though I think for images like this usually there would be a startup script to do it on first boot
<agraf>
Yes, that's part of the distro's responsibility
<marcan>
anyway, I'm generally on board with the general flow, which isn't much different from my idea except I was thinking that instead of a disk image I'd use some json/whatever description of the partitions and individual files
<agraf>
I don't know if local dual-boot is all that terribly important. It makes everything a lot more complicated
<marcan>
but that's an implementation detail
<marcan>
local dual-boot is important
<agraf>
Distros today all have existing dd'able images for ARM SBCs
<marcan>
but yeah, I don't like hardcoded UUIDs
<marcan>
that just sets users up for trouble in the future
<marcan>
yes, and those are SBCs, not real computers
<agraf>
I think it'd be easiest / best to stick to that as closely as possible
<sven>
marcan: ok. i was asking because i'm about to submit apple,dwc3 bindings and was wondering if i should also add "t6000-dwc3", "t8103-dwc", "snps,dwc3" instead of just "t8103-dwc", "snps,dwc3"
<marcan>
people are going to want to use these things a lot more than they use SBCs, and we also need to assume less experienced users will be more common ;)
<marcan>
sven: yeah, go ahead and add t6k
<sven>
k
<marcan>
agraf: for dd-able images you can just forgo UUIDs and use device paths or whatever; that's typical on SBCs but won't work for us
<agraf>
"yes, and those are SBCs, not real computers" -> That's a very difficult argumentation line :). Modern SBCs are easily in the same performance ballpark as "real computers" a few years ago. And their user base isn't necessarily more or less sophisticated either
<agraf>
marcan: Yes, but that's just part of the things you tell distros as part of your contract
<agraf>
marcan: You can tell them "Always rely on UUIDs"
<marcan>
sure, but once you use UUIDs now the device is unknown and conflicts are global
<marcan>
I would much, much prefer to have proper unique UUIDs
<agraf>
marcan: Maybe you also add an additional piece that says "You have to regenerate the UUID on first boot" to solve dual-boot
<marcan>
cloning UUIDs is a terrible idea
<marcan>
yeah, *that* could work :)
<agraf>
marcan: UUIDs are intrinsically in distros' turf. You don't want to even remotely know about them, otherwise you pull yourself too deeply into the details of how the distros build their images :(
<agraf>
marcan: and that means you limit their ability to change things. What if I want to build a btrfs based image tomorrow? Or one with 5 partitions?
<marcan>
sure
<marcan>
anyway, I would at least randomize the PARTUUIDs (or rather: diskutil will do that for me anyway)
<agraf>
marcan: I think that works, but it means you'll need to also document it as part of the installer/distro contract :)
<agraf>
marcan: to make sure nobody relies on static PARTUUIDs
<agraf>
marcan: I know of 1 compelling argument for PARTUUID: They work for finding a roofs without initramfs
<marcan>
yes
<marcan>
I've used them for that
<marcan>
but I don't want distros editing the GPT on first boot
<marcan>
and I don't want static PARTUUIDs either
<agraf>
But again, start with "easy to work with for distros" and "extensible later if necessary" :)
<agraf>
I think you'll have distros editing the GPT on first boot by default for expanding the date partition, no?
<marcan>
nah, all they have to do is resize2fs
<agraf>
data*
<marcan>
the actual partition would be created as full size already by the installer
<marcan>
(replace resize2fs with the appropriate dance for the fs/volume management in use)
<marcan>
this is actually important to do in the installer, because users need to be able to choose how much space to allocate to linux and how much space to leave unallocated for whatever reason
<agraf>
Ok, another thing to make sure you document properly. I don't know if all first boot scripts will growfs if they don't also resize
<marcan>
think e.g. planning to install a second distro
<agraf>
How important is "leave unallocated space" really? :)
<marcan>
it's important for me :p
<marcan>
resizing things down later to make space for more stuff is more of a pain
<agraf>
Heh, ok :)
<agraf>
I believe most distros will assume that "free space at the end" means "space I can use to grow into"
<agraf>
(which is probably accurate for 99% of users out there)
<agraf>
Anyhow, IMHO best would be to build a workflow around the already existing ARM SBC images - even if you don't actually dd them over. Then document a few requirements you put onto that image to be Asahi compatible.
<agraf>
That way you also pave a very natural path into passing ownership of almost everything to distros. You wouldn't be in the business of owning the kernel for example.
<chadmed>
imo the problem with going with the disk image route is that you break the workstation paradigm that desktop users are used to and have been dealing with for... well, decades at this point.
<chadmed>
users of workstations want to exercise a modicum of control over their disks and how the OS uses them, they dont want some image to just grow itself into all their free space on the first boot like so many ARM images do
<agraf>
chadmed: that flow is something that distros will then need to enable themselves. If a distro really wants to provide all of that flexibility, give them the tools to provide their own installer that gives you all these knobs
<chadmed>
i think for the immediate term the best course of action is something gentoo-like, where the distro's responsibility begins with extracting a tarball of their rootfs, and it is an exercise for the user/asahi installer to prepare the disk according to their design. then, beyond that, as kettenis suggests, having compatibility with ARM SR images
<agraf>
chadmed: but we're talking about bootstrapping an ecosystem here for the "easy" route.
<chadmed>
which most big distros provide anyway
<chadmed>
most arm forks of major distros already support the tarball rootfs method, and its simple enough to even integrate into the asahi installer if we so choose. and given that all our patches find their way upstream, we dont even need to take ownership of the kernel.
<agraf>
chadmed: no, rootfs doesn't give you distro ownership of kernel and UEFI payload (grub) for example - very bad idea
<chadmed>
it absolutely does when theyre configured properly. my raspberry pi runs artix, which i simply extracted a rootfs for and installed their kernel package once booted. as i said, the initial boot/handoff to the distro can be very easily automated through the asahi installer since all we will be presenting to users is m1n1+u-boot's efi
<chadmed>
plus, again, the end game should be ARM SystemReady images via uefi. it's what desktop users have come to expect from their machines. i think it is extremely poor form to equivocate the SBC experience with the desktop. performance aside, the platforms are absolutely nothing alike
<agraf>
chadmed: But that's the whole point - the above uses ARM SR images and mangles them into an Apple compatible environment
<agraf>
chadmed: Again, if you want anything more sophisticated than "take an image and throw it onto the system", you're in the land of "distro provides its own installer"
<agraf>
And that's absolutely a useful goal to have, I just don't know if it should be step 1 ;)
<chadmed>
well yeah thats my point of contention i think. the SR image should boot to a live medium a la PC, and users configure and install more advanced options via e.g. Anaconda as they would on any amd64 desktop
<chadmed>
rather than have the image directly dumped into their target partition
<marcan>
agraf: one issue is that I want to be able to stream images directly to the target disk, but I already built myself a seekable/cached fd view over HTTP for the ipsw in the installer... so that will work nicely for that use case too
<agraf>
chadmed: I don't think that's really possible. The installer flow on Apple Silicon would most likely be a macOS application that then runs/mimicks the distro installer
<chadmed>
but again, thats very endgame-y, and personally i think for the kinds of people who are interested in this in the immediate to near term future will be more than happy with "we give you m1n1+u-boot+an empty partition, configuring the rootfs is an exercise for the reader"
<marcan>
agraf: also we don't intend to own the kernel at all; if you want to be on our installer list you'd better be building kernels from usable trees for those images
<marcan>
for Arch I will take care of that myself, as the reference distro
<agraf>
marcan: perfect :)
<chadmed>
agraf: why? we have already established that u-boot can boot live media once it's been handed off to by iboot, so with that functionality in mind eventually the install process (beyond the intial setup of m1n1+uboot) will look virtually identical to how theyd set up an amd64 workstation right now
<agraf>
marcan: My point was that you don't want to dictate any of the post-UEFI-App flow. If a distro wants to use systemd-boot, they should be able to. If they want to patch grub with awkward config options, they should be able to
<marcan>
yes, we won't provide grub either
<agraf>
chadmed: because you need all the macOS system partition setup magic, no? How would you deal with that?
<marcan>
that's *why* we're using the whole u-boot/efi thing
<chadmed>
marcan's already written a script that deals with that, thats what i mean when i say "asahi installer"
<chadmed>
it sets up the boot policy and m1n1 right now, but of course can be easily rejigged to install a m1n1+uboot image, its a shell script after all
<marcan>
python script
<agraf>
That's something that would work with the flow above as well (modulo all the hazard that goes along with running the actual installer because it may not be fully aware that it needs to preserve the partition layout). Just use the "installer iso" (which also has an ESP and normal partitions) instead of the "SBC image" as target image.
<agraf>
It definitely isn't the "easy" route for not-heavily-sophisticated users though. That's more likely to be the SBC image.
<chadmed>
in terms of presenting a skeuomorph of a PC, its probably best though. its a happy medium that has worked for 20+ years in terms of ease-of-use vs flexibility
<chadmed>
i consider myself a pretty advanced computer user, and despite this the first time i was confronted with installing an OS on to an ARM system in the method you describe, i found myself confused and incensed that it did not like a PC, despite it being ostensibly "easier"
aleasto has joined #asahi-dev
psykose has quit [Read error: No route to host]
psykose has joined #asahi-dev
rkt is now known as Guest4991
rkt_ has joined #asahi-dev
rkt_ is now known as rkt
Guest4991 has quit [Ping timeout: 480 seconds]
<kettenis>
agraf: we did teach the OpenBSD installer to preserve the essential Apple partitions
<j_ey>
sven: what's the difference between the 'select' and 'properties' in apple,dwc3.yaml?
<j_ey>
sven: select has t8xx only, not sure if thats intentional
<kettenis>
but now that's done, the only thing that's needed is to have m1n1 with a u-boot payload and some free space
<kettenis>
and the installation experience is really not different from an x86 machine with UEFI
<kettenis>
dual booting macOS will work just fine
<sven>
j_ey: select makes sure that apple,dwc3 gets precedence over snps.dwc3.yaml as soon as the compatible contains t8103-... (which the t6k one will contain as well)
<j_ey>
sven: got it
<kettenis>
sven: I don't think the t6000 dwc3 should have t8103 as a compatible
<sven>
kettenis: that's what apple's device tree does and according to marcan t6k has the same reset quirk as t8103
<sven>
so t6000 would be "t6000-dwc3", "t8103-dwc", "snps,dwc3" then
<kettenis>
I guess you'd still be able to quirk t6000 and t8103 separately in that case
<kettenis>
so in that sense it is ok
<sven>
i'm also fine with "t6000-dwc3", "snps,dwc3" but then we'd need to already quirk both t8103 and t6000 with the same thing
<kettenis>
so there are two cases to consider:
<kettenis>
a) running a new kernel with an older DT
<kettenis>
b) running an older kernel with a newer DT
<kettenis>
suppose we find a new quirk that only applies to t8103 but breaks the t6000
<kettenis>
if we list both t6000 and t8103 as compatible for the t6000 we can support the quirk easily and only apply it to t6000
<kettenis>
but if we then remove the t8103 compatible from the DT for the t6000, an older kernel would no longer work properly with the new DT
<kettenis>
so if we already know that t6000 needs the same reset quirk as the t8103 it is probably best to make that explicit
<kettenis>
or maybe we should have an apple,dwc3 compatible after all
<kettenis>
(I know I argued against it earlier)
<sven>
true, we could enable the reset quirk for "apple,dwc3" then. we'd need a "apple,dwc3-v2" or something like that though if they ever fix that behavior in the future
<kettenis>
on the other hand, the machine is usable with only the snps,dwc3 matching, so maybe that is good enough
<kettenis>
scenario b) is really there such that people can upgrade their kernel after updating m1n1 and the device tree
<agraf>
kettenis: That works too, you'd basically end up with single-distro as well though, because of lack of UEFI variables :). I'm happy with that as well. Just not terribly thrilled about an installer poking at file systems that are not provided by itself (ESP) :)
<amw>
sven: Dumb question: I'm trying to get USB keyboard with your usb-reset/v2 + https://paste.debian.net/1218312 patch but I get the USB probe failing with missing memory resource?
<sven>
The nodes are wrong. You want the same usb nodes as before but a different compatible. You also don’t need that branch unless you also setup i2c, usb pd and the connection to dwc3
<amw>
ok - so need lots of other DT nodes and stuff to go before usable tree in the kernel
<sven>
this only makes hot plugging works fwiw
<amw>
ok - saw usb and got excited :-(
<sven>
usb already works
<amw>
not if you don't have it in the dts ...?
<sven>
you just need to add dwc3 nodes to the DT. i'll eventually submit those upstream as well but we'll need to get the apple,dwc3 binding figured out first
<amw>
Can we at least put a dwc3 node in the m1n1 dts area?
<amw>
Another question is there a seperate dts for macbook vs mini ?
<j_ey>
eventually
<sven>
m1n1/dts imho should only track whatever is upstream
<amw>
So where does the experimental / proposed stuff go if not in m1n1 for debugging/testing?
<j_ey>
random branches :p
<chadmed>
mu-one is probably the best staging ground we have right now for staging experimental stuff, right?
<chadmed>
its the most "complete" rn
<amw>
chadmed: That does seem to have a *very* complete DT - thanks
<amw>
chadmed: It still doesn't see my USB keyboard or USB drive :-(
<chadmed>
usb seems to be working for most other folks
<amw>
My m1n1 booting line is: python3.9 proxyclient/tools/linux.py -b 'earlycon console=tty0 console=tty0 debug net.ifnames=0 rw root=/dev/sda1 rootdelay=5 rootfstype=ext4' Image-mu-one.gz t8103-j274-mu-one.dtb
<amw>
chadmed: I'm sure it's something dumb - but it's time for sleep so I'll look tomorrow. But anything obvious jumps to mind just tap it in
<amw>
I'll look at it tomorrow - thanks - night.
<chadmed>
im pretty sure nvme isnt meant to work yet?
<sven>
nvme works with my downstream patches. they just need to be cleaned up before sent upstream
<chadmed>
ah yeah i see. its just not finding sda1 and dumping the list of nvme partitions. i assume its a kernel config problem since usb2 should work regardless
kettenis has quit [Quit: Lost terminal]
yuyichao has quit [Ping timeout: 480 seconds]
X-Scale` has joined #asahi-dev
yuyichao has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
[X-Scale] has joined #asahi-dev
kettenis has joined #asahi-dev
<kettenis>
agraf: yes, the lack of runtime access to UEFI variables does stand in the way of supporting multi-booting non-macOS OSes
X-Scale` has quit [Ping timeout: 480 seconds]
<kettenis>
maybe we can do something clever there for these systems
<kettenis>
it should be possible to isolate nvram access from the OS in a fairly reliable way on this hardware
<kettenis>
not sure if there is space in nvram for us to scribble in though
yuyichao_ has joined #asahi-dev
richbridger has quit [Remote host closed the connection]
richbridger has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
dsrt^ has quit [Ping timeout: 480 seconds]
<agraf>
kettenis: yeah, or maybe find something completely separate for us to store varstore data in the SEP. The only downside to that would be that you'd lose SEP access from Linux (because it's owned by UEFI RTS then), but that's probably something perfectly ok for most people
[X-Scale] is now known as X-Scale
<sven>
i don't think SEP has any key-value store. it might be possible to abuse something else but i haven't seen anything so far
<sven>
(you'll also need APFS support to fully boot SEPOS but i guess that can be worked around)
<sven>
and at least I want to store my ssh/gpg keys in there but i think my use case doesn't align with what most people want to use it for ;)
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
timokrgr6 has joined #asahi-dev
timokrgr has quit [Ping timeout: 480 seconds]
timokrgr6 is now known as timokrgr
jix_ has joined #asahi-dev
jix has quit [Ping timeout: 480 seconds]
dsrt^ has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
dottedmag has quit [Quit: QUIT]
yrlf2 has joined #asahi-dev
jannau_ has joined #asahi-dev
yrlf has quit [Remote host closed the connection]
jannau has quit [Remote host closed the connection]
grange_c has quit [reticulum.oftc.net liquid.oftc.net]
ponkey364[m] has quit [reticulum.oftc.net liquid.oftc.net]
astrorion26[m] has quit [reticulum.oftc.net liquid.oftc.net]
long[m] has quit [reticulum.oftc.net liquid.oftc.net]
os has quit [reticulum.oftc.net liquid.oftc.net]
roxfan has quit [reticulum.oftc.net liquid.oftc.net]
d4ve has quit [reticulum.oftc.net liquid.oftc.net]
arekm has quit [reticulum.oftc.net liquid.oftc.net]
Synth[m] has quit [reticulum.oftc.net liquid.oftc.net]
Fanfwe has quit [reticulum.oftc.net liquid.oftc.net]
suricato has quit [reticulum.oftc.net liquid.oftc.net]
crabbedhaloablut has quit [reticulum.oftc.net liquid.oftc.net]
mariogrip[m] has quit [reticulum.oftc.net liquid.oftc.net]
YichaoYu[m] has quit [reticulum.oftc.net liquid.oftc.net]
wollymilkcap[m] has quit [reticulum.oftc.net liquid.oftc.net]
TellowKrinkle[m] has quit [reticulum.oftc.net liquid.oftc.net]
Guest3421 has quit [reticulum.oftc.net liquid.oftc.net]
SocioProphet[m] has quit [reticulum.oftc.net liquid.oftc.net]
simjnd[m] has quit [reticulum.oftc.net liquid.oftc.net]
samfromspace[m] has quit [reticulum.oftc.net liquid.oftc.net]
sajattack[m] has quit [reticulum.oftc.net liquid.oftc.net]
nilsi[m] has quit [reticulum.oftc.net liquid.oftc.net]
kdrag0n[m] has quit [reticulum.oftc.net liquid.oftc.net]
lockna has quit [reticulum.oftc.net liquid.oftc.net]
joerosenberg[m] has quit [reticulum.oftc.net liquid.oftc.net]
fridtjof[m] has quit [reticulum.oftc.net liquid.oftc.net]
CristianMgheruan-Stanciu[m] has quit [reticulum.oftc.net liquid.oftc.net]
brentr123[m] has quit [reticulum.oftc.net liquid.oftc.net]
AnushervonTabarov[m] has quit [reticulum.oftc.net liquid.oftc.net]
davay[m] has quit [reticulum.oftc.net liquid.oftc.net]
bastilian[m] has quit [reticulum.oftc.net liquid.oftc.net]
AkihikoOdaki[m] has quit [reticulum.oftc.net liquid.oftc.net]
xerpi[m] has quit [reticulum.oftc.net liquid.oftc.net]
emilazy has quit [reticulum.oftc.net liquid.oftc.net]
alicela1n has quit [reticulum.oftc.net liquid.oftc.net]
psydroid[m]1 has quit [reticulum.oftc.net liquid.oftc.net]
akemin_dayo has quit [reticulum.oftc.net liquid.oftc.net]
mwalle has quit [reticulum.oftc.net liquid.oftc.net]
Stary has quit [reticulum.oftc.net liquid.oftc.net]
Esmil has quit [reticulum.oftc.net liquid.oftc.net]
jato has quit [reticulum.oftc.net liquid.oftc.net]
dottedmag has joined #asahi-dev
grange_c has joined #asahi-dev
astrorion26[m] has joined #asahi-dev
alicela1n has joined #asahi-dev
ponkey364[m] has joined #asahi-dev
mwalle has joined #asahi-dev
long[m] has joined #asahi-dev
roxfan has joined #asahi-dev
d4ve has joined #asahi-dev
os has joined #asahi-dev
arekm has joined #asahi-dev
Fanfwe has joined #asahi-dev
simjnd[m] has joined #asahi-dev
Synth[m] has joined #asahi-dev
samfromspace[m] has joined #asahi-dev
sajattack[m] has joined #asahi-dev
nilsi[m] has joined #asahi-dev
lockna has joined #asahi-dev
kdrag0n[m] has joined #asahi-dev
joerosenberg[m] has joined #asahi-dev
fridtjof[m] has joined #asahi-dev
emilazy has joined #asahi-dev
CristianMgheruan-Stanciu[m] has joined #asahi-dev
AnushervonTabarov[m] has joined #asahi-dev
brentr123[m] has joined #asahi-dev
bastilian[m] has joined #asahi-dev
AkihikoOdaki[m] has joined #asahi-dev
davay[m] has joined #asahi-dev
wollymilkcap[m] has joined #asahi-dev
xerpi[m] has joined #asahi-dev
YichaoYu[m] has joined #asahi-dev
crabbedhaloablut has joined #asahi-dev
suricato has joined #asahi-dev
TellowKrinkle[m] has joined #asahi-dev
SocioProphet[m] has joined #asahi-dev
akemin_dayo has joined #asahi-dev
Stary has joined #asahi-dev
mariogrip[m] has joined #asahi-dev
Guest3421 has joined #asahi-dev
Esmil has joined #asahi-dev
jato has joined #asahi-dev
psydroid[m]1 has joined #asahi-dev
timokrgr has quit [Quit: Ping timeout (120 seconds)]