Automatic boot parameter repetition / Ryzen kernel 4.11.3-4.g7bbd095-vanilla

(Tumbleweed: last update 2h before)

On my PC, all updates including changes under a running system - even only to set kernel parameters using Yast - weren’t possible in the last weeks, leading to yast2 hanger and incomplete end of update procedure (it’s only possible to do that using the installation DVD).

So I wanted to try kernel boot parameter “radeon.audio=1” with the new, somewhat more stable kernel (last hanger, today, incomplete - no screen action, no text input, but mouse pointer working).

[size=2]But Yast2 is showing a somewhat surprising kernel parameter setting for the optional parameters of the kernel command line (“Optionaler Parameter für Kernel-Befehlszeile”):

[/size]

resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts

This is better readable with some additional newlines as:


resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts

The line is obviously filled repetitively until there’s no space left.

Perhaps this is in error, but I’m not really sure - there are surprising provisorials for very new hardware configs like mine.

Should / may / is it safe to delete entries leading e.g. to


resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d
 splash=silent quiet showopts resume=/dev/sda2 
 splash=silent quiet showopts resume=/dev/disk/by-uuid/105646d5-63ca-4ea5-84b0-e26f7437693d 
 splash=silent quiet showopts resume=/dev/sda2 

Or is there a good cause for this repetition?

Sorry, the word “boot” was missing:

Not

But

On my PC, all updates including **boot **changes under a running system - even only to set kernel parameters using Yast - weren’t possible in the last weeks, leading to yast2 hanger and incomplete end of update procedure (it’s only possible to do that using the installation DVD).

We can talk German, its the German Subforum…

Inzwischen dürfte(!) die Fehlersituation etwas klarer sein. Wenn meine Vermutung zutrifft muß, damit der Fehler störende Auswirkungen hat, ungewöhnlich oft ein standalone-Update mittels DVD erfolgen. Die Notwendigkeit dazu ergab sich für mich dadurch, daß Patches, die den Boot betrafen, z.B. neue kernel, auf meinem System nur so erfolgreich eingefahren werden konnten.
Die Mithilfe für das Absetzen einer zielgerechten Fehlermeldung war leider eher gering, ich hätte es lieber zielgenauer getan.

Warum nimmst du den Vanilla kernel und nicht den aus kernel:stable?

Linux linux64 4.11.6-3.g5e3bb37-default #1 SMP PREEMPT Thu Jun 22 19:02:00 UTC 2017 (5e3bb37) x86_64 x86_64 x86_64 GNU/Linux

Warum ich den Vanilla-Kernel genommen hatte und nicht den aus kernel:stable?

  • Ich verwendete zuletzt nur Kernel aus diesem Repo, dort gibt’s auch die Vanilla-Kernel.
  • Einfach um auszuprobieren, wie er reagiert - mehr oder weniger störende Schwächen (das heißt angesichts meiner ja sehr neuen Hardware nichteinmal, ob er mehr oder weniger Fehler enthält). War unergiebig - es ergab sich kein auffälliger Unterschied.

Inzwischen verwende ich wieder einen Standardkernel, aber von anderswo. Mehr dazu und eine für Ryzen+Polaris z.T. (noch) günstige Kernel-Optionen in einem neuen Beitrag.