Tumbleweed kernel 4.11 problem

English Install/Boot/Login
1

Ciao
My computer

inxi -c 5 -b
System:    Host: linux-ghostrider Kernel: 4.10.13-1-default x86_64 (64 bit) Desktop: Gnome 3.24.2
           Distro: openSUSE Tumbleweed
Machine:   Device: desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
           Mobo: Hewlett-Packard model: 339A UEFI: Hewlett-Packard v: K01 v02.05 date: 05/07/2012
CPU:       Dual core Intel Pentium G640 (-MCP-) speed/max: 1599/2800 MHz
Graphics:  Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
           Display Server: X.Org 1.19.3 driver: N/A Resolution: 1680x1050@59.95hz
           GLX Renderer: Mesa DRI Intel Sandybridge Desktop
           GLX Version: 3.0 Mesa 17.1.0-devel (git-9f202a4 pontostroy:X11)
Network:   Card: Intel 82579LM Gigabit Network Connection driver: e1000e
Drives:    HDD Total Size: 1000.2GB (3.3% used)
Info:      Processes: 199 Uptime: 0:11 Memory: 1433.2/3824.5MB Client: Shell (bash) inxi: 2.3.8

Yesterday I updated my Tumbleweed Gnome, 2591 rpm to be updated, everything went fine.
At restart I started the new Kernel 4.11, but it did not start, disconnect the monitor and return to Grub2.
Here are the tests I did by starting from Kernel 4.10 that works regularly

  1. I added the repos of Kernel / Head 4.12.rc I updated everything to that repo, the result was that it stops loading on ram and does not even go with 4.12.rc.
  2. I added the repo home: / pontostroy: / X11 to update the xf86-video-intel driver, and updated everything to that repo, it does not even part.
  3. I went into the bios and tried to enable / disable secure boot, not part
  4. I’ve enabled / disabled in Yast2 boot loader> Safe bot and safe start, not even part of it.
2

Unfortunately I broke the system and I reinstalled Leap42.2.
This time I disable Bios the Boot / Efi partitioning everything in ext4.
In the next days I try Kernel4.11 to see if it goes

3

I tried the Upgrade at Tumbleweed, the problem with Kernel4.11 has reappeared so it is reproducible.
With Plasma5 and Tumbleweed, however, I had a lot more problems coming to the Plasma Desktop, but nothing works, the terminal message is that there is something that does not go with libproxy, the system is useless because it does not accept any command.
I hope you understand why I use the translator

4

Stay away from Tumbleweed. I have had a good time using TW during 2015-2016 and told everyone to use TW instead of Leap.

In late 2016 and 2017 TW keeps getting broken here and there. Almost unusable.

5

On 06/04/2017 08:16 AM, bonedriven wrote:
>
> Stay away from Tumbleweed. I have had a good time using TW during
> 2015-2016 and told everyone to use TW instead of Leap.
>
> In late 2016 and 2017 TW keeps getting broken here and there. Almost
> unusable.
>
>

I’ve used TW for many years and have had no major problems I could not
fix. So you see one persons experience does not reflect the experience
of the community. I say go for it and if you have problems as for help
here and on the factory mailing list.

–
Ken
linux since 1994
S.u.S.E./openSUSE since 1996

6

My installation Tumbleweed Gnome lasted for a year without any problems until the last update. Unfortunately I broke it in the attempt to launch the new Kernel 4.11. Certainly with my Hardware there is something that does not go with the latest Kernel

7

Not IME. And there’s proof: openqa.opensuse.org . TW passes the tests just like Leap. Yup, virtualized, but yet.

8

Not being persuaded I tried with the Stable Kernel also on Leap 42.2, well it was installed by deleting Kernel 4.4.62 and remaining alone by breaking the installation again.
I have now installed Manjaro and I have also tried Kernel4.11.3 but It does not go.
So there is something with my hardware that does not go.

9

instead of keep reinstalling have you considered just booting with the old kernel or even using rollback?

10

You are not alone
I exactly did the same and ended up like you…

11

It’s hard to understand why this is because it does not even try to leave, from Grub> sending to the Grub again, it passes 2 seconds.
Manjaro instead with Kernel 4.11.3 remains locked on loading Ram

12

Not a nice situation to be in but if you want to get a better view on why the kernel is not loading, you see SDB:Debugging_boot_hang

13

