Group 1-b: Resolve boot complicacies
openSuSE 42.1 et sqq.: Missing policy files for SELinux lock up the boot sequence
When you attempt to use SELinux with Leap 42.1 or newer you have s problem: Even though you install everything that is available and then instruct the system to fire up SELinux upon booting, you are in for a bad surprise: About halfway through the boot process it locks up, and no matter what you might try, you cannot get it unstuck again. This means that a reset is your only option to brutally get the system unstuck, and you should have your system's CD handy to start up a rescue system so that you can fire up a rescue system and get your system back up and running.
It's the missing policy files required by SELinux to work properly that are to
be blamed for this calamity. The consequence of this is that certain system
calls are either processed with a delay or get stuck altogether. Unfortunately these
files aren't provided for openSuSE beginning with 42.1, which means an
insurmountable obstacle for you.
The only solution that remains would be to do without SELinux.
Fortunately this problem can be worked around rather easily: You simply have
to add a repository that still contains the files needed for SELinux:
openSuSE
Leap 42.2 SELinux.
In order to get access to these files you just need to set up the repository
like this:
This makes the policy files available for SELinux again, and the higher priority guarantees that it has precedence over the normal repositories.
If you are using Tumbleweed, you don't have to do anything, because the policy files are already present in the repository.
to the topXen (Domain-0): kernel-default-4.15.0 on Intel CPUs hangs with kernel panic
If you are virtualizing on a computer with an Intel CPU and are using Xen as a hypervisor, the system is going to malfunction as soon as you update the kernel. Here a conflict with the updated microcode of said CPUs seems to be responsible that, in conjunction with specific patches to the system, is supposed to help mitigate a security flaw known as Meltdown.
Upon boot Xen starts up as usual, but as soon as control is passed to the
kernel to be booted, an error occurs as soon as it attempts to access Xen, and
the kernel immediately stops with a
kernel panic.
In order to work around this problem, the kernel must be booted without Xen if
possible, or if Xen is a must, you have to resort to an older kernel that does
not cause this problem.
Boxes that run on CPUs from AMD are entirely unaffected by this problem and so can boot under Xen even with the new kernel.
to the top