5

I cannot boot into GRUB. I see this:

Alloc magic is broken at XXXXXX Press any key

but when I do nothing happens. Holding shift doesn't do anything either.

The last time I could use my machine I changed stuff in /etc/grub.d, but I chrooted into the system, reverted everything and successfully ran update-grub.

What can I try?

If anyone wondering: Ubuntu 12.04.1, Installation media was (I guess) 11.10, it's an i5-first generation kernel, 4GB RAM, memtest was okay.

1
  • 1
    You should run memtest to verify, that faulty main memory isn't the root cause of this. Apr 6, 2015 at 19:26

9 Answers 9

3

A Boot-Repair Live USB can be used to repair Grub. You can download the ISO from the Ubuntu Wiki. Then, use Unetbootin to create a Live USB from the ISO file you downloaded. After you boot from the USB, the Boot Repair utility will pop up. Just click on the Recommended Repair button, and Boot-Repair will repair Grub for you.

1
  • 1
    I did that. Changed nothing. It did give come "advice", but nothing which should prevent GRUB from starting, and nothing which wouldn't be the same since the original installation.
    – mrs_sheep
    Sep 3, 2012 at 15:01
1

This is not a software issue, The alloc magic broken error is a result of bad memory chips.

1

I ran into this error recently when I partially wiped a member of a zfs pool accidentally. On a 6TB member disk, I wiped roughly 200GB before realizing I started wiping the wrong disk. ZFS did what it does and marked it as faulted after finding a bunch of checksum errors as you would expect (though it did attempt to resilver them).

On next boot, that drive faulted stating the label was missing. No big deal I thought. I just ran 'parted' and did a 'mklabel gpt' on it. Interestingly enough, the drive sprung to life again and began resilvering. However it eventually faulted again for the same checksum issue.

Scrubbing always failed with that drive being faulted shortly afterwards. I figured I would replace it on next boot later in the day as this was a non-production system. Wouldn't you know it, subsequent boots would fail with this 'alloc magic' error. At first I did not equate this problem to the drive I managed to convert into magnetic confetti with my antics. After disconnecting this drive (1 of around 60) and ONLY this drive, the error disappeared and I was able to replace the drive successfully.

So yeah, don't partially wipe stuff and think zfs will make it healthy. But I will praise zfs for its resiliency for the rest of the pool and its never-give-up attitude with trying to fix broken things.

0

I have solved this.

I used Rescatux and mainly SG2D to chainboot into my regular system. I then ran update-grub again and was wondering again why it would list everything twice, when it occurred to me to check the grub.cfg (just read, not write!).

I then found out that the supposedly "reverted" changes to the GRUB-config were still there preventing grub from starting.

(I had named the not-working ones .n for "new" assuming they would be ignored (like .bak))

SO: is it a valid bug to be posted, that reinstallation of GRUB does not clear the config dir?

1
  • AFAIK, reinstalling packages typically does not replace or clear their config files by default, by design, so it would be a feature request if you wanted it to be changed...
    – Zanna
    Aug 25, 2017 at 9:35
0

perhaps the iso file was made in a 32-bit computer, and the error comes from trying to boot it form a 64-bit one!!?

I had that issue! and I guess that was the cause!

0
0

I had the same problem, but with a different cause. I my case I had to do a boot repair of windows (download iso from MS; go into repair; go into terminal; bootrec /fixboot for details google.)

Hope this helps someone.

0

I started having the same issue when using the latest version of Rufus and iso of Ubuntu 16 (Paladin 7.08). I used the previous version of Rufus (3.8) and in worked for me. Although I had another error (with graphics), but that’s another story. Hope that helps someone.

0

This error can also happen when you have chosen the option to encrypt the entire disk when installing Ubuntu. If this is the case and you have secure boot enabled, there is no need to disable secure boot. Just go into BIOS and search for the option which allows you to setup a trusted file for EFI boot. One of these files will be shimx64. Choose that file and save and exit BIOS. Get into BIOS again, and you'll see the shim option in the boot priority menu. Move it to the topmost position. Save and exit BIOS. This time, it'll boot fine. The shim is a preloader that connects to grub.

0

Adding another possibility onto this, this time this error came up for me on 22.04 after I inserted a disk from a deprecated ZFS pool I planned to format. This error came up immediately.

There was nothing wrong with grub, or the disk, in any way. All I had to do was pull the old ZFS disk, and then boot, then hotplug it and format.

For context my system is not configured with ZFS, and grub had never seen this disk or had any configuration to even look at it. Adding an old ZFS formatted disk into a system without formatting it seems to be enough to break grub.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .