Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19592 - kernel panic with GRUB2 UEFI x86_64

Attached to Project: Arch Linux
Opened by Anonymous Submitter - Wednesday, 26 May 2010, 13:43 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 20 June 2010, 15:51 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Kernel Panic while booting Archlinux (kernel 2.6.33 x86_64) using GRUB2 for UEFI x86_64 (GRUB2 bzr revision 2396 - 23 May 2010).

This kernel panic is very specific. It does not occur with same GRUB2 compiled for BIOS (BIOS-GPT using BIOS Boot Partition) and it does not occur with GRUB-legacy x64 EFI (Fedora's version extracted from Fedora's rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=161036 ). I do not have Archlinux's GRUB-legacy installed to test it for this kernel panic. No problem with GRUB2 BIOS.

This kernel panic occurs only with GRUB2 compiled for UEFI x86_64 firmware. I use Tianocore EDK DUET UEFI64 firmware. GRUB2 compiled for BIOS is my own compiled version directly using source (not the AUR grub2-bzr package) (using gcc-multilib package). Configuration file for GRUB2 UEFI same as the one for GRUB2 BIOS.


Additional info:

kernel26 2.6.33.4-1 x86_64
udev 151-3 x86_64

GRUB2 UEFI configure options :-

./configure --with-platform=efi --target=x86_64 --program-transform-name=s,grub,grub2, --enable-efiemu --enable-mm-debug --enable-grub-fstest --enable-grub-mkfont --disable-nls --prefix=/grub2_efi_x64

Modules included in grub2.efi x86_64 UEFI Application (using grub-mkimage of GRUB2) :-

ata part_gpt part_msdos fat ntfs ntfscomp ext2 iso9660 udf hfsplus fshelp reboot normal chain linux xnu xnu_uuid ls search search_fs_file search_fs_uuid search_label help loopback cat tar boot configfile cpio sh echo loadbios efi_gop multiboot multiboot2 relocator

GRUB2 config :-

menuentry "Arch Linux" {
set root=(hd0,8)
linux /vmlinuz26 root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad rootfstype=ext4 ro nomodeset
initrd /kernel26.img
}

I have attached the kernel panic image as I couldn't get any other way of recording it. I have also attached my grub.cfg file.

My System :-

Dell India Studio 1537 Laptop
GUID Partition Table, EFI System Partition /dev/sda1 fat32,
Archlinux x86_64 root-partition /dev/sda7 ext4, Archlinux /boot /dev/sda8 fat32,
Windows 7 x64 Professional booting in UEFI-GPT mode.
ATI Mobility Radeon HD 3450 (not sure if this bug is related to my Graphics Card)

I think this is a Archlinux specific, kernel or initramfs bug as i didn't get this kind of error with Fedora 12 x86_64 kernels. If this is not specific to Archlinux kernel or initramfs, and if this is a bug in GRUB2 UEFI, I will then post this in GRUB2 mailing list.
   Archlinux_UEFI_GRUB2_x64_Kern... (248.9 KiB)
   grub.cfg (0.8 KiB)
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 20 June 2010, 15:51 GMT
Reason for closing:  Not a bug
Additional comments about closing:  The package in question (grub2-uefi) is not in Arch's repositories.

Problem can be fixed by using a newer snapshot.
Comment by Anonymous Submitter - Wednesday, 26 May 2010, 13:54 GMT
Similar bug is discussed here but no solution yet. http://bbs.archlinux.org/viewtopic.php?id=75120
Comment by Anonymous Submitter - Thursday, 27 May 2010, 12:38 GMT
Is this bug in anyway related to CONFIG_EFI_VARS=m instead of CONFIG_EFI_VARS=y in Archlinux kernel configuration?
Comment by Anonymous Submitter - Sunday, 30 May 2010, 14:24 GMT
This kernel panic did not occur with Fedora 12 x86_64 Kernel + archlinux's kernel26.img initramfs. Although some errors came regarding some modules missing for that kernel version, the booting went till KDE-mod user login screen (I tried 4 times). I am using ATI's fglrx video driver (not radeon).

Also why is dm-mod (device mapper) not built into the kernel. I read somewhere that it is essential for populating /dev directory contents and sometimes some device drivers create problems when they are available as a module and not built-in into the kernel.

I checked Archlinux's kernel config file and Fedora's 13 kernel config file (both 2.6.33 x86_64) for any possible differences but there are many and I don't understand 90 % of them. I am attaching the "diff -u" output between the two config files.
   config_2.6.33_fedora13 (103.3 KiB)
   kernel_config_diff.patch (94.6 KiB)
Comment by Thomas Bächler (brain0) - Sunday, 30 May 2010, 14:39 GMT
First (conclusions from the screenshot): Your grub is broken: It does not load the initrd at all. This means that this is not a bug in any of our packages, but in your own grub build. (It also looks like it strips off the leading "/dev" from root, meaning that root=disk/by-uuid/... is passed instead of root=/dev/disk/by-uuid/..., but I am unsure from the output that this is the problem).


This was your actual problem, the following are just side-remarks:

