Alloc magic is broken astra linux

Thread: Grub problem: «alloc magic is broken»

Thread Tools
Display

Grub problem: «alloc magic is broken»

I have an ASUS X54C that client has asked me to take a look at.

When I turn the system on I get the following message:

I am able to access the grub menu itself by holding shift, but choosing any entry from the list produces the same message. The only other thing that I can do is access the grub’s command prompt by pressing ‘c’. Any way to repair this from the command line?

Re: Grub problem: «alloc magic is broken»

Post the bootscript run this command set it will be in home as the results.txt use a live cd, and wrap it in codetags.

The chroot below may work, I have never seen this error before but the web does show some hits, I would look at google a bit before doing anything myself.

Last edited by wilee-nilee; June 12th, 2012 at 04:45 AM .

Re: Grub problem: «alloc magic is broken»

Use a Live CD
chroot in to the installed system
run synaptic, fix broken packages
then update grub

Re: Grub problem: «alloc magic is broken»

When you say «chroot into the installed system» could you tell me exactly what that means/how to do that please? This is a unique first for me I think.

Re: Grub problem: «alloc magic is broken»

You CD must be the same Arch as install ie; 64 or 32 bit

Re: Grub problem: «alloc magic is broken»

You CD must be the same Arch as install ie; 64 or 32 bit

This is what it looks like.

Just passing the info on.

Re: Grub problem: «alloc magic is broken»

I think I figured out the problem with this laptop. I booted into the RAM testing utility from a Live CD and discovered that the RAM is faulty. But here’s the kicker. This laptop’s factory RAM is built into the motherboard and is non-removable. Yet another reason I’ll never buy a laptop from Asus. Thanks for your help everybody. Sorry for the goose chase.

Источник

Ошибка установки Ubuntu: неверный магический номер. alloc magic нарушается на 0 × 87034480: 86dda600 отменено. Нажмите любую клавишу для выхода. «[Duplicate]

Я не могу загрузиться в GRUB. Я вижу это:

Alloc magic is broken at XXXXXX Press any key

, но когда ничего не делаю. Сдвиг переноса тоже ничего не делает.

В последний раз, когда я мог использовать свою машину, я изменил материал в /etc/grub.d, но я запустил систему, вернул все и успешно побежал update-grub.

Что я могу попробовать?

Если кому-то интересно: Ubuntu 12.04.1, установочный носитель был (я думаю) 11.10, это ядро ​​первого поколения, 4 ГБ оперативной памяти, memtest было в порядке.

4 ответа

Для восстановления Grub можно использовать Boot-Repair Live USB. Вы можете загрузить ISO из Ubuntu Wiki. Затем используйте Unetbootin для создания Live USB из загруженного ISO-файла. После загрузки с USB появится всплывающая утилита Boot Repair. Просто нажмите кнопку «Рекомендуемый ремонт», и Boot-Repair восстановит Grub для вас.

Читайте также:  Windows task manager all users

Это не проблема с программным обеспечением, ошибка alloc magic broken является результатом ошибок в чипах памяти.

возможно, файл iso был сделан на 32-битном компьютере, и ошибка возникает из-за попытки загрузить его из 64-битного!?

У меня была эта проблема! и я думаю, что это было причиной!

Я использовал Rescatux и, главным образом, SG2D, чтобы подключиться к моей обычной системе. Затем я снова запустил update-grub и снова задался вопросом, почему он перечислил все дважды, когда мне пришло в голову проверить grub.cfg (просто читать, а не писать!).

Затем я узнал, что якобы «вернувшиеся» изменения в GRUB-config все еще были там, чтобы предотвратить запуск grub.

(Я назвал неработающих .n для «новых», считая, что они будут проигнорированы (например .bak))

SO: это допустимая ошибка для публикации, что переустановка GRUB не очищает конфигурационный каталог?

Источник

grub fails with message «free magic broken» or «alloc magic broken» #2284

Comments

ajeddeloh commented Dec 9, 2017

Issue Report

Container Linux Version

1618.0.0 and newer

Environment

qemu, possibly others

Expected Behavior

appending to the kernel command line via editing the grub menu does no prevent the system from booting.

Actual Behavior

Appending to the kernel command line prevents the system from booting. grub exits with the error message: free magic is broken at 0x3cec8166: 0xcfc53e26 (actual addresses vary)

Reproduction Steps

  1. Build a Container Linux image
  2. run the generated coreos_production_qemu.sh script
  3. when the grub menu appears, edit the first entry and append something to the linux command like (e.g. «aaaaaaaaaaaaaaaaaaaaa»)
  4. Press ^X to boot
  5. observe free magic is broken at. message

Other Information

This was introduced with changing /boot to fat32. It may be a bug in our image creation or in grub itself.

It is present with our current alpha images, and in master. Sometimes the error message is repeated, especially when building off master, although that is probably coincidence.

The text was updated successfully, but these errors were encountered:

ajeddeloh commented Dec 9, 2017

Reviewed dosfstool’s changelog, nothing jumped out at me as a culprit.

I mounted the boot partition from an affected and non-affected image:

ajeddeloh commented Dec 9, 2017 •

Log from booting alpha. I went into the grub command line a set debug=all .

Edit: built new images today (qemu, qemu_uefi); they did not trigger this bug. Tested with the qemu_uefi platform from current alpha and from the same image that failed with the qemu platform (1618.0.0) and it also did not trigger the bug. The normal qemu platform still does.

ajeddeloh commented Dec 18, 2017

After about of week of digging I still haven’t been able to find the problem. Here is what I did find:

  • grub crashes with bad free magic or bad alloc magic
  • The bug is present in all CL channels
  • It only occurs when bios booting (although this is not heavily tested)
  • It does not matter if /boot is fat16 or fat32
  • A given image/build will succeed or fail deterministically
  • Running build_image multiple times is deterministic; If the state of your repos produces a succeeding build, it will always succeed. If they produce a failing build they will always fail.
  • I do not know what makes a given build/image succeed or fail
  • images with the cmdline appended via kola mkimage work
  • On some images just entering the menu editor then booting (via ^X ) is enough to trigger the bug. On other images you need to append to the menu item. Some images require several lines of text appended.
  • running grub_install.sh —target i386-pc —disk_image

fixes it

  • rerunning just the i386-pc target works
  • rerunning all the targets works
  • rerunning all targets except i386-pc does not work; i386-pc MUST be run
  • grub_install.sh can be run directly on the image or on a loop-mounted image
  • Rerunning grub_install.sh only changes the boot partition. All other partitions, the boot sector and the embedding area (sectors 34-4095) are unchanged.
  • Running grub-install.sh creates different boot partitions, probably due to timestamps.
  • reformatting /boot without rerunning grub-install causes it to fail to boot with «invalid gpt signature»
    • The grub config that gets loaded first looks for the uuid of the boot partition as originally created. This can be changed to search.fs_label for debugging purposes
    • If grub_install.sh is modified to use labels instead of uuids, then reformatting /boot and copying the files back works.
  • fcsk.fat sees no errors
  • dosfstools 4.1 and 3.x behave the same
  • testdisk claims the fat partitions are bad, but using testdisk to fix them has no effect
  • the stack is not colliding with the heap (edited debug messages to print an approximate sp)
  • editing files on a broken /boot has no effect
  • all of our modules ( gptprio , efilinux , search_part_label , getenv , smbios ) can be disabled in grub_install and the system will still boot, since they can be dynamically loaded from /boot
  • I have not been able to reproduce the issue with vanilla grub. Testing this requires removing all coreos modules in the CORE_MODULES list in grub_install.sh and always booting from USR-A (since the default menu entry uses gptprio )
  • Running git-bisect was not productive since there are sometimes builds that do not trigger the bug but still «carry» the bug.
  • Читайте также:  Unix среда под windows

    glevand commented Dec 19, 2017

    @ajeddeloh That error comes from grub’s memory manager code: https://github.com/coreos/grub/blob/master/grub-core/kern/mm.c#L205, so the problem seems to be memory corruption of the grub_mm_header_t.

    A Web search for free magic is broken gives a lot of hits. I did find this one fix: http://lists.gnu.org/archive/html/grub-devel/2008-01/msg00830.html.

    I suggest you put a hardware breakpoint on write to the grub_mm_header_t.magic address and see if you can figure out what is writing to it. You may need to find a qemu cpu emulation that supports hardware write breakpoint.

    ajeddeloh commented Dec 22, 2017

    Thanks for the suggestion, I’ll give that try after the holidays.

    Источник

    UEFI GRUB: Alloc Magic is Broken (won’t boot)

    zoomzoom

    Neophyte Sage

    Attachments

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U2 | < PNY Turbo USB3 32GB (2) > Mirror

    Windows
    Alienware 18 | Intel 2.5gHz 4C i7 4710MQ, OC’d 3.5gHz
    32GB Corsair Vengeance 1.35v | 8GB AMD SLI R9 M290x
    SSD | Samsung 850 EVO: 1TB ; mSATA: 1TB (2)
    Windows 10 Pro

    ESXi
    In Win Chopin | SuperMicro A1SRi-2758F | Intel 2.4gHz 8C Avoton C2758
    32GB Kingston KVR16LSE11 ECC 1.35v
    SSD | Samsung 850 Pro 128GB ; EVO mSATA: 1TB
    ESXi | Sophos UTM 9.5

    Ericloewe

    Not-very-passive-but-aggressive

    zoomzoom

    Neophyte Sage

    In my signature =]

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U1| < PNY Turbo USB3 32GB (2) > Mirror

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U2 | < PNY Turbo USB3 32GB (2) > Mirror

    Windows
    Alienware 18 | Intel 2.5gHz 4C i7 4710MQ, OC’d 3.5gHz
    32GB Corsair Vengeance 1.35v | 8GB AMD SLI R9 M290x
    SSD | Samsung 850 EVO: 1TB ; mSATA: 1TB (2)
    Windows 10 Pro

    ESXi
    In Win Chopin | SuperMicro A1SRi-2758F | Intel 2.4gHz 8C Avoton C2758
    32GB Kingston KVR16LSE11 ECC 1.35v
    SSD | Samsung 850 Pro 128GB ; EVO mSATA: 1TB
    ESXi | Sophos UTM 9.5

    zoomzoom

    Neophyte Sage

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U2 | < PNY Turbo USB3 32GB (2) > Mirror

    Читайте также:  Astra linux автоматический вход

    Windows
    Alienware 18 | Intel 2.5gHz 4C i7 4710MQ, OC’d 3.5gHz
    32GB Corsair Vengeance 1.35v | 8GB AMD SLI R9 M290x
    SSD | Samsung 850 EVO: 1TB ; mSATA: 1TB (2)
    Windows 10 Pro

    ESXi
    In Win Chopin | SuperMicro A1SRi-2758F | Intel 2.4gHz 8C Avoton C2758
    32GB Kingston KVR16LSE11 ECC 1.35v
    SSD | Samsung 850 Pro 128GB ; EVO mSATA: 1TB
    ESXi | Sophos UTM 9.5

    Ericloewe

    Not-very-passive-but-aggressive

    Anyway, this seems to be squarely a GRUB problem. Since multiple installs haven’t solved the problem (I assume you wiped the boot drive between these attempts), try a different boot device. Also make sure that the ISOs match their posted checksums.

    zoomzoom

    Neophyte Sage

    The issue is UEFI and GRUB, as it appears there’s a misconfiguration of GRUB to load a UEFI install. Selecting BIOS as the install method works perfectly fine.

    I’ll open a bug report in the morning and post the link.

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U2 | < PNY Turbo USB3 32GB (2) > Mirror

    Windows
    Alienware 18 | Intel 2.5gHz 4C i7 4710MQ, OC’d 3.5gHz
    32GB Corsair Vengeance 1.35v | 8GB AMD SLI R9 M290x
    SSD | Samsung 850 EVO: 1TB ; mSATA: 1TB (2)
    Windows 10 Pro

    ESXi
    In Win Chopin | SuperMicro A1SRi-2758F | Intel 2.4gHz 8C Avoton C2758
    32GB Kingston KVR16LSE11 ECC 1.35v
    SSD | Samsung 850 Pro 128GB ; EVO mSATA: 1TB
    ESXi | Sophos UTM 9.5

    Ericloewe

    Not-very-passive-but-aggressive

    zoomzoom

    Neophyte Sage

    It’s also not isolated to the two PNY (USB3) drives, as I also tried two different SanDisk (USB2) drives, and a 120GB 850 EVO. All four USB drives, if installed with UEFI selected in the installer, failed with the alloc magic error, but if BIOS was selected in the installer, booted fine.

    Even weirder, with the 11.1 install media, when I installed to the 850 EVO, which had previously been apart of a single drive pool for backup logs, the install would complete successfully, but when it went to boot, it came up as (paraphrasing) «this drive is a NAS drive», like it’s still apart of a pool, and refused to boot. I installed to it twice and each time, the same error.

    • I did verify each time that I was indeed selecting the 850 EVO, as it became far more efficient to simply load the boot menu and select a drive, rather than go in the BIOS each time I tried a different boot disk.

    These two things seem to imply there’s something wrong with GRUB in the 11.1 install media that causes issues when selecting UEFI install inside the installer, or when it updates a UEFI 11.0 install to a UEFI 11.1 install through the WebUI.

    I’ll repeat the installs tomorrow in order to provide a comprehensive bug report. Do I need to record everything via the jviewer, or is there a way to log all install activity from the point the installer loads through to when it reboots?

    FreeNAS
    SilverStone DS380 | AsRock C2750D4I | Intel 2.4gHz 8C Avoton C2750
    32GB Crucial CT5008061 U-ECC 1.35v | StarTech PEXESAT322I
    SSD | Samsung 850 EVO 120GB
    2.5″ | < HGST: HTS721010A (3) > Z1
    3.5″ | < WD: WD60EFRX (2) | Seagate: ST5000DM00 (2) ; ST4000DM00 (3) > Z2 ; < ST4000VN000 (8) >Z2
    FreeNAS 11-U2 | < PNY Turbo USB3 32GB (2) > Mirror

    Windows
    Alienware 18 | Intel 2.5gHz 4C i7 4710MQ, OC’d 3.5gHz
    32GB Corsair Vengeance 1.35v | 8GB AMD SLI R9 M290x
    SSD | Samsung 850 EVO: 1TB ; mSATA: 1TB (2)
    Windows 10 Pro

    ESXi
    In Win Chopin | SuperMicro A1SRi-2758F | Intel 2.4gHz 8C Avoton C2758
    32GB Kingston KVR16LSE11 ECC 1.35v
    SSD | Samsung 850 Pro 128GB ; EVO mSATA: 1TB
    ESXi | Sophos UTM 9.5

    Источник

    Оцените статью