Strange booting problem

[Chris Murphy]

observations:


1. GRUB's boot.img, the 440 bytes of code in the MBR/LBA 0, does not
use the partition active bit (the boot flag). So boot flag is
irrelevant in a GRUB context. The GRUB boot.img code contains the
specific LBA to jump to where core.img is found, which on MBR disks is
in the MBR gap.


2. The most likely explanation for the problem, as someone else
alluded to, is the USB drive has stale bootloader code on it that
points to no where and hangs. If this drive was partitioned with
parted (including gparted which leverages libparted), the described
behavior is intended behavior by parted developers. [1]

The solution is to do one of two things: change the boot order in
BIOS; or zero the first 440 bytes of LBA 0 with this:

# dd if=/dev/zero of=/dev/sdX bs=440 count=1

##where X is the letter for the USB drive

---
Chris Murphy



[1] Which I've complained about, but the parted developers don't
appear to care, or think they're doing the majority a favor.

If LBA 0 is completely blank at the time parted partitions it, parted
writes out some basic jump code in the first 440 bytes of the MBR that
honors the active bit to determine the jump location. If the drive
isn't meant to be a boot drive, this code just causes the CPU to jump
to nowhere. There isn't even any error handling in this jump code. So
you get exactly the behavior described.

Now, I find it absurd, but, that's life with people who think everyone
else is a moron. Because after all, if you're not creating a drive
intended to boot you have no good reason to partition it at all: a.)
format the entire block device with a file system; or b.) use LVM on
the whole block device as the method of partitioning, which is vastly
superior to MBR or GPT partitioning. Note that parted will not
overwrite already present bootloader code in the MBR.