Error invalid magic number ubuntu

I installed Ubuntu 20.04 on a fresh SSD. This motherboard has other harddrives with, for example, windows on them. My installation went fine and I was working all day yesterday on this install. I can’t recall for sure, but I believe I restarted a few times, for updates and the like, and booted back into Ubuntu 20.04 no problem. What I didn’t do was ever launch back into windows until the end of the night. I shut the system down after that, and this morning tried to launch back into Ubuntu 20.04. I mention this because some of my research indicated Windows can sometimes mess with boot filesystems.

Note that the below issues all occurred identically both before and after I ran fsck on the ssd from a temp Live Ubuntu thing, even though apparently fsck found a large volume of errors. Before fsck, the drive was unmountable in that Live Ubuntu, after, it was mountable, and I could grab some files I needed this morning.

If I try to select «Ubuntu» in my Grub menu, I get the error:

Error: Invalid Magic Number
Error: You need to load the kernel first

If I drop into the console, I can see my file system no problem.

ls (hd3,gpt2/)
lost+found/, boot/ ...etc

In my boot/, there is

efi/
grub/
System.map-5.4.0-26-generic
config-5.4.0-26-generic
initrd.img
initrd.img.old
memtest86+.bin
memtest86+elf
memtest86+_multiboot.bin
vmlinuz
vmlinuz.old
vmlinuz-5.4.0-26-generic 
vmlinuz-5.4.0-48-generic <-- this is the one I'm trying to use
initrd.img-5.4.0-26-generic
config-5.4.0-48-generic
System.map-5.4.0-48-generic
initrd.img-5.4.0-48-generic

If I do file on these, I get weird results:

file (hd3,gpt2)/boot/vmlinuz-5.4.0-48-generic
error: invalid arch-independent ELF magic

file (hd3,gpt2)/boot/initrd.img-5.4.0-48-generic
error: invalid arch-independent ELF magic

At this point my potential research points have branched enough to make me think I should ask on stackexchange what next steps I can try. For example, the two most common ubuntu stackoverflow answers get the «invalid arch-independent ELF magic» directly from grub (or grub-rescue?) it seems. Also, every other «invalid magic number» answer on reddit and stackexchange involve Live CD type things running directly off a flashdrive, and the solution is always «use a different flash drive / installation creation tool.»

Note that the above commands and responses were hand-typed so while I double checked I may have mis-typed something.

How can I boot into 20.04 again, ideally without re-installing or losing my files?

Experiments below:

I tried Live USB error «you need to load the kernel first» :

First answer doesn’t work, if I do

linux /boot/vmlinuz-5.4.0-48-generic root=/dev/sdb2

I get

error: invalid magic number

Second answer doesn’t work. I’m not in secure-boot mode.

The third answer didn’t work, I’ve tried disconnecting all USB devices to no avail.

I saw some things online about EFI mode. In my grub menu, I see UEFI Firmware Settings as an option, I’m not sure if that indicates I’m in UEFI «mode» or not. Based on what I’m looking at in my bios menu, I believe I’m in UEFI mode.

I tried the most-given solution to invalid arch-independent ELF magic error (across various Stackexchange questions)

sudo mount /dev/sdb2 /mnt
sudo grub-install --root-directory=/mnt /dev/sdb2
Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.
grub-install: error: will not proceed with blocklists. 

EDIT: I ran the oft-recommended boot repair tool, this is the output: http://paste.ubuntu.com/p/H86ZBpr9Sr/

Now the error is

error: invalid magic number
alloc magic is broken at 0xb7855240: b779dc00
Aborted. Press any key to exit.

Arch Linux

You are not logged in.

#1 2021-06-02 18:43:41

[SOLVED] Invalid magic number on boot

after a system upgrade including linux and linux-headers my system stopped working.

I’ve already tried to reinstall linux and linux-headers, tried `mkinitcpio -P`, to rebuild my grub config and to reinstall grub. Everything without error messages.

Some weeks ago I had the same issue, but here everything was fine again after I reinstalled linux and linux-headers.

