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'

            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>
              search --no-floppy --fs-uuid --set=root <UUID1>
            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.

  • In order to boot installed systems in both UEFI and BIOS mode, you must have bootloaders for both. This can be done but is a bit tricky. See this link, help.ubuntu.com/community/Installation/UEFI-and-BIOS . You can take a shortcut and strart from one of the compressed image files, or you can use the description and do something similar to make your installed system boot in both modes. An alternative is to use a persistent live drive according to this link, askubuntu.com/questions/664577/… – sudodus Mar 30 '17 at 12:17
  • If you boot in BIOS mode and use Something Else the install option partition screen shows where to install the grub2 boot loader. Just be sure to choose the external drive for boot loader. Then in UEFI you have to choose to boot external drive. Many new systems will auto switch, others have to have legacy mode enabled. You may need newer version as Dell often has additional drivers in sputnik and those later are incorporated into Linux. – oldfred Mar 30 '17 at 12:20
  • I was under the impression that if I make a non-UEFI (old-school) bootable USB, that it should work in a UEFI system as long as the system has legacy mode and USB compatibility enabled, is that not the case? I'm not trying to boot it in UEFI mode. oldfred - I did install the bootloader on the same USB. I may need a newer version of what, the computer? GRUB2? Ubuntu? – orion_134 Mar 30 '17 at 13:11
  • If you are happy to boot all the computers in BIOS (legacy, CSM) mode, fine, then you need not worry about booting in UEFI mode, and things will be easier :-) Avoid proprietary drives. Add some tweaks to decrease wear of the memory cells: noatime, maybe no journaling, maybe no swap, or at least try to avoid swapping. – sudodus Mar 30 '17 at 14:02
  • You can fix the 'funky' grub menu, if you run sudo update-grub in a computer with no other drive. Then no other system will be detected and entered into the grub menu. (You can also remove them from /boot/grub/grub.cfgmanually.) – sudodus Mar 30 '17 at 14:05

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.