Debian CD Image for AArch64 Windows Laptops
github.com
github.com
Update: some enterprise UEFI setups do boot from DVDs but the ISO should be a hybrid type (aka must have EFI-style partitions).
> To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification.
This was chosen specifically to allow polyglot ISO files that can both be booted bh UEFI and legacy BIOS. The implementation of tools to create such polyglot files are, to say the least, interesting. The tools effectively generate both a FAT and ISO partition, each having its own file information table, but sharing the actual file contents.
Phoenix and IBM coming up with a standard. Wonder if that was still a hard pill the swallow in 1995.
But I'm sure the bad blood was measurable, especially for the higher-ups.
[0] https://www.debian.org/releases/jessie/amd64/ch04s03.html.en
Of course, in practice with optic media you may stumble upon varying forms of bit rot, scratches or recording errors so it's definitively not the be-all and end-all, but still, I've got CDs recorded 30 years ago I can still read in modern systems and that I won't wipe by accident.
Me neither!
Between this and Marcan42 on Twitter working on Linux for M1 Macs, I'm hopeful that ARM64 Linux devices will slowly start to creep in further
(32-bit Arm was another story, but that era is long since dead)
EDIT: think that this was worded badly, modified it.
Microsoft also seems quite positive about the option being there: https://docs.microsoft.com/en-us/windows-hardware/manufactur...
Edit: fair enough, sounds about right!
That’s basically the definition of Linux. That’s not Apple’s fault.
A common misconception. Something like 90+% of Linux commits come from people whose job is writing that code.
The reality is that hardware manufactures do not care what OS you run, as long as it doesn’t result in costly hardware returns or endless support calls. This is why hardware typically has options to disable OS-specific. secure boot, but it requires some technical steps that average users won’t accidentally stumble upon.
The M1 macs were never locked down, either. Apple has said that Microsoft can make Windows builds for them if they’d like. Linux on M1 macs is only a matter of time.
Secure boot is a net win for everyone. Having an option to disable it lets the 0.01% of people who want to run Linux use the hardware too.
It wasn't just FUD. Microsoft has changed their tune on this over the years, but it used to be that their certification requirements mandated that users could not disable secure boot on ARM devices: https://arstechnica.com/information-technology/2012/01/micro...
If that were still their policy today, it would make projects like this nearly impossible.
Ok, but why can't it use the EFI runtime services to write to the efi vars, like Windows' bcdedit does? After all, bypassing the firmware to write the vars should actually be riskier, as to my knowledge UEFI does not mandate any specific format for them in NVRAM, so a vendor very much could use a custom format if they wanted, even though almost everybody just uses a modified version of the reference implementation.
The UEFI standard SetVariable implementation is nonfunctional and the GetVariable one is at the same state since ExitBootServices.
This is due to the fact that the firmware and the OS cannot control the storage device at the same time. The issue isn't seen on most x86 PCs since those use a separate SPI flash chip for the UEFI.