Second: Fedora's kernel can not boot with Arch's initrd and on-disk modules, period. In fact, if you actually had booted Fedora's kernel with Arch's initrd (as you claim), it wouldn't even succeed to mount the root file system, unless Fedora's kernel is a bloat that has EVERYTHING built-in.

Third: You "read somewhere" that device-mapper does something that has nothing to do with device-mapper. 90% of the people writing stuff on the internet are plain idiots, don't believe anything you "read somewhere".
Comment by Anonymous Submitter - Tuesday, 01 June 2010, 16:43 GMT
Fedora's kernel includes an embedded initranfs. So maybe Archlinux's initramfs file was ignored (if at all it was passed by grub2 efi). But Fedora's kernel was able to mount Archlinux's root even if the init methods of both are different.

I will post this same bug report in bug-grub mailing list and come back to you guys with their response on this.
Comment by Thomas Bächler (brain0) - Tuesday, 01 June 2010, 17:19 GMT
Okay, that explains some of it.

The files from Arch's initramfs would have overwritten Fedora's, if it had been loaded at all (the internal one is loaded first, then external one(s)). Contacting the grub people is probably best, this seems like a grub bug (assuming your configuration is correct).
Comment by Anonymous Submitter - Tuesday, 01 June 2010, 17:55 GMT
Seems like the initrd file passed to grub2 is indeed loaded in memory. The question is whether the kernel knows that the initrd file is loaded or whether the kernel fails to read the initrd file when booted in UEFI firmware. I modified my grub.cfg file to :-

menuentry "Arch Linux" {
set root=(hd0,gpt8)
echo "Loading Archlinux x86_64 Kernel"
linux (hd0,gpt8)/vmlinuz26 root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad rootfstype=ext4 ro nomodeset debug=all
echo "Archlinux x86_64 Kernel loaded"
echo "Loading Archlinux x86_64 Initramfs"
initrd (hd0,gpt8)/kernel26.img
echo "Archlinux x86_64 Initramfs loaded"
}

and the "echo" messages were printed on boot screen. So most likely the initrd is loaded but not passed correctly to the kernel by grub2 in UEFI firmware. Does this have something to do with EFI memory map of the firmware, or anything to do with the compression used for compressing initramfs? Initially I used LZMA, then I tried bzip2. But the problem did not disappear.

I got an extra error just before the kernel panic and VFS error (after I added the echo lines to grub.cfg).

PM: Resume from disk failed.

One more error that occurred even the last time (before the screenshot - while booting) was

pci EHCI: BIOS handoff failed (BIOS bug?) 01010001
Comment by Anonymous Submitter - Saturday, 05 June 2010, 19:35 GMT
Fedora's grub-legacy patched for efi and gpt - http://koji.fedoraproject.org/koji/buildinfo?buildID=161036 and http://git.kernel.org/?p=boot/grub-fedora/grub-fedora.git;a=summary . This grub.efi booted my system without any problem.

I sent a report to bug-grub mailing list http://lists.gnu.org/archive/html/bug-grub/2010-06/msg00000.html . Is this bug in any way related to some UEFI PCI or ACPI errors? I do not know what is ACPI but I have read about faulty ACPI implementations and DSDTs used to correct them.

I also tried booting partedmagic 4.11 using the same grub2 UEFI. It booted and but it could mount neither the Archlinux root partition (but no error about init appeared) nor its iso (findiso kernel parameter). I do not know whether it contains an embedded initramfs or not.
Comment by Anonymous Submitter - Tuesday, 08 June 2010, 15:00 GMT
Kernel parameters acpi=force and acpi=off did not work with original grub.cfg.

I tried Fedora 12 x86_64 kernel + Archlinux kernel26.img initramfs, in dmesg :-

Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd


Fedora's grub-legacy grub.efi booted Archlinux without any problems. My initramfs is lzma compressed. Seems like grub2 uefi does not pass the correct memory address of the loaded initramfs to Archlinux kernel.
   dmesg_archlinux_grub-legacy-f... (43.9 KiB)
   dmesg_fedora_kernel_grub2_efi... (42.8 KiB)
Comment by Anonymous Submitter - Sunday, 20 June 2010, 15:48 GMT
This problem is resolved by using grub2 bzr experimental branch http://grub.enbug.org/ExperimentalBranch (bzr repo - http://bzr.savannah.gnu.org/r/grub/branches/experimental ). It is due to the way the current main bzr trunk of grub2 allocates memory for kernel and initramfs in UEFI systems.

Once the kernel and initramfs has been loaded into memory and after the kernel is launched by grub2, kernel decompression (LZMA compressed) overwrites part of the initramfs LZMA archive in memory and then leading to a corrupted initramfs which the kernel then fails to load. GRUB2 BIOS allocates adequate memory for kernel decompression without affecting initramfs but GRUB2 UEFI does not do the same job, leading to the kernel panic.

The related info is here http://lists.gnu.org/archive/html/bug-grub/2010-06/msg00027.html . There seems to be no problem from Archlinux side. I think this bug-report may be closed.

Loading...