You've got several things going on here. I'll try to address all of them.
The Compatibility Support Module (CSM) provides support for booting BIOS boot loaders (and therefore OSes) on an EFI-based computer. This is also known as "legacy" support. Thus, three names may be used to refer to the same thing -- BIOS, CSM, and legacy. Note that you cannot disable the EFI on an EFI-based computer -- the firmware on the computer is an EFI, full stop. (There is a partial exception in some older EFI implementations for x68/x86-64, like Gigabyte's Hybrid EFI, but they're something of a footnote in firmware history.) The most you can do is to tell it to ignore EFI-mode boot loaders -- and on many computers, even if you do that, it's treated more as a suggestion than as a command; the computer may still boot an EFI-mode boot loader under certain circumstances. Disabling the CSM, OTOH, is usually more reliable; this usually prevents any BIOS-mode boot loader from running on the computer.
Most computers that ship with Windows 8 and later are configured by default to boot in EFI mode only. They're also configured with Secure Boot active by default. Thus, if you want a universal boot medium, it should support both BIOS-mode and EFI-mode booting, and with Secure Boot support for the latter. This is possible, but it can be rather tedious to set up. There are several questions/answers on this site that cover this topic:
GRUB Boot Options
GRUB's boot menu is controlled via a file called
grub.cfg, which is normally located in the
/boot/grub directory. This configuration file is normally generated by scripts that come with GRUB, and is customized for a particular installation. Thus, when you installed to a USB flash drive on a system that had Windows XP on its hard disk, your
grub.cfg file included an entry for that Windows XP installation, and that entry persisted on other computers, despite the fact that the entry would become useless. When you ran
update-grub on a system that included Windows 7, the Windows 7 entry replaced the Windows XP entry because the scripts found Windows 7 but not Windows XP. There are several ways to fix this problem:
- Run the
update-grub command on a system that has no OS installed except for the Ubuntu on the USB drive.
- Use the GRUB Customizer tool to edit
grub.cfg. (I'm not 100% positive that it will enable you to remove your unwanted entries, though, since I've never used this tool myself.)
- Manually edit
grub.cfg. (This is generally a bad idea because of the risk of error, but it might be necessary in some cases.)
- Switch to a boot loader other than GRUB. Most such boot loaders require manual editing of their configuration files -- but those files are simpler and therefore easier to edit than
grub.cfg. My own rEFInd boot manager detects OSes on every boot, which makes it less reliant on configuration files and more adaptable to the current system. OTOH, rEFInd is an EFI-only tool -- which is true of most boot loaders. Thus, if you switch, you may need different BIOS-mode and EFI-mode boot loaders. (This isn't necessarily much of a drawback; EFI-mode and BIOS-mode versions of GRUB can be tricky to get to coexist.)
Note that any solution you try might be undone by an update to GRUB or to your Linux kernel, since the scripts that generate the configuration file run after every kernel or GRUB update. (A kernel update won't trigger a switch back to GRUB from another boot loader, but a GRUB update might.)
Missing USB drive
Some EFIs include a feature called "fast startup" or something similar (or completely different -- the lack of standardization in names is frustrating) that disables USB initialization, or at least cuts it back to the bare minimum. It could be that this feature is active on your Dell Alienware system, and is preventing GRUB from accessing the USB flash drive. This would result in the symptoms you describe. If so, the solution is to disable this feature in the firmware setup utility. Some systems offer fine-grained control over USB initialization, so you might look for options about that, too.
A similar issue might arise if the system treats different USB ports differently. For instance, USB 2 and USB 3 ports might be initialized differently. If so, moving the USB drive from one port to another might help.
One doubt I have about this explanation is that the system was obviously able to load GRUB itself, presumably from the USB drive. This suggests that USB access is active, which flies in the face of my hypothesis. Perhaps it's active enough to load the initial boot loader but not to let GRUB access the USB drive, though. Another possibility is that GRUB was loading from somewhere else, such as your hard disk. Yet another possibility relates to your Ubuntu version....
Ubuntu 14.04... Really?
Although Ubuntu 14.04 is still officially supported, it's getting a bit long in the tooth, and is likely to fail completely on the most modern hardware. This is because new hardware often requires new drivers, and the older Ubuntu 14.04 may lack these drivers. Thus, rather than Ubuntu 14.04, you may want to use 16.04.2, 16.10, or even the 17.04 beta that was recently released.
There's a slim chance that this accounts for your Dell's inability to boot, too; there could be a bug or missing driver in GRUB that's causing it to fail to access the USB drive.
Don't worry too much about this. Ubuntu identifies disks by their UUID values, which are unique 128-bit identifiers of filesystems. Thus, if the USB drive on which Ubuntu is installed switches from (say),
/dev/sdc, the system should continue to boot and work just fine.
I've already alluded to one exception to this rule: If a computer uses a new type of USB controller, the USB device might not be visible to the older Ubuntu 14.04. There may be other exceptions, too, such as if a computer's hard disk has a filesystem with the same UUID as one on your USB drive -- but such a collision is very unlikely unless you deliberately clone the filesystem or duplicate its UUID. There might be other reasons problems might crop up, but nothing else springs immediately to mind.