Re: PXE booting on Arm64 platform

To once again follow up on this. Would it be possible to have coreos-installer ported to Kubic or similar? Something where you boot a live environment and instruct to install to a device via ignition. Kubeadm configuration done purely with Ignition is super appealing. https://build.opensuse.org/request/show/882034 (https://link.getmailspring.com/link/52D29193-F296-4C84-8986-382B07DD1BEE@getmailspring.com/0?redirect=https%3A%2F%2Fbuild.opensuse.org%2Frequest%2Fshow%2F882034&recipient=a3ViaWNAbGlzdHMub3BlbnN1c2Uub3Jn) I have just submitted this request to add DigitalOcean as a platform type for ignition so user-data on digitalocean can be used for ignition. Originally I was using a user-data script with the openstack images. The issue I'm currently facing now is doing similar for my bare metal clusters. I have fine tuned autoyast but it's too 'fragile'. I can't easily change through code my ignition url (aka adding a kernel parameter in my autoyast xml). Using purely ignition to automate the kubeadm cluster creation process would be great for Kubic. I would be happy to submit a blog post as well instructing users on how it can be done. I'd love to get support for matchbox with Kubic. It's almost there! On Mar 16 2021, at 8:18 pm, Anthony J Rabbito wrote:

For what it's worth and clarity I have achieved most of what I was looking for by using a autoyast similar to this.

https://gist.github.com/anthr76/d06ee9ef7e791563597fba708aefdd48 (https://link.getmailspring.com/link/52D29193-F296-4C84-8986-382B07DD1BEE@getmailspring.com/1?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2F502B77CA-D340-4952-B4FA-DE3910B6C5BC%40getmailspring.com%2F0%3Fredirect%3Dhttps%253A%252F%252Fgist.github.com%252Fanthr76%252Fd06ee9ef7e791563597fba708aefdd48%26recipient%3DZnZvZ3RAc3VzZS5kZQ%253D%253D&recipient=a3ViaWNAbGlzdHMub3BlbnN1c2Uub3Jn) I compiled ipxe and edk2 for aarch64. I avoided grub through this and just chain into the yast installer. I have yet to test on a Pi yet but everything has been smooth so far via libvirt.

On Mar 15 2021, at 9:30 am, Anthony J Rabbito wrote:

...

Thanks for you reply Fabian.

I've gotten my iPXE deployment enviroment set up and I've been playing around with scenarios. I didn't yet end up taking the Kiwi route as you previously mentioned since I'm able to get to edk2 UEFI iPXE on my Pis through the network. So essentially I have the yast iso for arm and x86. What I'm struggling with is a unattended installation. I have tried some autoyast2 configurations borrowing ideas from the https://github.com/yast/skelcd-control-MicroOS/blob/master/control/control.M... (https://link.getmailspring.com/link/52D29193-F296-4C84-8986-382B07DD1BEE@getmailspring.com/2?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2F502B77CA-D340-4952-B4FA-DE3910B6C5BC%40getmailspring.com%2F1%3Fredirect%3Dhttps%253A%252F%252Fgithub.com%252Fyast%252Fskelcd-control-MicroOS%252Fblob%252Fmaster%252Fcontrol%252Fcontrol.MicroOS.xml%26recipient%3DZnZvZ3RAc3VzZS5kZQ%253D%253D&recipient=a3ViaWNAbGlzdHMub3BlbnN1c2Uub3Jn) repo in terms of patterns and roles, and pointing install at my nearest OSS tumbleweed mirror. Even though Jing is coming back clean my installs are failing. Before going to deep in that topic is this really the best avenue? All I'm trying to achieve is a unattended installation of Kubic specifying a drive to be installed on and giving a SSH key. Autoyast seems way to over kill for this but there's only yast installations being provided for aarch64 and x86. Fedora Core-OS has something like the installer that can be called with a initial ignition. I think I'm looking for something like that. A live kubic system that installs to a specific drive. One more thing: I'm assuming ignition can be specified with a net url such as a http server like most over platforms can? Is that right? Thanks, Anthony On Mar 4 2021, at 8:29 am, Fabian Vogt wrote:

...

Moin,

Am Mittwoch, 3. März 2021, 16:18:42 CET schrieb Anthony J Rabbito:

...

Good Day,

I'm inquiring for some methods of PXE booting on a mixed architecture environment between Raspberry Pis and X86 platforms. It seems like my best, and quickest path to success would be something like this. Compile aarch64 grub

No need to compile that yourself. For EFI, you can use the prebuilt grub.efi from grub2-arm64-efi, combined with shim.efi for secure boot, if you need that.

...

and host on a tftp server along with x86 grub and chain load based on MAC addresses AFAIK there are various DHCP options which indicate the arch, so you might not have to use the MAC prefix there.

...

Use a custom ipxe file to either boot from hard drive or do a fresh install

*possibly* use ignition.url as a kernel command line for combustion/ignition configuration on the hosts

Note that initrd networking on Tumbleweed is currently broken: https://bugzilla.opensuse.org/show_bug.cgi?id=1182227

...

Though there's a few short falls I see here. One being RBrown has a experimental self-install image for x86-64 that installs to the first hard drive it sees. That is almost perfect for my use-case but it would be best if we can specify a drive by UUID (especially on storage-nodes). Here's the kiwi documentation for deploying images over PXE: https://osinside.github.io/kiwi/building_images/build_expandable_disk.html#d...

You could file a feature request for kiwi to accept a device ID (and possibly other options) from the kernel cmdline.

Cheers, Fabian

...

I have been successful on getting iPXE to work on Raspberry Pi4s though I'm unsure yet how I can instruct the existing Pi image to install from iPXE. Does anyone have a working implementation of PXE booting from x86, and arm to install to disk without YaST and the use of using physical medium for combustion/igntion? Does anyone have any thoughts to share? Thanks, Anthony