I’ve used the grub command line. I’m not sure if I used it correctly or if it is a hint:

It is a btrfs filesystem and it works.

I hope someone has an idea.

EDIT: My solution was to upgrade grub to 2.06 RC1. Details are in the thread.

Last edited by bysom (2021-06-07 19:52:23)

#2 2021-06-02 20:06:13

Re: [SOLVED] Invalid magic number on boot

Suggests /boot/vmlinuz-linux is corrupt.
Is the boot partition full (no space left)?
What dow «file /boot/vmlinuz-linux» say and what is the md5 of the file?
If thereÄs enough space, can you isntall and boot the lts kernel?

#3 2021-06-03 09:26:48

Re: [SOLVED] Invalid magic number on boot

Hi, thanks for your answer.

There is enough space, since i have no extra /boot partition. I’ve encrypted my entire system including /boot. Therefore I have an extra efi partition with grub, that decrypts my btrfs and then boots the kernel. Mostly like it is described in the Wiki

I’ve also installed the lts kernel. Both aren’t working.

Here the md5 sums

I’ve also tried a `btrfs check` without errors.

Thanks for your help!

#4 2021-06-03 13:42:56

Re: [SOLVED] Invalid magic number on boot

It would seem that either the decryption fails or maybe is just too slow
Can you «ls» the partition after «insmod btrfs»?

#5 2021-06-03 17:30:34

Re: [SOLVED] Invalid magic number on boot

Okay, I have some results.

After the cryptomount command:

I have tried a `ls /@/boot` after the `echo ‘Loading Linux linux-lts . ‘` and it lists the files in my /boot directory. After that I have tried a `file —is-x86-linux /@/boot/vmlinuz-linux` and got no result (and also no error). Is there something else I should try?

#6 2021-06-03 18:37:26

Re: [SOLVED] Invalid magic number on boot

I’ve tried a `sleep 30` before loading the kernel, which hasn’t changed anything.

After that I have chrooted my arch again and reinstalled linux, linux-lts, and the headers and now something changed. If I try to boot the LTS kernel it passes the ‘Loading Linux linux-lts . ‘ section and then I get a kernel panic in the following ‘Loading initial ramdisk . ‘ section. The error message before the kernel panic is

The normal linux kernel still fails at the first section ‘Loading Linux linux . ‘

Last edited by bysom (2021-06-03 18:38:35)

#7 2021-06-04 05:19:17

Re: [SOLVED] Invalid magic number on boot

Re-cap:
This is a regression, the config used to work befoer?
The files end on the encrypted partition intact, ie. they’re perfectly accessible offline?
The error has a degree of randomness, eg. vmlinuz-linux-lts (now) loads, but the other files have bad header bytes?

What else was included in the breaking udpate? /var/log/pacman.log?

returns a boolean.

#8 2021-06-04 14:48:33

Re: [SOLVED] Invalid magic number on boot

Yes, your recap sounds correct. The config worked before, I can access my files and the error seems to have some kind of randomness.

Here is the pacman log from the last update before the crash: http://ix.io/3oJJ

#9 2021-06-04 14:55:54

Re: [SOLVED] Invalid magic number on boot

cryptsetup sticks out…
Downgrade that, re-install the kernels and see what happens.

BE PREPARED TO LOSE ACCESS TO THE … oh, wait: you can’t boot and will have to chroot anyway

#10 2021-06-04 17:48:05

Re: [SOLVED] Invalid magic number on boot

I’ve downgraded to cryptsetup 2.3.4 and the error is still the same.

Is this setup with an encrypted boot partition that rare, that it could be a bug in grub or somewhere else? The idea to reinstall my arch with a classical encryption setup gets more and more attractive for me. Unless you have still some good ideas. I’m still very happy with your help

#11 2021-06-04 20:40:21

Re: [SOLVED] Invalid magic number on boot

Did the kernel re-installation change anything about the randomness aspect of the kernel/initramfs «corruption»?
And otherwise, how the status is at the grub shell (ie. testing the file types there) in case this is -somehow- a time/race condition…

#12 2021-06-05 20:23:24

Re: [SOLVED] Invalid magic number on boot

Hi, I have some news.

To your questions: The kernel reinstallation made that the error occours at the ‘Loading Linux linux-lts . ‘ again for the lts kernel which made it to the initramfs loading. As far as I remember this state changed with the reinstallation of the kernel.

I have tried your ‘if file xy then’ example and it obviously returned a false value. I’ve got a ‘kernel is bad’ because I’ve added an else case. It should have been true, right?

After that I saw, that I can use md5sum with grub and checked the md5 sum of the kernel and got a different number than I get from my live system.

From a live linux

I have asked someone else with an arch linux for a hash sum as a reference and got the 8ed348f0125772a6ef0756b818199fc6 for the actual kernel.

(I’ve updated the kernel yesterday)

Then I’ve used cat with grub to view some text files which all looked normal to me. After that I’ve used md5sum on one of these files and got the same hash numbers with grub and with my live stick.

Last edited by bysom (2021-06-05 21:33:05)

#13 2021-06-05 22:33:50

Re: [SOLVED] Invalid magic number on boot

If you change the mkinitcpio compression (in doubt to «cat»), do the md5sums for those turn consistent?
https://wiki.archlinux.org/title/Mkinitcpio#COMPRESSION

#14 2021-06-06 12:13:21

Re: [SOLVED] Invalid magic number on boot

Hi, I have changed that compression to cat and reinstalled the kernels.

The md5 sums from my live linux (ubuntu 20.04, Kernel 5.8.0, cryptsetup 2.2.2, btrfs-progs v5.4.1). Those from my chrooted arch are the same.

The md5sums from grub

That ones from the initramfs are correct. And that one from the linux is different now.

Last edited by bysom (2021-06-06 12:18:59)

#15 2021-06-06 12:34:36

Re: [SOLVED] Invalid magic number on boot

Smells as if the grub btrfs module doesn’t like compressed files (at least not zstd)?
If you check a random zstd compressed file from the grub shell, does its md5 deviate?
Or do you maybe use https://wiki.archlinux.org/title/Btrfs#Compression ?

#16 2021-06-06 21:57:33

Re: [SOLVED] Invalid magic number on boot

Yes, I’m using btrfs compression with zstd.

I’ve checked the results with a normal file

Linux point of view

grub point of view

Both files are different here. There could be some randomness, I think.

Last edited by bysom (2021-06-06 22:27:06)

#17 2021-06-06 22:03:11

Re: [SOLVED] Invalid magic number on boot

What if you «chattr -c /boot» and update the kernel?

Edit: also notice the warning and to have grub-install post 2019-07-05

Last edited by seth (2021-06-06 22:06:14)

#18 2021-06-07 19:45:18

Re: [SOLVED] Invalid magic number on boot

Hi, I have tried that chattr -c /boot thing and it hasn’t changed anything. After that I have checked the md5sums with grub again and got for one file an error message containing ‘error: zstd data corrupted.’. After that I have repeated that btrfs check just in case without errors.

Since the error only occurred with grub and there is already a rc1 for the next grub release, which seems to be really rare, I thought that I could try grub-git from the aur (what if it is a grub bug and no one fixes it before the release, was my first thought). So I installed grub-git, then executed grub-install, restored the grub config and got a booting system. I’m a bit happy now. And I am very thankful for your help and your patience, seth! A very positive experience. Let me know if I can do something in reward.

#19 2021-06-07 19:47:19

Re: [SOLVED] Invalid magic number on boot

Let me know if I can do something in reward.

Please always remember to mark resolved threads by editing your initial posts subject — so others will know that there’s no task left, but maybe a solution to find.
Thanks.

#20 2021-06-07 19:49:57

Re: [SOLVED] Invalid magic number on boot

Of course

Last edited by bysom (2021-06-07 19:54:38)

Источник

«Неверное магическое число, сначала необходимо загрузить ядро» в существующей и ранее работающей установке Ubuntu (не проблема с живым USB)

Я установил Ubuntu 20.04 на новый SSD. На этой материнской плате есть и другие жесткие диски, например, с windows. Моя установка прошла нормально, и я вчера весь день работал над этой установкой. Я не могу вспомнить наверняка, но думаю, что перезапускал несколько раз, для обновлений и т.п., и без проблем загрузился обратно в Ubuntu 20.04. Чего я не делал, так это никогда не запускал обратно в окна до конца ночи. После этого я выключил систему и сегодня утром попытался снова запустить Ubuntu 20.04. Я упоминаю об этом, потому что некоторые из моих исследований показали, что Windows иногда может вмешиваться в загрузочные файловые системы.

Обратите внимание, что все перечисленные ниже проблемы возникли одинаково как до, так и после того, как я запустил fsck на ssd из временного Live Ubuntu, хотя, очевидно, fsck обнаружил большой объем ошибок. До fsck в Live Ubuntu диск был отключен, после этого он был монтируемым, и я мог получить некоторые файлы, которые мне понадобились сегодня утром.

Если я попытаюсь выбрать «Ubuntu» в меню Grub, я получаю сообщение об ошибке:

Если я захожу в консоль, я вижу свою файловую систему без проблем.

В моем boot/ есть

Если я сделаю file на них я получаю странные результаты:

На данный момент мои потенциальные точки исследования достаточно разветвились, чтобы заставить меня подумать, что я должен спросить у stackexchange, какие следующие шаги я могу попробовать. Например, два наиболее распространенных ответа на переполнение стека в ubuntu получают «недействительную магию ELF, независимую от архитектуры» непосредственно из grub (или grub-rescue?) Кажется. Кроме того, любой другой ответ «недействительный магический номер» на Reddit и stackexchange включает в себя вещи типа Live CD, работающие непосредственно с флэш-накопителя, и решение всегда «использовать другой флэш-накопитель / инструмент для создания установки».

Обратите внимание, что приведенные выше команды и ответы были набраны вручную, поэтому, пока я дважды проверял, я мог что-то напечатать неправильно.

Как я могу снова загрузиться в 20.04, в идеале без переустановки и потери файлов?

Первый ответ не сработает, если я сделаю

Второй ответ не работает. Я не в режиме безопасной загрузки.

Третий ответ не сработал, я безуспешно пытался отключить все USB-устройства.

Я видел кое-что в Интернете о режиме EFI. В моем меню личинок я вижу UEFI Firmware Settings как вариант, я не уверен, означает ли это, что я нахожусь в «режиме» UEFI или нет. Судя по тому, что я смотрю в меню BIOS, я считаю, что нахожусь в режиме UEFI.

Я попробовал наиболее подходящее решение для invalid arch-independent ELF magic ошибка (по различным вопросам Stackexchange)

Источник

System boot error : invalid magic number #505

Hi,
I am using ventoy 1.0.20, on a physical hard drive.
When I try to UEFI boot debian 10.5 (live+gnome), I choose the iso, then I have the grub boot menu, select default entry, and I have these errors :

I am still searching for more information on how to fix this (even with a bios config. ), but still no luck.

Does anyone have any idea ?

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

I have the same.

ubuntu-21.04-desktop-amd64.iso and ventoy 1.0.53

This is an old issue. I will close it now.
If you still have problem with latest Ventoy release, you can reopen the issue.

Same problem, 1.1.0.64 release, trying bodhi linux, but no tried other images with no success.

Ventoy-1.070:

debian-live-11.2.0-amd64-kde+nonfree.iso (includes microcode for non-free hardware) does not work, while debian-live-11.2.0-amd64-kde+nonfree.iso works

No problems with ubuntu (kubuntu 20.04/21.10, neon-user, ubuntu 20.04/21.10)

Q: can this issue be reopened?
@abuGit did you do a checksum of it from in Ventoy (press M)?

