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

loqs · 2017-05-30 17:16:34

erickwill wrote:

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

https://bugs.archlinux.org/task/54171#comment158034 this post on the bug report on the arch bug tracker summarizes my understanding of the current issue with regards to upstream.
Are you booting using efi or bios have you tried the kernel parameter earlyprintk=vga for bios booting systems or earlyprintk=efi (without using acpi=off) to see if an Oops is displayed.
Getting upstream to take an interest without a bisect or an Oops pointing to a particular function may prove difficult as the list of known facts seems limited to:

Issue is not present in 4.9.13
Issue is present in 4.11.2
Issue can be avoided by adding the parameter acpi=off

keibak · 2017-05-30 19:03:00

loqs wrote:

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?

Sorry, I'm new around here, but with the release of 4.11.3, 4.11.2 is outdated. As the arch bugtracker says REPEAT: Do NOT report bugs for outdated packages!, I deemed it worth mentioning, that the problem is still around.

loqs · 2017-05-30 19:13:04

keibak wrote:

Sorry, I'm new around here, but with the release of 4.11.3, 4.11.2 is outdated. As the arch bugtracker says REPEAT: Do NOT report bugs for outdated packages!, I deemed it worth mentioning, that the problem is still around.

How is that relevant to posting on the forums? The bug report was opened when 4.11.2 was current. If the issue was not closed on the bug tracker as fixed why would anyone believe the situation had changed?
See here as an example of repeated posts that an issue exists through numerous kernel package releases with no result https://bbs.archlinux.org/viewtopic.php?id=218581
Edit:
As you mentioned the bug report guidelines Reporting_bug_guidelines#Upstream_or_Arch.3F there is no evidence this is a packing or integration issue so it should be reported upstream.

Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it.

Also Reporting_bug_guidelines#Updating_the_bug_report_when_a_new_version_of_the_related_software_is_out

Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.

Last edited by loqs (2017-05-30 19:37:02)

keibak · 2017-05-30 20:02:45

loqs wrote:

keibak wrote:
Sorry, I'm new around here, but with the release of 4.11.3, 4.11.2 is outdated. As the arch bugtracker says REPEAT: Do NOT report bugs for outdated packages!, I deemed it worth mentioning, that the problem is still around.
How is that relevant to posting on the forums? The bug report was opened when 4.11.2 was current. If the issue was not closed on the bug tracker as fixed why would anyone believe the situation had changed?
See here as an example of repeated posts that an issue exists through numerous kernel package releases with no result https://bbs.archlinux.org/viewtopic.php?id=218581
Edit:
As you mentioned the bug report guidelines Reporting_bug_guidelines#Upstream_or_Arch.3F there is no evidence this is a packing or integration issue so it should be reported upstream.
Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it.
Also Reporting_bug_guidelines#Updating_the_bug_report_when_a_new_version_of_the_related_software_is_out
Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.

Thanks a lot for making that clear.

loqs wrote:

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

I'd love to test given patch, but building a custom kernel using this instructions is not doable for me.

loqs · 2017-05-30 20:19:37

keibak wrote:

I'd love to test given patch, but building a custom kernel using this instructions is not doable for me.

Do you mean you got stuck on a step and need clarification or some other reason?

keibak · 2017-05-30 20:28:01

Yes, I got stuck right after cloning the linux package files.

There's this passage: Then, get any other file you need (e.g. custom configuration files, patches, etc.) from the respective sources.. Which is really a big black whole to me.
Furthermore there's mentioned, that under some circumstances one needs to rename linux.install. Then I remembered I've kernel dependencies to the nvidia package and others.
All in all the instructions aren't clear for me.

I just don't want to break my system and end up in an completly unbootable and unrepairable configuration.
Been there, not going there anymore.

loqs · 2017-05-30 21:05:42

Perfectly understandable would suggest firstly you have linux-lts installed plus as you need nvidia the nvidia-lts package
and ensure those can boot the linux-lts kernel as well as the linux kernel that gives you two working kernels.
As long as you choose a different name for the kernel you are building it will not interfere with either of those kernels.
Without building a custom nvidia package you are correct you would not get the nvidia module working however to test this bug my understanding t you would only need the kernel to boot successfully.
In the bisect or patch testing if the kernel does not boot the bug is present if the kernel boots even dropping you to a rescue shell then the bug is fixed.
Then you can reboot to either of the two good kernels you should have on the system.
These should be the minimum steps to build a kernel called linux-custom applying the patch from post #24
Following the instruction you shave a a directory ~/build/linux

$ cd ~/build-linux
$ makepkg -osr

This will download all the source files from kernel.org and verify them
Save the patch from the codeblock in post #24 as 7425826f4f7ac60f2538b06a7f0a5d1006405159_4_11_3.patch in this directory the name is not important but I will use this name in the rest of the changes.

