Learn more about these different git repos.
Other Git URLs
So we started trying to build a Workstation live for aarch64 recently, but it fails. It fails because we try and make it bootable on Macs, which involves running mkfs.hfsplus, and that isn't present:
mkfs.hfsplus
DEBUG util.py:621: ERROR:program:Error running mkfs.hfsplus: No such file or directory
"But why, O most handsome and pleasant QA monkey", I hear you ask, "is mkfs.hfsplus missing?"
Well that was an excellent question, and so wonderfully phrased! The answer is: because lorax only depends on it on x86_64.
Up till about three weeks ago I'd have just said, hey, let's tweak lorax or pungi-fedora or whatever to not try and make these images bootable on Macs, but then uh a thing happened.
So, @bcl @pwhalen @mohanboddu , what do you folks reckon we should do here? Have lorax depend on hfsplus-tools on aarch64 too? Not make the aarch64 image Mac bootable? Or something else? Thanks!
Is there a reason why hfsplus-tools is not available across all architectures?
hfsplus-tools
It is available on all arches.
I'd say we should modify lorax to require it on aarch64 also and see what happens, but happy to defer to those who know better...
Changing the Requires: hfsplus-tools to cover all Live image arches looks like as the right solution to me.
Requires: hfsplus-tools
It's pointless though on anything other that x86, and even then only for Macs, it sounds like a blunt hammer solution
+1 to changing lorax to depend on hfsplus-tools for aarch64 (with hopes of supporting the new Macs).
The new Macs are irrelevant here ATM
Unless there is an actual reason to enable mac booting on aarch64 (eg. actual hardware that can use it) I don't think it should be switched on. When new macs become available, and someone makes sure it works (what are the odds that booting them will be different than x86_64?) then it can be enabled.
Enabling it now gives users the impression that it is expected to work, which it isn't.
Agreed, ATM we have no idea if we will be able to run bare metal dual boot along side MacOS, and if we ever are able to it'll likely look completely different to the x86 means so we should not add this functionality as it affects vanilla UEFI and there's other deps there which definitely aren't built and we don't wish to build on aarch64 because they're unsupportable.
I too agree with @bcl and @pbrobinson here, I guess making aarch64 image non mac bootable (until we know for sure) seems to be a better option for now.
Metadata Update from @mohanboddu: - Issue tagged with: groomed, medium-gain, medium-trouble
If everyone agrees with making aarch64 image non mac bootable, then we just wait for the lorax patch.
You just need to pass --nomacboot when building the live image.
that would be a pungi-fedora or pungi change, then.
I think it's gonna take a pungi patch, currently we can't pass that to the things in the livemedia phase... @lsedlar any thoughts?
I think we actually need to fix Koji.
Does the tool that create the live images need one or the other? It doesn't default to nomacboot if macboot isn't specified?
I think we actually need to fix Koji. Does the tool that create the live images need one or the other? It doesn't default to nomacboot if macboot isn't specified?
macboot = True is the default, so passing --macboot doesn't really do anything. Only --nomacboot has an effect.
So in which case we need the koji patch
The koji patch is in/live now and indeed we have a aarch64 live workstation image (no idea if it works... but it composed!)
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Thanks for the update, Kevin. It works in qemu, not yet tested on actual hardware.
Login to comment on this ticket.