Yes; I did a md5sum check on the usb device. The strange thing is that debian-live-11.2.0-amd64-kde+nonfree.iso is the only iso which dont work (and I use many

Ventoy version 1.0.70
Same problem, with isos of:
Debian, Slackware, Zorin OS, Kubuntu. Linux Mint

Did you press m when booted to Ventoy to check the hash value of all of the ISOs and check matches the published values?
Is the memory of your computer reliable (perform a memory test).

Did you press m when booted to Ventoy to check the hash value of all of the ISOs and check matches the published values? Is the memory of your computer reliable (perform a memory test).

The hash values changed when checking in ventoy with the built in tool, but the hash value of the iso matched the published one when I downloaded it (Tested with latest Ubuntu iso). My computer’s memory is definitely reliable.

Check the hash value of the files on the usb drive under Windows or Linux
If bad then usb file is corrupt.
If good then usb I/o reads may be the problem.
Report back which it is

Checked, the hash of the iso file is still correct when first pasting the iso into the ventoy usb, I’ll check if it changes after I try and boot it and report back.

Using m in Ventoy will use bios usb driver, using windows or Linux will use OS usb driver. That is why you need to check same file on usb drive using both m in Ventoy and using an os. Do not overwrite the file until you check with both methods.

Using m in Ventoy will use bios usb driver, using windows or Linux will use OS usb driver. That is why you need to check same file on usb drive using both m in Ventoy and using an os. Do not overwrite the file until you check with both methods.

Interestingly, some isos work and some don’t for example, Fedora KDE live iso worked but Ubuntu 21 did not. I currently have 2 isos on my ventoy USB, Ubuntu and Fedora, the sha256 of the Ubuntu image did change, I did not check the Fedora iso

Using m in Ventoy will use bios usb driver, using windows or Linux will use OS usb driver. That is why you need to check same file on usb drive using both m in Ventoy and using an os. Do not overwrite the file until you check with both methods.

Interestingly, some isos work and some don’t for example, Fedora KDE live iso worked but Ubuntu 21 did not. I currently have 2 isos on my ventoy USB, Ubuntu and Fedora, the sha256 of the Ubuntu image did change, I did not check the Fedora iso

Update: The hash for the ubuntu iso changed, but not the fedora iso

What do you mean ‘changed’?
How did you get the hash in first attempt and how did you get hash in second attempt?
Using m both times? Comparing with published values? Getting hash of downloaded file on system hard disk? Getting hash of file on usb drive?
Please can you be specific.

Final update:
The iso files were damaged due to not ejecting the USB stick properly, issue can now be considered as closed. Thank you for your help 😀

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Страницы: [1] 2  Все   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1] 2  Все   Вверх

Actually I doubt this has anything to do with kernel modules. As it seems the kernel itself is being refered to as a module. It is possible the kernel got built incorrectly or is being loaded incorrectly possibly from the grub commandline.

http://forums.gentoo.org/viewtopic-t-932358-start-0.html try that.

It is possible that some file in the kernel build didn’t get cleaned up properly an so has incorrect data in it since any changes you made in a previous attempt at building it.

Also do note that the x86 images will end up at arch/x86_64/boot/bzImage or arch/x86/boot/bzImage inside the kernel source make sure you actually have copied the kernel itself and not some other incorrect file.

If that fails try grub 1.x as its simpler to use than grub 2.x just note that alot of things are different and you should read tutorials for the correct version of grub. Often grub 1.x will be in a grub-legacy or similar package depending on the distro.

Edit: If you are building your kernel for your hardware only… do not use an initramfs its overkill. There are places you would want to do this is if your system is incapable of loading a kernel large enough for essential drivers (sparc for instance is very limited in kernel image size). another being booting over network possibly but by and large it isn’t needed. If you must use an initramfs get your kernel build working without it first.

Also personally I build my kernel with essential drivers included (disk and filesystem basically) and build it with.

make mrproper (save/backup your .config first) ; 
make menuconfig ; 
make -j8 ; 
make modules_install ; 
cp arch/x86_64/boot/bzImage /boot/linux-3.7.1 ; 

(modify grub to boot the new kernel) and im done and ready to reboot.

Any chance you could attach a screenshot of the failure?

Re: invalid magic number when i try «linux» command to boot after an upgrade