[SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

keibak · 2017-05-24 17:35:52

Hi,

I just upgraded to kernel 4.11.2 from core/linux (4.11.2-1). But now Arch won't boot anymore. It's stuck at loading inital ramdisk. The fallback ramdisk also show the same behaviour.

Any hints how to solve this issue? Unfortunatelly I don't have any log messages which would error searching.

Btw, I managed to get the computer booting again by installing the lts-kernel.

Boot from https://www.archlinux.org/download:

mount /dev/sda1
arch-chroot /mnt
pacman -Sy linux-lts nvidia-lts
grub-mkconfig -o /boot/grub/grub.cfg

Update:
The issue is fixed with core/linux 4.11.5 for bios booting and will be fixed with core/linux 4.11.6 for EFI systems. See FS#54171 for further information.

Last edited by keibak (2017-06-17 12:44:57)

R00KIE · 2017-05-24 17:47:05

Welcome to the forums.

Please post your full pacman log.

keibak · 2017-05-24 18:00:02

The kernel installs without any error. Nevertheless it won't boot.

[2017-05-24 18:20] [ALPM] reinstalled linux (4.11.2-1)
[2017-05-24 18:20] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2017-05-24 18:20] [ALPM] transaction completed
[2017-05-24 18:20] [ALPM] running '90-linux.hook'...
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Starting build: 4.11.2-1-ARCH
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Starting build: 4.11.2-1-ARCH
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-05-24 18:20] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
[2017-05-24 18:20] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-05-24 18:20] [ALPM] running 'systemd-update.hook'..

R00KIE · 2017-05-24 18:17:18

Can you also post your grub.cfg and your fstab.

keibak · 2017-05-24 18:47:22

The fstab is pretty short:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# UUID=64f19c9a-2549-4ced-ad69-8f95d10c543d
/dev/sda1               /               ext4            rw,relatime,data=ordered,noatime                0 1

In grub, the same device is used for both linux and linux-lts:

        menuentry 'Arch Linux, mit Linux linux-lts' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-advanced-64f19c9a-2549-4ced-ad69-8f95d10c543d' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_msdos
                insmod ext2
                set root='hd0,msdos1'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  64f19c9a-2549-4ced-ad69-8f95d10c543d
                else
                  search --no-floppy --fs-uuid --set=root 64f19c9a-2549-4ced-ad69-8f95d10c543d
                fi
                echo    'Linux linux-lts wird geladen …'
                linux   /boot/vmlinuz-linux-lts root=UUID=64f19c9a-2549-4ced-ad69-8f95d10c543d rw  
                echo    'Initiale Ramdisk wird geladen …'
                initrd  /boot/initramfs-linux-lts.img
        }
        menuentry 'Arch Linux, mit Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-64f19c9a-2549-4ced-ad69-8f95d10c543d' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_msdos
                insmod ext2
                set root='hd0,msdos1'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  64f19c9a-2549-4ced-ad69-8f95d10c543d
                else
                  search --no-floppy --fs-uuid --set=root 64f19c9a-2549-4ced-ad69-8f95d10c543d
                fi
                echo    'Linux linux wird geladen …'
                linux   /boot/vmlinuz-linux root=UUID=64f19c9a-2549-4ced-ad69-8f95d10c543d rw  
                echo    'Initiale Ramdisk wird geladen …'
                initrd  /boot/initramfs-linux.img
        }

To me this looks like a problem with the linux package rather than a configuration issue.

I can't pin anything down as the computer is stuck at 'Loading initial ramdisk'.

loqs · 2017-05-24 18:53:30

Please see https://bbs.archlinux.org/viewtopic.php … 6#p1713046 if it is the same issue then also appears to be the issue here https://bbs.archlinux.org/viewtopic.php?id=226520.

keibak · 2017-05-24 19:06:31

loqs wrote:

Please see https://bbs.archlinux.org/viewtopic.php … 6#p1713046 if it is the same issue then also appears to be the issue here https://bbs.archlinux.org/viewtopic.php?id=226520.

The last thread gave some hints: Setting parameter acpi=off will boot kernel 4.11.2.

loqs · 2017-05-24 19:15:41

Can you produce the same Oops as Maniaxx?

keibak · 2017-05-24 19:37:57

No, I don't get any Oops. The kernel boots just fine.

loqs · 2017-05-24 19:45:43

loqs wrote:

