Did you look at your last CODE section? The command is very different from what you say it produces
For the rest, no we do not need a preempt kernel. Maybe that is something that should ve solved first.
zypper se preempt
Also, did you do the zypper clean and zypper --releasever 15.4 ref correct (my steps 7 and 8)?
Then I do not see the --allow-vendor-change I suggested in my step 9. Any explanation?
OK I am getting a bit confused. Not used to do things in the terminal.
I have not started the upgrade yet according to the one with coffe break you posted ^^ . I will do an attempt later today. Just wanted to be sure I am not messing it up by ignoring the kernel preempt issue.
Thanks for all support!
I had four sections. The first is answered I think.
But we should attend the second about the preempt kernel first before you carry on!. So please:
zypper se preempt
Here it is :
zypper se preempt
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+---------------------------------------+----------------------------------------------------------------------------+-----------
| bbswitch-kmp-preempt | Bumblebee ACPI kernel module | package
| cluster-md-kmp-preempt | Clustering support for MD devices | package
| crash-kmp-preempt | Crash utility for live systems; netdump, diskdump, LKCD or mcore dumpfiles | package
| dlm-kmp-preempt | DLM kernel modules | package
| dpdk-kmp-preempt | DPDK KNI kernel module | package
| drbd-kmp-preempt | Kernel driver | package
| gfs2-kmp-preempt | GFS2 kernel modules | package
| kernel-livepatch-5_3_18-24_64-preempt | Kernel live patch module | package
i | kernel-preempt | Kernel with PREEMPT support | package
| kernel-preempt | Kernel with PREEMPT support | srcpackage
i | kernel-preempt-devel | Development files necessary for building kernel modules | package
i | kernel-preempt-extra | Kernel with PREEMPT support - Unsupported kernel modules | package
| kernel-preempt-livepatch-devel | Kernel symbols file used during kGraft patch development | package
i | kernel-preempt-optional | Kernel with PREEMPT support - Optional kernel modules | package
| kselftests-kmp-preempt | Kernel sefltests | package
| lttng-modules-kmp-preempt | Licensing information for package lttng-modules | package
| mhvtl-kmp-preempt | Virtual Tape Library kernel module | package
i+ | nvidia-gfxG05-kmp-preempt | NVIDIA graphics driver kernel module for GeForce 600 series and newer | package
| ocfs2-kmp-preempt | OCFS2 kernel modules | package
| openafs-kmp-preempt | OpenAFS Distributed File System - kernel module | package
| oracleasm-kmp-preempt | Kernel driver backing the Generic Linux ASM Library | package
| pcfclock-kmp-preempt | Pcfclock kernel driver | package
| reiserfs-kmp-preempt | Reiserfs kernel module | package
| rtl8812au-kmp-preempt | Kernel driver for Realtek 802.11ac rtl8812au wifi cards | package
| rtw89-kmp-preempt | Driver for Realtek 8852AE Wifi chip | package
| v4l2loopback-kmp-preempt | A kernel module to create V4L2 loopback devices | package
| vhba-kmp-preempt | Virtual SCSI Host Bus adapter | package
| virtualbox-kmp-preempt | Kernel modules for VirtualBox | package
| xtables-addons-kmp-preempt | IP Packet Filter Administration Extensions | package
So you indeed have the kernel-preempt installed, which is not OK.
I am not good at this (let us hope others will tune in), but in the mean time we can gather some more information.
To begin with, which kernel is running:
uname -r
And see which kernels are installed:
zypper se -si kernel | grep -v firm
I cannot even be sure I installed the preempt but I doubt I did, if I installed it perhaps some module needed it.
Why is having the preempt a bad deal btw?
I could remove the preempt kernel and its files I suppose…
**linux-5wbg:~ #** uname -r
5.3.18-150300.59.90-preempt
[FONT=monospace]zypper se -si kernel | grep -v firm
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-----------------------------+---------+------------------------+--------+-------------------------------------------------------------
i+ | kernel-default | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-devel | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-devel | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-devel | package | 5.3.18-57.3 | x86_64 | Main Repository
i | kernel-default-extra | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-extra | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-optional | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-default-optional | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel | package | 5.3.18-150300.59.90.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel | package | 5.3.18-150300.59.87.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel | package | 5.3.18-57.3 | noarch | Main Repository
i+ | kernel-macros | package | 5.3.18-150300.59.90.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-devel | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-devel | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-devel | package | 5.3.18-57.3 | x86_64 | Main Repository
i | kernel-preempt-extra | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-extra | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-optional | package | 5.3.18-150300.59.90.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i | kernel-preempt-optional | package | 5.3.18-150300.59.87.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | purge-kernels-service | package | 0-8.3.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
[/FONT]
Already some time ago, there were several threads here about people having got kernel-preempt. I am not sure if it was some one-click problem, but there was a bug report and it was solved. It seems you still have the kernel-default. And once you have it, it will be updated at every update. So you must get rid of it, But as you are using it now, it would be suicide for the system to just remove those packages. First we must see that you switch to kernel-default.
Because I am not 100% sure how to do this, I already warned in my post above. And I do not want that my suggestions give you an unusable system 
So let me think it over.
Learning something new every day. I’m a GUI guy and rarely open the terminal.
Oh, I have preempt as default? I haven’t had any issues with my openSUSE system with kernel preempt. I will try to read it up a bit.
Thanks for your considerations. I really appreciate the time and efforts by you and others.
Found some posts about preempt. Some users have virtualbox that requires preempt. I do not have virtualbox.
Seems some managed to remove preempt files by simply deleting them from Yast.
Or this post ;
As said, you better do NOT remove the kernel you are using! Looks clear to me.
I think we can try this (and it is using the GUI 
)
I do not have a English language YaST here, thus translations may differ from what you see.
YaST > System > Bootloader. There is a tab Options for Bootloader. There you see a menu Default start session. Select your kernel-default there.
Then a reboot should use that one. Check with
uname -r
When that is correct, you can now use YaST > Software > software Management to Search for all preem
Alternatively…
Assuming you have “kernel-default”, “kernel-default-extra”, and “kernel-default-optional” already installed then just reboot, and at the grub screen:
“Advanced Options” and Select kernel-default from there.
If that boots OK then:
Yast -> Software Management -> Options - “Cleanup when deleting packages”
followed by:
Search (for kernel-preempt) and select any installed for removal.
I would also remove the proprietary nvidia packages (if you still have those installed), and temporarily disable the nvidia repository until after you have successfully performed the “zypper dup”
Thanks! I changed to default. But cannot remove preempt as Nvida seems to be needing those. I will keep them for now.
Now I will attempt the upgrade. Wish me luck ^^
I think that is good alternative way of doing it.
And do not forget the zypper clean and zypper ref commands!!!
I will repeat what I wrote in comment #31
I would also remove the proprietary nvidia packages (if you still have those installed), and temporarily disable the nvidia repository until after you have successfully performed the “zypper dup”
In fact he has removed the nvidia repo completely (not just disabled it). But yes, falling back might be better, because after the upgrade the nvidia driver and 15.4 will not match.
Thinking about that further… will not having a specific kernel version specified there cause problems after the zypper dup? don’t know as I’ve never done it… will that (kernel) be removed by the purge-kernels.service on reboot? meaning the subsequent boot will no longer have the kernel specified… I have a “bad feeling”…, but it’s been a long and stressful day today with few coffees… I may have just gone into “alarmist” mode.
Guys,
I got to point 6 (zypper --releasever 15.4 dup --allow-vendor-change.) but after that I got stuck.
The installer asked me to choose to either break or keep or de-install basically everything on my system (I think)
(including Chromium!). So at that point I stopped the installation process fearing I would break something for real and render my system unbootable.
I think something serious has silently happened to my system. I’ve upgraded from 15.1 to 15.3 without issues so I am rather surprised 15.4 is giving me these issues.
Perhaps it’s better to do a clean install?
What I don’t understand is, looking at Yast / repos I still have Leap 15.3 URI. I thought I’d have a look at those in case the URIs were pointed to 15.4 as after the pre-installation terminal commands.
I am not sure about all this. What I saw at upgrading is that only the new 15. kernel was kept and that the 15.3 kernel was gone. Of course the kernel purge function would (as default) keep at least two kernels, but it is logical that no 15.3 kernel is kept. Either by the upgrade or by the purge (I guess the upgrade). And that new 15.4 kernel will most probably be used in a new Grub configuration and dracut mkinitrd as part of the upgrade. Erasing all old stuff from them.
But I am afraid that the proof of this pudding is …
The default string for version will only change from 15.3 to 15.4 AFTER the installation of the new packages (in fact it is only one of those packages, but it will be included in the big upgrade). And you broke it off, so it is still 15.3 when you do not specify different (with --releasever).
As we can not see exactly what the zypper dup says it is difficult to comment on that.
Personally I would guess that chromium, which is in the 15.4 OSS repo, just should upgrade. For chromium it is of course not a disaster when it is only removed, because it is only an end-user program and can be installed later easy enough. But the same situation for important system packages would be different.
But, as said, we can not look over your shoulder, we can not really check waht messages are there.
In any case, your repo refresh is now done from the 15.4 repos and does not fit to your 15.3 installation as it is. So not NOT install anything before this either is sorted out and went forward into 15.4, or you have done a step back with a zypper clean and a zypper ref, to get 15.3 info back.