How to restore the MBR after do-release-upgrade?

blind Pete 0123peter at
Sun Jul 10 13:38:08 UTC 2016

Liam Proven wrote:

> On 9 July 2016 at 17:03, Ralf Mardorf <silver.bullet at> wrote:
>> So there will be a pointer within the 512 bytes of the MBR, but no
>> entry beyond those 512 bytes, the GRUB image that might need additional
>> bytes, is written to some space, that belongs to the partition? It's
>> somewhere on the disk, but definitively not attached to the 512 bytes
>> of the MBR?

This is confusing.  Don't panic.  

The reason it is called booting is that at first sight it looks 
impossible - like lifting yourself of the ground by pulling on 
your boot straps (shoe laces).  Not because you want to kick 
the computer across the room.  

> I am not sure that I understand.
> After this, you will need some other boot manager in your MBR,
> something that can chainload the copy of GRUB in your Ubuntu root
> partition. This setup alone will not be able to boot your computer.
> It is a way of confining Ubuntu's GRUB within Ubuntu. You will need
> some other bootloader, such as the FreeBSD one perhaps, or the Windows
> one if you use Windows.

If your computer has UEFI firmware and a GPT disk ignore this...

With BIOS firmware at power up, if no floppy, CD, DVD, USB stick, 
etc. is found the first hard disk is looked at.  

Beware; your installer, your firmware and your operating system(s) 
might discover your hard disks in different orders.  The first 
one found will be /dev/sda.  Solid state 
drives "spin up" faster than spinning rust drives.  If you have 
configured RAID, LVM, Power Up In Standby, or encryption, things 
can get complicated.  Try not to use /dev/sda, if you can use a 
LABEL, UUID, PARTLABEL, or PARTUUID.  LABELs are good for humans, 
UUIDs are good for computers.

After the POST the BIOS will read the 512 bytes of sector zero 
(the mbr) of /dev/sda (well, of *a* disk).  Some of those 512 
bytes are needed for the partition table and other stuff, 
leaving 400 odd byte for code, barely enough to do anything 
sensible.  That code is technically a bootloader in itself, 
but more commonly known as the first stage boot loader, or 
as the mbr code.  On a BIOS machine all it has to do is start 
loading code from somewhere.  Historically that somewhere 
was the "unused" first track, up to 63 sectors of it, that 
came before the start of the first partition.  That code was 
smart enough to do something interesting.  That code was also 
a boot loader, although usually known as the second stage 
bootloader, or maybe the stage 1.5 bootloader.  I'm not joking, 
read the grub classic documentation.  

After that there are a few choices.  >:->

What you want is for execution to pass to sector zero (the Volume 
Boot Record) of the root partition of your chosen installation, but 
there are a few problems with that.  

First, as Liam pointed out, if there is nothing in the mbr the BIOS 
will not find the vbr and so can not boot your OS.  

Second, some file systems don't leave any free space at the start 
of the partition, so writing to that sector will corrupt things.  
Ext2, ext3 and old ext4 are good.  

Third, I've left out a few details.  

Forth, the Grub2 developers frown on this.  

Fifth, depending on which boot loaders you have installed and how 
they have been configured, many other things are possible.  

Now the disk as a whole is a volume, so the mbr is a type of vbr.  
You can cascade a lot of boot loaders.  You can go from /dev/sda 
to /dev/sda7, back to /dev/sda, to /dev/sdb, to /dev/sdb4 to your
operating system, but that all requires a bit of forethought.  

What have you got?  What do you want?  

blind Pete
Sig goes here...  

More information about the ubuntu-users mailing list