[Solved] Grub2 and "Invalid partition table!"

chewtoy · 2015-12-30 07:40:39

Solution

It seems my problem was that my BIOS didn't like having a boot-flag on a logical partition.
Changing the boot-flag from sda5 (where my Linux resides) to sda1 (first partition, and is a Windows-recovery partition) made my BIOS happy and stopped giving the error.
GRUB loads just fine and has no trouble booting either Linux or Windows.

--------

Yesterday I decided to dual boot one of my machines.
It is a Dell Latitude E6430 and came pre-installed with Windows 7 Pro (it's a work laptop and we are required to have a bare-metal install of Windows, so no VMs).
As me and Windows tend to disagree about how an OS should be I could no longer stand it and decided to install Arch on it and dual boot.
After some trial and error I got the partitioning to work. Note that the computer came pre-loaded with windows with an MBR partitioning table. I don't have access to a full Windows DVD-installI disc and I have work-related things already on it. So doing a complete reinstall and using GPT is not an option for me atm.

Partitioning process, can be skipped over

I started out with three partitions:

OEM partition (primary)
Windows recovery (primary)
Windows OS (primary, boot)

Great, I thought. Now lets create two more partitions, one for Linux and one partition that's NTFS so I can share files between my OSs.
Being stupid and not paying attention, I created another primary partition marked ext4. All good so far. I tried to create another partition. "Cannot create more partitions." I read. Silly as I was, I thought "Well a reboot should fix that, must be something borked somewhere." Nope. Still the issue. "But hey! Windows can partition drives, lets do that" (DONT'T DO THAT). I did. Windows created the partitions I wanted. "Hmm, parted must be broken". I once again booted the install media. parted /dev/sda print now printed like the following:

OEM partition (primary)
<blank> (primary, no info, and about as big as the OEM partition)
Windows recovery (primary)
Windows OS (primary, boot)

Oookay. I went to ##windows on freenode and was told "Just fire up a windows recovery disc and use the 'repair-startup' util". Sure. Did that. Parted now tells me I have something like the following:

Windows recovery (primary)
Windows OS (primary, boot)
<blank> (primary)

I lost my OEM-partition. huh...
Boot up windows just to see what it can see. The <blank> partition seems to be just unallocated space. Good.

Boot arch-install again. Partition my drive so it now looks like this:

[# ~] parted /dev/sda print
Model: ATA ST9750420AS (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type      File system  Flags
 1      41.9MB  830MB  789MB   primary   ntfs
 2      830MB   482GB  481GB   primary   ntfs
 3      482GB   750GB  268GB   extended               lba
 5      482GB   530GB  48.3GB  logical   ext4         boot
 6      530GB   750GB  220GB   logical   ntfs

Great! I didn't do the same stupid mistake and try and create 5 primary partitions.
1 is windows Recovery, 2 is Windows OS, 5 is linux OS, and 6 is my 'share-data-between-OSs-partition'.
And that's the end of the partitioning.

Post-partitioning, actual install

After my clumsy partitioning adventures, I proceed to actually install Arch. The install proceeds as any arch-install does with forgotting things you do and what nots but I finally get everything I wanted installed.
I use Grub2, because I've always used GRUB for non-EFI systems. Install it like the wiki says Beginners guide, Install bootloader BIOS/MBR
Time to reboot.

"Invalid partition table!"

Eh? ctrl+alt+delete (because reboots solve everything).
Still the error. Accidently presses some random key.

"Welcome to GRUB!" and grub loads just fine. I can see three boot-options, Arch, Arch fall back, and Windows.
So, GRUB obviously works. But when I boot I get the "Invalid partition table!" error (white text on black background).

I found this thread: https://bbs.archlinux.org/viewtopic.php?id=148467 and tried it's suggestions. Didn't work. And as that thread is from 2012, I didn't post in it because I don't like grave-digging.

I'm at a loss as to what to do to get rid of the "Invalid partition table!" error. The error itself isn't that bad, but it forces me to be active during the boot-process instead of just hitting the power button, go grab a cup of <insert hot beverage>, and come back to a booted system.

I've done some research of my own (ofcourse!) and I think I actually do have a messed up MBR, based on this:

[# ~] dd if=/dev/sda of=mbr.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00197697 s, 259 kB/s

[# ~] file mbr.bin
mbr.bin: DOS/MBR boot sector

Now, if the MBR had been proper, file mbr.bin should also have printed the partitions.

An example would be like this:

# file mbr.bin
mbr.bin: x86 boot sector;
partition 1: ID=0×83, active, starthead 1, startsector 63, 40949622 sectors;
partition 2: ID=0×82, starthead 254, startsector 40949685, 2088450 sectors;
partition 3: ID=0x8e, starthead 254, startsector 43038135, 74172105 sectors, code offset 0×48

It seems to me like Grub didn't write a correct MBR, and I have no idea how to fix that. So I'm looking for help on how to proceed.

I bet someone will ask for a fdisk output, so here it is:

[# ~] fdisk -l
Disk /dev/sda: 698.7 GiB, 750156374016 bytes, 1465149168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2365ebc1

Device     Boot      Start        End   Sectors   Size Id Type
/dev/sda1            81920    1622015   1540096   752M  7 HPFS/NTFS/exFAT
/dev/sda2          1622016  940851199 939229184 447.9G  7 HPFS/NTFS/exFAT
/dev/sda3        940851200 1465147391 524296192   250G  f W95 Ext'd (LBA)
/dev/sda5  *     940853248 1035155455  94302208    45G 83 Linux
/dev/sda6       1035157504 1465147391 429989888   205G  7 HPFS/NTFS/exFAT

Last edited by chewtoy (2016-01-04 07:42:22)

Head_on_a_Stick · 2015-12-30 13:35:42

chewtoy wrote:

It seems to me like Grub didn't write a correct MBR, and I have no idea how to fix that. So I'm looking for help on how to proceed.

What was the *exact* command that you used to install the GRUB loader to the MBR?

The simple answer here would seem to be to load up the Arch live ISO and re-install & re-configure GRUB but perhaps I'm missing something.

chewtoy · 2015-12-30 13:54:25

Head_on_a_Stick wrote:

What was the *exact* command that you used to install the GRUB loader to the MBR?

I followed the wiki, so, first I installed grub and os-prober:

 [# ~] pacman -S grub os-prober

Then, as the wiki says, I installed grub to /dev/sda (the drive, not a partition, and it's the only drive in my computer) with

[# ~] grub-install --recheck /dev/sda

And then, finally, I generated the grub.cfg with

[# ~] grub-mkconfig -o /boot/grub/grub.cfg

When I first got the issue, I though the same that I did something wrong.
After three tries I'm willing to rule out that I'm not following the instructions to the letter...

Head_on_a_Stick · 2015-12-30 13:58:06

OK, try again but use this variant:

# grub-install --target=i386-pc --recheck /dev/sda

This command explicitly specifies that the loader should be placed on the MBR and is suitable for use in 64-bit systems in spite of the confusing nomenclature

Note that you will have to be (arch-)chroot'd into the system with /boot mounted when running that command (it can be done without chroot'ing with extra flag options).

EDIT: I've just noticed that the bootable flag is set on your Arch partition -- try un-setting it.

# parted /dev/sda set 5 boot off # I think

I must admit that it's been so long since I've booted GNU/Linux in a non-UEFI system that I can't remember where the boot flag is supposed to be placed (if at all)

I think it should be fine to leave it unset but perhaps you should await the advice of those who know better than me.

Last edited by Head_on_a_Stick (2015-12-30 14:03:04)

chdslv · 2015-12-30 15:56:18

@chewtoy,

As your Arch install is in sda5, the boot flag is in the right place. Just reformat the sda6 partition to ext3, ext4 or ext2. As grub is already there, both Arch and Windows would boot up.

chewtoy · 2015-12-30 20:20:57

Head_on_a_Stick wrote:

OK, try again but use this variant:
# grub-install --target=i386-pc --recheck /dev/sda
This command explicitly specifies that the loader should be placed on the MBR and is suitable for use in 64-bit systems in spite of the confusing nomenclature
Note that you will have to be (arch-)chroot'd into the system with /boot mounted when running that command (it can be done without chroot'ing with extra flag options).
EDIT: I've just noticed that the bootable flag is set on your Arch partition -- try un-setting it.
# parted /dev/sda set 5 boot off # I think
I must admit that it's been so long since I've booted GNU/Linux in a non-UEFI system that I can't remember where the boot flag is supposed to be placed (if at all)
I think it should be fine to leave it unset but perhaps you should await the advice of those who know better than me.

I tried that. No dice. Still invalid MBR.

Also, the boot-flag should be set on the partition that hold the second stage boot loader, which is in /boot, that I have one sda5. For the MBR, the boot-flag isn't really of importance. The boot-flag is for GRUB, and GRUB works, it's just that I seem to have a errornus MBR. Meaning, I get a "Invalid partition error!" on boot, but I then push (the) any button and GRUB starts to load, and I can boot both Linux and Windows.

chdslv wrote:

@chewtoy,
As your Arch install is in sda5, the boot flag is in the right place. Just reformat the sda6 partition to ext3, ext4 or ext2. As grub is already there, both Arch and Windows would boot up.

What? How would that help fix my MBR?
I want sda6 to be NTFS, otherwise Windows can't read it. And both Arch and Windows already boots just fine.

My problem is that I get a warning before GRUB even starts. During POST I get "Invalid partition table!", I can then press any button on my keyboard and GRUB starts to load and I can boot Arch and Windows.

tom.ty89 · 2015-12-31 03:10:00

Can you paste a copy of your mbr? https://ptpb.pw/f

chewtoy wrote:

I've done some research of my own (ofcourse!) and I think I actually do have a messed up MBR, based on this:
[# ~] dd if=/dev/sda of=mbr.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00197697 s, 259 kB/s

[# ~] file mbr.bin
mbr.bin: DOS/MBR boot sector
Now, if the MBR had been proper, file mbr.bin should also have printed the partitions.
An example would be like this:
# file mbr.bin
mbr.bin: x86 boot sector;
partition 1: ID=0×83, active, starthead 1, startsector 63, 40949622 sectors;
partition 2: ID=0×82, starthead 254, startsector 40949685, 2088450 sectors;
partition 3: ID=0x8e, starthead 254, startsector 43038135, 74172105 sectors, code offset 0×48
It seems to me like Grub didn't write a correct MBR, and I have no idea how to fix that. So I'm looking for help on how to proceed.

FWIW this is probably normal. The reason `file` shows only "DOS/MBR boot sector" is because grub writes a "jump instruction" ("eb 63 90") at the very beginning to indicate where does the boot code start. If you zero-out the three bytes (or even just the first) of the dump then `file` will show you the partition info again: https://gist.github.com/tomty89/6630204c6be34f5e9206

If you can afford to re-install grub, you can also try to zero-out the 440 bytes of the MBR and see if you still get the warning. If so, then it does not have anything to do with grub. If not, then try to re-install grub and see if the warning comes back right away.

What I concern more are the partition type of the extended partition and the CHS addresses (which should normally be ignored anyway though). For example, this is what fdisk in linux creates:

DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x5,25,21), end-CHS (0x64,246,18), startsector 81920, 1540096 sectors; partition 2 : ID=0x7, start-CHS (0x64,246,19), end-CHS (0xc5,71,2), startsector 1622016, 939229184 sectors; partition 3 : ID=0x5, start-CHS (0xc5,71,3), end-CHS (0x41,52,51), startsector 940851200, 524296192 sectors

and this is what parted creates:

DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x5,25,21), end-CHS (0x64,246,18), startsector 81920, 1540096 sectors; partition 2 : ID=0x7, start-CHS (0x64,246,19), end-CHS (0x3ff,254,63), startsector 1622016, 939229184 sectors; partition 3 : ID=0xf, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 940851200, 524296192 sectors

Or maybe some problem in the extended boot record (EBR) or some leftover bytes on the fourth partition entry region.

Last edited by tom.ty89 (2015-12-31 07:45:36)

chewtoy · 2016-01-04 06:27:14

tom.ty89 wrote:

Can you paste a copy of your mbr? https://ptpb.pw/f
FWIW this is probably normal. The reason `file` shows only "DOS/MBR boot sector" is because grub writes a "jump instruction" ("eb 63 90") at the very beginning to indicate where does the boot code start. If you zero-out the three bytes (or even just the first) of the dump then `file` will show you the partition info again: https://gist.github.com/tomty89/6630204c6be34f5e9206

Ah. I see.
Unedited mbr: https://ptpb.pw/7mgA.bin
Edited mbr: https://ptpb.pw/G32z.bin

From the edited I now get this:

[# ~] file mbr.bin
mbr.bin: DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x5,25,21), end-CHS (0x64,246,18), startsector 81920, 1540096 sectors; partition 2 : ID=0x7, start-CHS (0x64,246,19), end-CHS (0x3ff,254,63), startsector 1622016, 939229184 sectors; partition 3 : ID=0xf, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 940851200, 524296192 sectors

tom.ty89 wrote:

If you can afford to re-install grub, you can also try to zero-out the 440 bytes of the MBR and see if you still get the warning. If so, then it does not have anything to do with grub. If not, then try to re-install grub and see if the warning comes back right away.

I'm unsure how to safely zero out the first parts though. dd'ing to sda seems... dangerous.
Do you have any suggestions on to how to do this safely?

tom.ty89 wrote:

What I concern more are the partition type of the extended partition and the CHS addresses (which should normally be ignored anyway though). For example, this is what fdisk in linux creates:
DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x5,25,21), end-CHS (0x64,246,18), startsector 81920, 1540096 sectors; partition 2 : ID=0x7, start-CHS (0x64,246,19), end-CHS (0xc5,71,2), startsector 1622016, 939229184 sectors; partition 3 : ID=0x5, start-CHS (0xc5,71,3), end-CHS (0x41,52,51), startsector 940851200, 524296192 sectors
and this is what parted creates:
DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x5,25,21), end-CHS (0x64,246,18), startsector 81920, 1540096 sectors; partition 2 : ID=0x7, start-CHS (0x64,246,19), end-CHS (0x3ff,254,63), startsector 1622016, 939229184 sectors; partition 3 : ID=0xf, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 940851200, 524296192 sectors
Or maybe some problem in the extended boot record (EBR) or some leftover bytes on the fourth partition entry region.

Hmm. Yes. It seems parted leaves more room between the partitions. Might it have to do with that parted reads 1kB as 1000B wheras fdisk reads 1kB as 1024B ? And their calculated sizes says that the partition should start at different sectors. Not sure how this should affect the MBR though.
Surely, you can create a disk with partitions that have a hugh gap in them and the MBR is still valid?

Partition     Sectors
    1           1-1000
    2           1001-2000
    3           8000-90000

This must surely be valid, no?

tom.ty89 · 2016-01-04 07:17:42

Well dd can always be dangerous, yes. The only way I can think of that is safer is, dd a mbr with grub code removed, instead of /dev/zero with bs=440 and count=1, so that dd won't keep on erasing your drive if you forgot the two options: https://ptpb.pw/gvco.bin
In any case, make sure you have an installation medium that allows you to install grub back.

Leaves more room? What are you talking about? The difference I pointed out is on how they write the CHS address differently when it can no longer represent the corresonding LBA because of the exceeded limit. fdisk write "truncated" CHS addresses (e.g. 940851200 -> 0xe4c5, 71, 3 -> 0xc5, 71, 3), while parted just write the maximum valid CHS for all of them (0x3ff,254,63).

But as I've said, it shouldn't matter anyway, the CHS addresses should simply be ignored unless your BIOS is really silly (or ancient?). So it's probably more about the partition type code of partition 3 (0x5 vs 0xf), or something in the EBR, which resides in the the gap between start of sda3 (940851200) and sda5 (940853248), and describes the logical partitions (sda5 and sda6). Maybe you can dump that out and attach it here too:

dd if=/dev/sda3 of=ebr.bin

Shouldn't need a count= option. Apparently dd would just dump 2 sectors (1KiB) for you this way.

It's true that parted use si unit to show partition information by default, but it doesn't really do alignment in a very different way from fdisk. You can check that by switching unit to binary ones or sector in parted to see that.

Last edited by tom.ty89 (2016-01-04 07:36:55)

chewtoy · 2016-01-04 07:34:33

Seems I solved it with the help from sheep in #archlinux
So just setting the boot-flag to be on sda1 instead of sda5 seemed to have fixed it.
My partition-tabel now looks like this:

[# ~] fdisk -l
Disk /dev/sda: 698.7 GiB, 750156374016 bytes, 1465149168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2365ebc1

Device     Boot      Start        End   Sectors   Size Id Type
/dev/sda1  *         81920    1622015   1540096   752M  7 HPFS/NTFS/exFAT
/dev/sda2          1622016  940851199 939229184 447.9G  7 HPFS/NTFS/exFAT
/dev/sda3        940851200 1465147391 524296192   250G  f W95 Ext'd (LBA)
/dev/sda5        940853248 1035155455  94302208    45G 83 Linux
/dev/sda6       1035157504 1465147391 429989888   205G  7 HPFS/NTFS/exFAT




Disk /dev/sdb: 1000.8 MiB, 1049362432 bytes, 2049536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x011dda2e

Device     Boot Start     End Sectors   Size Id Type
/dev/sdb1  *     2048 2049535 2047488 999.8M  c W95 FAT32 (LBA)

tom.ty89 · 2016-01-04 07:39:22

Didn't you already try unsetting the boot flag as Head_on_a_Stick told you to? Or do you mean it complains when no boot flag is set at all but not when it's set in sda1?

If that's the case your BIOS is indeed silly. Btw grub doesn't actually rely on the boot flag at all.

Last edited by tom.ty89 (2016-01-04 07:39:32)

chewtoy · 2016-01-04 11:44:33

tom.ty89 wrote:

Didn't you already try unsetting the boot flag as Head_on_a_Stick told you to? Or do you mean it complains when no boot flag is set at all but not when it's set in sda1?
If that's the case your BIOS is indeed silly. Btw grub doesn't actually rely on the boot flag at all.

Indeed. I needed a boot-flag set somewhere. Not having one didn't work. And having it on sda5 didn't work.
sda1 works though. Silly silly BIOS.

marcvangend · 2016-01-25 10:28:29

Awesome, thanks! I had a similar problem for months on my Dell Latitude: getting a "Invalid partition table!" warning on boot, but continuing smoothly after pressing a key. This thread finally helped me solve it.

Unlike the disk of the OP, mine is partitioned with GPT, but the boot flag was still the key to the solution. I added a boot flag to the disk (I guess GPT disks have the boot flag on the disk level instead of the partition level) running

# parted /dev/sda

and using the command

disk_toggle pmbr_boot

within parted. Problem solved.

Arch Linux

#1 2015-12-30 07:40:39