Grub2 Corrupts Hard Drive and Bad Design Causing failed boot.

Bug #995144 reported by David F.
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

It's bad enough that the designers of various linux distros decided the default place for GRUB was the MBR instead of adhering to standard PC architecture practices (which all other OSes, including *nix version, followed), of putting the kernel loaders in the partition and making it active so standard code in the MBR would transfer control to it. For cases where a volume was to boot it could have made the Extended partition active, put the start code in the EBR of the extended and have that boot the volume. The Linux community would have a fit if MS decided it was going to write its own kernel loaders and stick them in the MBR and take over the disk.

Anyway, now apparently whoever has taken over GRUB2 (latest version) has made some big mistakes and must not understand the standard pc architecture either. Someone has made it write outside the first track of the hard drive if it doesn't think there is a partition there.

1 - Writing outside the first track of the hard drive can corrupt partitions not in the MBR at the time which is common with various partitioning schemes and cause data loss for users.

2 - Adding a partition to the start of the disk (cylinder aligned) afterwards would overwrite the part of GRUB written out beyond the first track making the entire system unbootable.

3 - changing partition layouts can again overwrite GRUB data which should be in the partition by default.

Revision history for this message
Hawk (rthawkcom) wrote :

Looks like you beat me to the punch David! Here we go again!! Already went though all this crap with Lucid and NOW IT'S BACK!!

Performed an upgrade from 10 LTS to 12 LTS. Upgrade went perfectly. Rebooted the computer... nothing!! DEAD! Boot sector GONE!!

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Hawk (rthawkcom) wrote :

Unable to even re-install. Refer to Bug #998292

Ubuntu is NOT Fit 2 PC friendly!!

Revision history for this message
Phillip Susi (psusi) wrote :

What do you mean by "write outside the first track"? Where did grub write to? How do you know?

When reporting bugs it is important to describe exactly what you did, what you expected to happen, and what happened instead.

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
David F. (dfisa) wrote :

If there is no partition starting at lba 63 (the normal location when sectors per track is 63 for modern large hard drives) grub can use over 100 sectors (0-100) and maybe more. The only "safe" area is within the first track, however that isn't really safe as other specs such as gpt, embr, certain attribute fields for Windows and some ibm structures already use that area. A kernel loader really belongs in a boot partition by default, at least on PC architecture.

Revision history for this message
Phillip Susi (psusi) wrote :

Unfortunately there is no such thing as a grub boot partition in the msdos partition table, and adding one would cause more problems that it would solve given the fragility of the msdos partition table. Using the unpartitioned space after the MBR is the best grub can do on msdos partitioned disks, and intended behavior, not a bug. Also there is nothing particular about the first track that makes it any more or less safe to use than any other unpartitioned space on the disk. It is simply a matter of convention that msdos left this space unpartitioned, and boot loaders decided to make use of it.

Normally the grub core image can fit within 62 sectors, depending on what modules are built into it. It appears that recently when both lvm and raid modules are built in, it no longer quite fits in 62 sectors. Fortunately, the convention has shifted in recent years to not start the first partition until sector 2048.

Changed in grub2 (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
David F. (dfisa) wrote :

In the PC architecture (has nothing to do with DOS) the boot partition is the active partition. When Linux OS is installed, that partition is where the kernel loader should be located and that partition set active if the user choose (for extended partitions I offered a solution in my prior message).

Sectors in the first track has been reserved by IBM for data structures since the early 90's and the entire first track has been fully standardized and extended by the EMBR in 1996. See http://www.terabyteunlimited.com/specs/embr2.pdf and http://www.terabyteunlimited.com/history-bootit-bare-metal.htm. The first track has further been defined for EFI based systems and the GPT.

You should also note that the alignment to 2048 sectors has caused many users lost data and corruption by older OSes and their tools, this is, once again, because of the lack of knowledge and experience of those implementing it.

The fact remains that the current design of GRUB on PC's is destructive and improper. The design and flexibility of the PC architecture would allow a properly designed GRUB to work without causing any problems of conflicts.

Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Phillip Susi (psusi) wrote :

Installing grub to a partition requires that the core image file have its sector list embedded in the MBR so it can be loaded, which comes with its own set of problems, including failure if the file is moved by a defragger, and getting block lists on some filesystems such as btrfs is not even possible. This is why such setups are unsupported by the grub developers and so this will not be changed.

If you want grub to fit within the first 63 sectors of the disk, you will need to use a simple boot setup, such as a plain ext2 /boot partition, rather than more complex setups which simply requires more code than can fit there.

Changed in grub2 (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
David F. (dfisa) wrote :

No, it doesn't require anything in the MBR. The file system specific kernel loader code goes in the boot sector of the partition. All PC based partitions are required to have a boot sector if bootable. If someone designs a file system without one and they want it to boot, they didn't know what they were doing.

File system specific loaders can use file names and don't require bad designs like using sector maps. The file system can set aside enough sectors it thinks would be required to for a kernel loader to access files. It's been done that way by just about everybody, including PC *nix versions, OS/2, Windows, DOS, BeOS, MacOS on the PC, etc.. except Linux. Linux was / is unique in it's lack of PC standards and lack of kernel loader being included standard.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.