14.04 USB install GRUB2 issue

Question

I used an old Dell running XP to install 14.04 x64 onto a Corsair Voyager GTX 128 GB. The drive works great on that Dell. I moved it to a Panasonic Toughbook (newer UEFI, Win7 x64, UEFI disabled, CSM enabled, legacy boot, etc), and it also works fine. However, I think the GRUB2 boot order is funky. In the GRUB options it still shows me the option to boot into the XP Professional (original host laptop). Also, looking at the GRUB commands, how will grub know if I install this into a dual-HDD computer to change the sdX to the correct device?

The other issue is when trying to use this on a new Dell Alienware R13 (UEFI, Win 8.1 x64, UEFI disabled, legacy boot, AHCI mode), it will always fail to boot correctly. It almost seems like, during the boot sequence, it is trying to boot root from the host SSD instead of the USB...but the USB isn't shown in the grub> ls output, all outputs are no file system found.

The end goal is to have a working 14.04 install on this USB that can work on BIOS and legacy-booted UEFI host laptops. Thoughts?

Update-- After sudo update-grub on the legacy-enabled UEFI Win7 Toughbook, it indeed updated the grub, but to the Win7 option. The grub looks like this:

    setparams: 'Ubuntu'

            recordfail
            load_video
            gfxmode $linux_gfx_mode
            insmod gzio
            insmod part_msdos
            insmod ext2
            set root='hd0,msdos1'
            if [ x$feature_platform_search_hint = xy ]; then
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-baremetal=ahci0,msdos1 <UUID1>
            else
              search --no-floppy --fs-uuid --set=root <UUID1>
            fi
            linux         /boot/vmlinuz-3.16.0-30-generic root=<UUID> ro quiet splash $vt_handoff
            intrd          /boot/initrd.img-3.16.0-30-generic

Update 2--- Per the advice of @Rod Smith, I used Rufus to build an installer with 16.04 and, sure enough, it will boot on the Dell in both BIOS and EFI modes. I guess it was a driver issue. Now to install it onto my good stick.

Answer 1

You've got several things going on here. I'll try to address all of them.

The CSM

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:

• Ubuntu on a USB stick - boot in both BIOS and UEFI modes
• Boot usb key on both UEFI and MBR?
• Making a pen-drive with a image from scratch bootable both in BIOS and UEFI mode

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.

Device Names

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/sdb to /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.