For the second possibility add the earlyprintk=vga for bios booting systems or earlyprintk=efi for efi booting systems kernel parameter ( see https://www.kernel.org/doc/Documentatio … meters.txt for more details )

So I meant do not use the acpi=off parameter use earlyprintk=efi as your system appears to be efi booting and see if an Oops is displayed that matches the screenshots in https://bbs.archlinux.org/viewtopic.php … 7#p1713237

keibak · 2017-05-24 19:48:39

The only differences in dmesg I can see between 4.9.29 and 4.11.2 are the missing ACPI entries:

Linux version 4.9.29-1-lts (builduser@andyrtr) (gcc version 7.1.1 20170516 (GCC) ) #1 SMP Sat May 20 17:35:48 CEST 2017
Command line: BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=64f19c9a-2549-4ced-ad69-8f95d10c543d rw
(...)
RAMDISK: [mem 0x3748c000-0x37a3dfff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x00000000000F0450 000024 (v02 ALASKA)
ACPI: XSDT 0x00000000CA27F078 000074 (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: FACP 0x00000000CA2895A8 0000F4 (v04 ALASKA A M I    01072009 AMI  00010013)
ACPI: DSDT 0x00000000CA27F188 00A41E (v02 ALASKA A M I    00000014 INTL 20051117)
ACPI: FACS 0x00000000CA298F80 000040
ACPI: APIC 0x00000000CA2896A0 000092 (v03 ALASKA A M I    01072009 AMI  00010013)
ACPI: ASF! 0x00000000CA289738 0000A5 (v32 INTEL   HCG     00000001 TFSM 000F4240)
ACPI: MCFG 0x00000000CA2897E0 00003C (v01 ALASKA A M I    01072009 MSFT 00000097)
ACPI: AAFT 0x00000000CA289820 0000C2 (v01 ALASKA OEMAAFT  01072009 MSFT 00000097)
ACPI: HPET 0x00000000CA2898E8 000038 (v01 ALASKA A M I    01072009 AMI. 00000005)
ACPI: SSDT 0x00000000CA289920 00036D (v01 SataRe SataTabl 00001000 INTL 20091112)
ACPI: SSDT 0x00000000CA289C90 0009AA (v01 PmRef  Cpu0Ist  00003000 INTL 20051117)
ACPI: SSDT 0x00000000CA28A640 000A92 (v01 PmRef  CpuPm    00003000 INTL 20051117)
ACPI: BGRT 0x00000000CA28B0D8 00003C (v00 ALASKA A M I    01072009 AMI  00010013)
ACPI: Local APIC address 0xfee00000
No NUMA configuration found

Linux version 4.11.2-1-ARCH (builduser@tobias) (gcc version 7.1.1 20170516 (GCC) ) #1 SMP PREEMPT Mon May 22 06:53:49 CEST 2017
Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=64f19c9a-2549-4ced-ad69-8f95d10c543d rw acpi=off
(...)
RAMDISK: [mem 0x37486000-0x37a3afff]
No NUMA configuration found

Btw, CPU in this machine is a faithful i7-2600K.

keibak · 2017-05-24 19:55:02

loqs wrote:

loqs wrote:
For the second possibility add the earlyprintk=vga for bios booting systems or earlyprintk=efi for efi booting systems kernel parameter ( see https://www.kernel.org/doc/Documentatio … meters.txt for more details )
So I meant do not use the acpi=off parameter use earlyprintk=efi as your system appears to be efi booting and see if an Oops is displayed that matches the screenshots in https://bbs.archlinux.org/viewtopic.php … 7#p1713237

I don't boot EFI. So setting earlyprintk=efi has no effect for me.
Nevertheless I tried it and got stuck at Loading initial ramdisk. No Ooops was recorded.

earlyprintk=vga also has no effect. There the only message on screen is Loading initial ramdisk.

Last edited by keibak (2017-05-24 19:59:50)

loqs · 2017-05-24 20:10:14

Try combining loglevel=7 with earlyprintk=vga it looks like the quiet parameter is not present but if it is please remove it as well.
If that fails you will probably have to bisect the kernel to find the bad commit. So possibly not the same issue as Maniaxx.

keibak · 2017-05-24 20:18:49

loqs wrote:

Try combining loglevel=7 with earlyprintk=vga it looks like the quiet parameter is not present but if it is please remove it as well.
If that fails you will probably have to bisect the kernel to find the bad commit. So possibly not the same issue as Maniaxx.

Booting with above parameter doesn't give me more information. The screen only shows 'Loading initial ramdisk'. The quiet parameter also isn't set.

Bisecting extends my abilities. That's not really doable for me.

For now what really matters is that sucessful booting can be done with parameter acpi=off

keibak · 2017-05-25 06:51:19

I managed to get some output using vga=1 earlyprintk=vga:

Seems different to Maniaxx's one?

loqs · 2017-05-25 10:51:17

Yes seems different unfortunately https://abload.de/img/cameringo_20170525_08tksef.png contains less information than Maniaxx due to more lines wrapping.

erickwill · 2017-05-27 18:59:44

keibak wrote:

loqs wrote:
Try combining loglevel=7 with earlyprintk=vga it looks like the quiet parameter is not present but if it is please remove it as well.
If that fails you will probably have to bisect the kernel to find the bad commit. So possibly not the same issue as Maniaxx.
Booting with above parameter doesn't give me more information. The screen only shows 'Loading initial ramdisk'. The quiet parameter also isn't set.
Bisecting extends my abilities. That's not really doable for me.
For now what really matters is that sucessful booting can be done with parameter acpi=off

I'm also with the same problem.. are you booting with parameter acpi=off using linux-lts or the current one?
Also.. does this bug was already reported?
Thanks

Last edited by erickwill (2017-05-27 19:00:19)

loqs · 2017-05-27 20:28:41

@erickwill what kernels have you tried? Are you booting using efi or bios have you tried the kernel parameter acpi=off or earlyprintk=vga for bios booting systems or earlyprintk=efi to see if an Oops is displayed.
It is unclear how many bugs there actually are in this thread and the ones linked from it so it is difficult to say if any or all the the relevant upstream parties are aware of the issue reporting it to arch will not achieve a fix for an upstream issue.
Edit:
Spelling

Last edited by loqs (2017-05-27 20:29:01)

keibak · 2017-05-28 08:56:03

@erickwill: I'm booting linux (4.11.2) with acpi=off. linux-lts (4.9.29) starts up fine without the option.

In the bug tracker you can find FS#54171 - [Linux] freeze boot after "loading initial memory image" with 4.11.2. The issue is the same, but the whole thing is missing information like oopses and debug output. loqs is right, for further processing, more details are necessary.

loqs · 2017-05-28 09:30:17

https://bugzilla.kernel.org/show_bug.cgi?id=195633#c2 This is for the efi bug with similar symptoms appears upstream is investigating it as an efi issue so will not help bios booting systems such as keibak uses.
Edit:
This might be releated to the issue on bios booting systems but needs someone to test https://lkml.org/lkml/2017/5/28/61

Last edited by loqs (2017-05-29 22:40:13)

hodasemi · 2017-05-30 15:00:04

I tested this fix on my bios system and it just worked!

keibak · 2017-05-30 15:01:58

I have to report, that the issue persists with linux 4.11.3-1-ARCH

hodasemi wrote:

I tested this fix on my bios system and it just worked!

That's great to hear!

erickwill · 2017-05-30 15:35:13

keibak wrote:

I have to report, that the issue persists with linux 4.11.3-1-ARCH
hodasemi wrote:
I tested this fix on my bios system and it just worked!
That's great to hear!

Yep, I can confirm that this bug persists on latest kernel.

loqs · 2017-05-30 16:25:32

Patch from post #20 rebased against 4.11.3 obviously needs an affected user to test.

diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index 04ca8764f0c0..8bf27323f7a3 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_table_header *table)
 	if (acpi_disabled)
 		return;
 
+	if (!efi_enabled(EFI_BOOT))
+		return;
+
 	if (table->length < sizeof(bgrt_tab)) {
 		pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
 		       table->length, sizeof(bgrt_tab));

keibak wrote:

I have to report, that the issue persists with linux 4.11.3-1-ARCH

Unless upstream is aware of the issue would you not expect that situation to continue?

erickwill · 2017-05-30 17:03:36

loqs wrote:

Patch from post #20 rebased against 4.11.3 obviously needs an affected user to test.
diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index 04ca8764f0c0..8bf27323f7a3 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_table_header *table)
 	if (acpi_disabled)
 		return;
 
+	if (!efi_enabled(EFI_BOOT))
+		return;
+
 	if (table->length < sizeof(bgrt_tab)) {
 		pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
 		       table->length, sizeof(bgrt_tab));
keibak wrote:
I have to report, that the issue persists with linux 4.11.3-1-ARCH
Unless upstream is aware of the issue would you not expect that situation to continue?

Just to avoid duplicity, are you aware of a report, regarding this bug, for the subjected kernel? Otherwise, we could issue a bug report.

Last edited by erickwill (2017-05-30 17:03:57)

Arch Linux

#1 2017-05-24 17:35:52

[SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#2 2017-05-24 17:47:05

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#3 2017-05-24 18:00:02

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#4 2017-05-24 18:17:18

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#5 2017-05-24 18:47:22

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#6 2017-05-24 18:53:30

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#7 2017-05-24 19:06:31

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#8 2017-05-24 19:15:41

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#9 2017-05-24 19:37:57

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#10 2017-05-24 19:45:43

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#11 2017-05-24 19:48:39

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#12 2017-05-24 19:55:02

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#13 2017-05-24 20:10:14

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#14 2017-05-24 20:18:49

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#15 2017-05-25 06:51:19

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#16 2017-05-25 10:51:17

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#17 2017-05-27 18:59:44

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#18 2017-05-27 20:28:41

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#19 2017-05-28 08:56:03

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#20 2017-05-28 09:30:17

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#21 2017-05-30 15:00:04

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#22 2017-05-30 15:01:58

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#23 2017-05-30 15:35:13

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#24 2017-05-30 16:25:32

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

#25 2017-05-30 17:03:36

Re: [SOLVED] [Kernel 4.11.2] Stuck at loading inital ramdisk

Board footer