Having no clues, I gave up, completely eliminating Tumbleweed

14

I can imagine, that kind of debugging is not easy and time-consuming. On the other hand, somebody has to do it, let’s hope somebody also has the problem and it gets debugged so that a fix is present in a next kernel.

Are you now back to LEAP?

15

I wanted to install Manjaro to try, and even with that if I install Kernel4.11 does not part, as opposed to Opensuse the installation of the new kernel did not delete that working, so now I keep Manjaro.
I look at Leap42.3

16

Gigabyte motherboard Z170X UD5 Th with Nvidia 960 graphics card installed
also showed the same booting problem with the new 4.11 kernel.

Fortunately,
I booted up the machine successfully by digging up the snapshot 4.9.6 kernel, because the snapper has been working in my machine.
Let us see when the new kernel shows up that solves this booting problem.

17

I thought I was the only white fly.
As I have already said I left Tumbleweed waiting for better times

18

Similar problen on small i568 system:

On Alix Router board TW up to Kernel 4.10.13 runs fine:

# inxi -c 5 -b
System: Host: alix Kernel: 4.10.13-1-default i586 (32 bit) Console: tty 0 Distro: openSUSE Tumbleweed
Machine: No /sys/class /dmi; using dmidecode: no smbios data available. Old system?
CPU: Single core Geode Integrated by AMD PCS (-UP-) speed: 498 MHz (max)
Graphics: Card: Failed to Detect Video Card!
Display Server: N/A driver: N/A tty size: 166x52 Advanced Data: N/A for root out of X
Network: Card-1: VIA VT6105M [Rhine-III] driver: via-rhine
Card-2: VIA VT6105M [Rhine-III] driver: via-rhine
Drives: HDD Total Size: 144.0GB (17.6% used)
Info: Processes: 110 Uptime: 1:18 Memory: 87.2/240.4MB Init: systemd runlevel: 3
Client: Shell (bash) inxi: 2.3.8

Starting with Kernel 4.11.x or 4.12.rc-xx from SuSE Kernel Repository this board does not boot:

Directly after loading initrd sytem resetets:

Booting a command list

Loading Linux 4.11.7-1-default …
Loading initial ramdisk …
PC Engines ALIX.6 v0.99m ← Reset
640 KB Base Memory
261120 KB Extended Memory
Waiting for HDD …

debug & initcall_debug does not help to get more messages.

I don’t know absolute minimal requirements of TW (i586),
but it seems Alix boards still supported with creating
LED access on /sys/class/leds/alix:[123].

As workaround I’ve locked old Kernel 4.10 on yast to prevent any update

19

Manjaro now starts with the kernel4.11.8
It should also Tumbleweed, but not having it installed I can not say.
Does anyone who has the same problem can check it out?

20

Sorry,
Has nothing to do with TW.
it’s a kernel bug - starting with Kernel 4.8 and later.

This was gives the hint:
https://forum.openwrt.org/viewtopic.php?id=69243

With kernel 4.11 microcode loading changed for AMD CPUs.

Disabling microcode loading with CONFIG_MICROCODE=n in .config → kernel works.
Disabling microcode loading with cmdline boolean “dis_ucode_ldr” → kernel hangs on early boot in reset loop

Looking in detail what is the difference between both ways:

Found in file /arch/x86/kernel/cpu/microcode/core.c,
function check_loader_disabled_bsp(void)

Disabling microcode update with Cmdline checked as latest!

Even with disabling microcode updates CPU is checked for microcode update possibility before.
It’s useless cause later microcodes disabled anyway.

New amd cpu-id identification don’t work on AMD geode cpu.

Following kernel patch solves problem:

— a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -122,6 +122,9 @@ static bool __init check_loader_disabled
bool *res = &dis_ucode_ldr;
#endif

  • if (cmdline_find_option_bool(cmdline, option) > 0)
  •    return *res;
  • if (!have_cpuid_p())
    return *res;

@@ -138,8 +141,7 @@ static bool __init check_loader_disabled
return *res;
}

  • if (cmdline_find_option_bool(cmdline, option) <= 0)
  •    *res = false;

  • *res = false;

    return *res;
    }

This moves cmdline check for “dis_ucode_ldr” at first.

Disabling microcode update with cmdline should be fail-safe option,
especially for generic kernels which should run on many platforms.

No idea how to commit to kernel developers.

rgs