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
possiblemeatball1 has joined #asahi-alt
possiblemeatball has quit [Write error: connection closed]
possiblemeatball has quit [Remote host closed the connection]
possiblemeatball has joined #asahi-alt
possiblemeatball has quit []
kidplayer666 has joined #asahi-alt
possiblemeatball has joined #asahi-alt
possiblemeatball has quit [Remote host closed the connection]
<mps>
I've got alpine installed with installer but problem which didn't solved is how to embed proper root partition in EFI/BOOT/BOOTAA64.EFI
<mps>
and I don't have idea how to do this with installer, if possible at all
<ncopa>
Do we even need grub when we have u-boot?
<mps>
ncopa: good question
<mps>
but end users like grub
<ncopa>
I mean u-boot is able to load kernel specified in extlinux.conf?
<mps>
right, that is how I used M1 in beggining, with extlinux.conf
<mps>
and iirc j`ey also used it for long
<mps>
and also to boot alpine
<ncopa>
only reason for grub is if you have your kernel and initramfs on lvm or zfs or similar
<mps>
we can try again with extlinux.conf but then we will be different from all other distros
<mps>
also maybe we could ask Dermot Bradley (alpine dev) because he have good understanding of grub
<mps>
anyway, good thing (news) that we are nearly 'there'
<mps>
also with extlinux.conf we will have to keep vmlinuz, initramfs and dtbs on ESP
<mps>
in new installation root partition will be usually 5 so we can prepare EFI/BOOT/BOOTAA64.EFI with this number embeded
<j`ey>
mps: I tried to understand that, but didnt, I asked on the fedora channel to see if someone knows
<janneg>
it uses root=UUID=...
<ncopa>
I don’t know if I completely misunderstand, but why does grub need root partition?
<ncopa>
I thought grub only needs partition with kernel and initramfs, eg boot partition
<j`ey>
janneg: if that root is 'randomised' (or generated) how does that actually get into the image? (for multiple installs)
<janneg>
it's updated after 1st boot randomization and I think it's a random (at image generation time) UUID to begin with
<mps>
janneg: BOOTAA64.EFI 'must' have embeded partition on which it will search for grub (but I'm sure you know this, so maybe I was not clear with my question)
<mps>
prepared root.img which is then installed on linux root partition with installer 'keeps' UUID, this is not problem
<mps>
I could prepare few BOOTAA64.EFI files with different gpt partition numbers and tell users to copy proper one to ESP from macos. Ugly solution but I don't have better idea for now
<chadmed>
pass --boot-directory to grub-install too
<chadmed>
and point it to /boot on your image
<mps>
chadmed: on different partition?
<mps>
isn't --boot-directory default to /boot
<mps>
chadmed: forgot to mention /boot/grub is not on ESP but on root partition in alpine case
<chadmed>
dunno but that should basically be all you need to get BOOTAA64.efi to loog for grubaa64.efi in the correct place
<chadmed>
yeah exactly
<chadmed>
thats literally all you need to do
<chadmed>
when your rootfs image is dded into the free space the uuid will go with it
<mps>
interesting, will try
<chadmed>
so your bootaa64.efi image will find it
<mps>
thank for hint
<mps>
thanks*
<mps>
chadmed: yes, dd preserves uuid
<mps>
is there guide for tags in installer_data.json
<mps>
I had to guess from fedora and debian ones
<chadmed>
i dont think any part of the installer is documented right now lmfao :p
<mps>
heh, right
<chadmed>
when i and/or leio have a crack at a gentoo image i will probably document some stuff
<chadmed>
or at least write a guide
<mps>
'use source, Luke' :)
<leio>
I've built such an image already, yeah, but need to add all the dracut and other fun and automate it
<leio>
we ought to aim putting this out to official builders, just like weekly stage3's
<leio>
but now work is picking back up again, so I'm struggling catching up with the other stuff I wanted to do and then the existing nvram ::gentoo PRs even :(
<chadmed>
my plan is to use catalyst to build an asahi stage3 and then basically follow what builder.sh does
<mps>
macos 14.2.1 is offered right now for upgrade
<mps>
would it work with asahi
<cy8aer>
I am running 14.2.1 - and the asahi stub is - and stays 13.5
<mps>
on new install stub is also new, i.e. will be 14.2.1?
<j`ey>
no, the stub stays at a particular version
<mps>
j`ey: even if I do clean install?
<j`ey>
(because some firmware interfaces can change between versions)
<j`ey>
yes
<mps>
ah, so stub is not taken from installed macos?
<j`ey>
nope
<mps>
good then, thanks
<j`ey>
some firmware, NVMe, SMC, is global, and that shoudl stay backwareds compatible
<mps>
ok, lets upgrade
<mps>
while I'm preparing and building new alpine files
r0ni has joined #asahi-alt
casycas has quit [Quit: Leaving]
u154ss has joined #asahi-alt
john-cabaj has joined #asahi-alt
u154ss has quit [Quit: Page closed]
<mps>
chadmed: sorry to bother you again, '--boot-directory=/boot' or '--boot-directory=/boot/grub'? grub is installed in /boot/grub on root partition
lactose has joined #asahi-alt
<mps>
whatever I try grub embeds '(,gpt6)/boot/grub' in BOOTAA64.EFI, and this is root partition on system where I'm trying to fix this in chroot
lactose_ has joined #asahi-alt
lactose_ has quit []
kidplayer666 has quit [Quit: Connection closed for inactivity]
kidplayer666 has joined #asahi-alt
possiblemeatball has joined #asahi-alt
hightower2 has joined #asahi-alt
possiblemeatball has quit [Quit: Quit]
possiblemeatball has joined #asahi-alt
lactose has quit [Read error: Connection reset by peer]
possiblemeatball has quit [Remote host closed the connection]
lactose has joined #asahi-alt
lactose has quit [Read error: Connection reset by peer]
possiblemeatball has joined #asahi-alt
lactose has joined #asahi-alt
lactose has quit []
john-cabaj has quit [Quit: john-cabaj]
john-cabaj has joined #asahi-alt
eiln has joined #asahi-alt
<chadmed>
mps: its just /boot. maybe see what builder.sh does if youre trying to do it from a chroot