pkgbase=linux               # Build stock -ARCH kernel
#pkgbase=linux-custom       # Build kernel with a different name

comment the first of those two lines out and uncomment the second so the package name becomes linux-custom

source=("https://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.xz"
        "https://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.sign"
        "https://www.kernel.org/pub/linux/kernel/v4.x/patch-${pkgver}.xz"
        "https://www.kernel.org/pub/linux/kernel/v4.x/patch-${pkgver}.sign"
        "7425826f4f7ac60f2538b06a7f0a5d1006405159_4_11_3.patch"
        # the main kernel config files
        'config.i686' 'config.x86_64'
        # pacman hook for initramfs regeneration
        '90-linux.hook'
        # standard config files for mkinitcpio ramdisk
        'linux.preset')

Add entry for the patch file to the source array

$ updpkgsums

This will update the checksums for all the entries in the source array as you used makepkg -o previously the only checksum that should be changed will be the one for the patch file

prepare() {
  cd "${srcdir}/${_srcname}"

  # add upstream patch
  patch -p1 -i "${srcdir}/patch-${pkgver}"
  patch -p1 -i "${srcdir}/7425826f4f7ac60f2538b06a7f0a5d1006405159_4_11_3.patch"

Add a line to the prepare function so that the patch is applied. Changes complete.
I would recommend changing the MAKEFLAGS option in /etc/makepkg.conf so the package build uses all the core available this will speed up the build process.
Then you should be back at Arch_Build_System#Compiling
Because of the earlier use of `makepkg -o` `makepkg -s` will fail as the src directory has already been patched and applying the patch the second time will cause the error
Use `makepkg -sC` -C removes the srcdir ( it will then be recreated clean ) you could also add -r which will remove makedepends after building.
If you encounter difficulties please post the commands and their outputs.
Edit:
grammar
Edit2:
Added warning about expected error after using `makepkg -o`

Last edited by loqs (2017-05-30 21:40:41)

keibak · 2017-05-31 16:05:18

@loqs: Thanks! Your instructions were perfectly clear! I managed to build a patched kernel 4.11.3:

Linux Angband 4.11.3-1-custom #1 SMP PREEMPT Wed May 31 17:54:55 CEST 2017 x86_64 GNU/Linux

The resulting kernel boots without acpi=off set.

However it fails to start the display manager, which we expected due to a missing custom nvidia module build.

Edit: The patch and the modified PKGBUILD are available in this gist.

Last edited by keibak (2017-05-31 16:11:09)

loqs · 2017-05-31 16:30:52

So it looks like the cause of the issue has been found congratulations.

keibak · 2017-05-31 17:43:28

Now that there's a patch, what will be the next steps?

erickwill · 2017-05-31 17:48:33

keibak wrote:

Now that there's a patch, what will be the next steps?

Maybe to let the maintainer to know that the patch is available? BTW, thanks

Last edited by erickwill (2017-05-31 17:49:32)

loqs · 2017-05-31 18:14:16

Yes as you have a patch now posting it to the bug report as the fix for bios booting systems will let the maintainer and others following the bug report know about the fix.
Upstream the patch was from tip from there it needs to go to mainline ( Linus Torvalds tree ) efi-bgrt.c ( should appear in the log here if accepted )
Once it is in mainline the patch against the 4.11 series can be added to stable-queue to become part of the a new stable release from linux-stable.
Edit:
Posted to the arch bug report about the patch.

Last edited by loqs (2017-05-31 19:12:27)

keibak · 2017-05-31 19:32:48

Added findings to https://bugzilla.kernel.org/show_bug.cgi?id=195633.

This bug is about the commit that probably introduced the issue.

W54J04S07T · 2017-06-01 20:43:29

I've followed this thread with great interest, since one of my
systems failed to boot in exactly the same manner.

However, I'm wondering about this ACPI issue. You see,
I upgraded 3 other systems to 4.11.2 without a hitch.
Only an x79 chipset machine hung. I simply downgraded
back to 4.10.13.

Then I realized soemthing. One of my systems has had ACPI
issues from day one and never hung. And this ACPI issue
has been around for years ( from my net searches ) in one
form or another.

Which gets me to the point; while it is excellent to have a fix
in the form of a patch in place, I'm wondering why the
upstream guys have never bothered to simply replace their
ACPI ( and other BIOS feathures handling code ) with something
a bit more robust? Is it really acceptable in their minds
to have a system that hangs in precisely this manner?

loqs · 2017-06-01 22:11:36

W54J04S07T wrote:

However, I'm wondering about this ACPI issue. You see,
I upgraded 3 other systems to 4.11.2 without a hitch.
Only an x79 chipset machine hung. I simply downgraded
back to 4.10.13.
Then I realized soemthing. One of my systems has had ACPI
issues from day one and never hung. And this ACPI issue
has been around for years ( from my net searches ) in one
form or another.

This seems to be conflating all ACPI issues as the same issue as you yourself note the issue for your system is not present in the 4.10 series
so it was introduced during during the 4.11 cycle which is has not been around for years.

W54J04S07T wrote:

Which gets me to the point; while it is excellent to have a fix
in the form of a patch in place

If the system is bios booting have you tried the patch to verify it is the same issue and that the fix works?
If the system is not bios booting there is no patch for the issue and upstream requires feedback.

W54J04S07T wrote:

I'm wondering why the
upstream guys have never bothered to simply replace their
ACPI ( and other BIOS feathures handling code ) with something
a bit more robust? Is it really acceptable in their minds
to have a system that hangs in precisely this manner?

Have you asked upstream?
Edit:
Grammar is not in
Edit2:
Commit for the bios booting issue is now in mainline https://git.kernel.org/pub/scm/linux/ke … 1006405159

Last edited by loqs (2017-06-02 17:50:58)

W54J04S07T · 2017-06-02 19:51:54

loqs wrote:

Edit:
Grammar is not in
Edit2:
Commit for the bios booting issue is now in mainline https://git.kernel.org/pub/scm/linux/ke … 1006405159

Grammar? Yours or mine?

Commit in mainline. Great, now we wait

loqs · 2017-06-02 20:06:00

W54J04S07T wrote:

Grammar? Yours or mine?

Mine
The "is not in" referred to my edit changing "the issue for your system in not present in the 4.10 series" to "the issue for your system is not present in the 4.10 series" if I recall correctly.

erickwill · 2017-06-13 13:56:34

Seems that the issue persists along the new kernel.. anyone can confirm?

coldcontrol · 2017-06-14 15:45:16

Confirmed that 4.11.4 does not resolve the issue, but it looks like there's some activity towards 4.11.5 today as well: https://git.archlinux.org/svntogit/pack … ages/linux

loqs · 2017-06-14 16:31:05

4.11.5-1 will fix the issue under BIOS booting but not under EFI booting more details https://bugs.archlinux.org/task/54171#comment158492

spinnau · 2017-06-14 16:53:12

Looks like both patches for BIOS and EFI boot will be included in 4.12 (Linux-4.12-rc5 announcement)

erickwill · 2017-06-15 00:16:52

spinnau wrote:

Looks like both patches for BIOS and EFI boot will be included in 4.12 (Linux-4.12-rc5 announcement)

Sounds good.. looking forward for the new kernel..

loqs · 2017-06-15 11:30:21

Fix for EFI booting is now in the stable-queue https://git.kernel.org/pub/scm/linux/ke … ress.patch
So 4.11.6 or 4.12 whichever is released first both should contain the last fix to resolve the issue.

erickwill · 2017-06-15 13:25:59

loqs wrote:

Fix for EFI booting is now in the stable-queue https://git.kernel.org/pub/scm/linux/ke … ress.patch
So 4.11.6 or 4.12 whichever is released first both should contain the last fix to resolve the issue.

That's great, thanks for sharing this info

spinnau · 2017-06-17 09:30:26

Linux-4.11.6 was released 5 hours ago with the EFI patch included and it's already in testing repo

edit: I have tried the version from testing and it fixes the issue on my system.

Last edited by spinnau (2017-06-17 10:08:08)

Arch Linux

#26 2017-05-30 17:16:34

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

#27 2017-05-30 19:03:00

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

#28 2017-05-30 19:13:04

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

#29 2017-05-30 20:02:45

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

#30 2017-05-30 20:19:37

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

#31 2017-05-30 20:28:01

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

#32 2017-05-30 21:05:42

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

#33 2017-05-31 16:05:18

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

#34 2017-05-31 16:30:52

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

#35 2017-05-31 17:43:28

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

#36 2017-05-31 17:48:33

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

#37 2017-05-31 18:14:16

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

#38 2017-05-31 19:32:48

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

#39 2017-06-01 20:43:29

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

#40 2017-06-01 22:11:36

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

#41 2017-06-02 19:51:54

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

#42 2017-06-02 20:06:00

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

#43 2017-06-13 13:56:34

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

#44 2017-06-14 15:45:16

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

#45 2017-06-14 16:31:05

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

#46 2017-06-14 16:53:12

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

#47 2017-06-15 00:16:52

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

#48 2017-06-15 11:30:21

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

#49 2017-06-15 13:25:59

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

#50 2017-06-17 09:30:26

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

Board footer