A friend of mine believes there may be an issue with some UEFI thing? I dont quite understand what shes saying about it. Just that theres some sort of issue involving "UEFI""
Alright. You're talking some newfangled substitute for BIOS designed by Intel starting in the mid 1990's and used only for servers until the mid 2000s, and intended to be generalised to all PC's by now. To be honest I built computers all throughout the 2000's (not Intel, though), and up until a few years ago, without actually ever running across a motherboard with UEFI. But basically UEFI / EFI is just a souped up BIOS.
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_InterfaceThe whole point of the UEFI or Unified EFI (Extensible Firmware Interface) is that you can communicate at more than 16 bits of data,that is in 32-bit and 64-bits as well. The EFI does a lot more than the BIOS ever did, even running diagnostics and remote operation of the computer without an operating system (scary, eh?).
The other side of this booting scheme in the booting of a hard drive is that in older systems, the Master Boot Record (MBR, a hidden file inside a bootable hard drive listing the operating systems in the hard drive) that worked together with BIOS has been replaced by the "GUID Partition Table" or GPT, such that GPT enabled disks drives work with EFI enabled motherboards. All well and good but I'm too old school for that...
Anyhow, according to this piece of text below, the new (U)EFI/GPT system is backward compatible to (BIOS/MBR) hardware, allowing new EFI compatible disks to be used in older BIOS enabled motherboards and viceversa. So there should be no issue here. If your computers have (U)EFI, they should recognize any bootloader, even the old GRUB types, let alone syslinux.
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_InterfaceLinux
See also: EFI System partition § Linux
Support for GPT in Linux is enabled by turning on the option CONFIG_EFI_PARTITION (EFI GUID Partition Support) during kernel configuration.[30] This option allows Linux to recognize and use GPT disks after the system firmware passes control over the system to Linux.
For reverse compatibility, Linux can use GPT disks in BIOS-based systems for both data storage and booting, as both GRUB 2 and Linux are GPT-aware. Such a setup is usually referred to as BIOS-GPT.[31] As GPT incorporates the protective MBR, a BIOS-based computer can boot from a GPT disk using GPT-aware boot loader stored in the protective MBR's bootstrap code area.[29] In case of GRUB, such a configuration requires a BIOS Boot partition for GRUB to embed its second-stage code due to absence of the post-MBR gap in GPT partitioned disks (which is taken over by the GPT's Primary Header and Primary Partition Table).
I'm going to risk it and say this - aware that I'm far too old school, and probably need to read a manual on PCs by now:
The thing that pulls my eyes, is that one requirement for the EFI, that the data size (bits) of the kernel of the operating system (the core or kernel of Linux used in Ubuntu) needs to match the size in the EFI system. I'm assuming (perhaps wrongly) that a 64 bit computer will have a 64 bit EFI, and thus the Linux Kernel should be 64 bits too, although it reads that a 64 bit Linux kernel can support a 32 bit EFI, version 3.15 or better. But what if it doesn't in the opposite direction? That is what if a 32 bit Linux kernel is not compaticle with a 64 bit EFI?
I say this because one common bug in Ubuntu Linux is that the software bells and whistles that supports a 32-bit software to be run by a 64 bit computer tends to fail every now and then (it's a set of kernels and associated peripherals known by the name of "arch." This "arch" feature is newfangled and working intermittently, shall we say?
UEFI requires the firmware and operating system loader (or kernel) to be size-matched; for example, a 64-bit UEFI firmware implementation can load only a 64-bit operating system boot loader or kernel. After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over. At this point, the kernel can change processor modes if it desires, but this bars usage of the runtime services (unless the kernel switches back again).[24]:sections 2.3.2 and 2.3.4 As of version 3.15, Linux kernel supports 64-bit kernels to be booted on 32-bit UEFI firmware implementations running on x86-64 CPUs, with UEFI handover support from a UEFI boot loader as the requirement
Bottom line, is that a safe thing to do is to get a Linux Image that matches your computer hardware. A 64 bit Linux for a 64 bit computer. Nowadays most processors are 64 bit (say the Intel Core 2 i3 and i5, and you may assume all the AMD processors have been 64 bit for more than a decade now). Make sure you have a 64-bit Linux ISO image and that your unetbootin can handle 64 bit images of Linux.
Is the ISO image of your current Linux ISO 32 bit or 64 bit? What Ubuntu are you trying to run? I only use 64 bit Linux (and have for many years now since I'm addicted to AMD processors). Are your machines' CPU 64 bit? If you don't know, are they newer than say 2006? If so, it's more than likely they run on 64 bits. I think they need a 64 bit Linux kernel.
