Hi 
on my laptop TUXEDO InfinityBook Pro 15 v4, ssd disk=2Tb, /home EXT3 partition=58Gb, processor= Intel Core i7-8565U, RAM=32Gb, graphics card Model: “Intel UHD Graphics 620 (Whiskey Lake)” with tri boot leap 15.1, leap 15.2, windows 10running leap 15.2 KDE neon after the last update stuck after boot choosing leap 15.2 at “loading initial ramdisk…” and only hard switch off works.
with kernel 5.3.18-lp152.69 it stucks, booting with kernel 5.3.18-lp152.66 leap 15,2 it boot and login fine.
is there any solution?
manythanks, ciao, pier
There are some earlier threads on this. And there are two bug reports.
My understanding is that there will soon be another kernel update to fix the problem.
manythanks, reading the thtread you mentioned I found that adding “intel_iommu=off” in the grub parameters editing it pressing “e” during the boot works,
is it safe to leave the “intel_iommu=off” permanently in the grub parameters?
or is better to remove kernel 5.3.18-lp152.69 as gldickens3 says in the thread??
and how can I do this removing safely?
manythanks, ciao, pier
That’s for you to decide. I’m not aware of other issues that it cause.
or is better to remove kernel 5.3.18-lp152.69 as gldickens3 says in the thread??
If you do that, it will show up as a needed update. It seems easier to just wait for a newer kernel.
and how can I do this removing safely?
When I manually remove a kernel, I normally use Yast Software Manager, and then use the “Versions” tab.
I would simply continue booting the 66 kernel until a newer than 69 shows up, because it’s easy.
New kernel is in the update-test Repo:
- Di Apr 13 2021 jroedel@suse.de
- iommu/vt-d: Use device numa domain if RHSA is missing (bsc#1184585).
- Refresh patches.suse/iommu-vt-d-fix-ineffective-devtlb-invalidation-for-subdevices.
- commit 6ad821c
manythanks 
but if I install the new kernel and it has another bug I will find the non working kernel as the second option and it is not a good thing.
I found these instructions here:
https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-tuning-multikernel.html
that says as an example:
Change the following line in /etc/zypp/zypp.conf:
multiversion.kernels = latest,latest-1,latest-2,running
so I changed that line in /etc/zypp/zypp.conf in this way
multiversion.kernels = latest,latest-1,latest-2,latest-3,5.3.18-lp152.66,running
is this a good way to have the latest 4 kernes as options and the 5.3.18-lp152.66 that surely works?
manythanks, ciao pier
That’s one solution.
Another is removing each non-working kernel, so currently .69.
I typically add oldest to multiversion.kernels.
New Kernel is out:
i+ | kernel-default | Paket | 5.3.18-lp152.72.1 | x86_64 | OSS-Update
Update to .72 has just arrived:
~> LANG=C zypper se -iv kernel
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-----------------------+---------+-----------------------------+--------+--------------------------------
i+ | kernel-default | package | 5.3.18-lp152.66.2 | x86_64 | Hauptaktualisierungs-Repository
name: kernel-default
i+ | kernel-default | package | 5.3.18-lp152.69.1 | x86_64 | Hauptaktualisierungs-Repository
name: kernel-default
i+ | kernel-default | package | 5.3.18-lp152.72.1 | x86_64 | Hauptaktualisierungs-Repository
name: kernel-default
Yes, that’s what I do. That way I always have a kernel that is known to work.
When there is a newer good kernel, I manually remove the oldest (with the “Versions” tab in Yast Software Management), so that “oldest” then becomes one newer than it previously was.
Really? One minute ahead?
I’m just posting too slow.
grep -i '5.3.18-lp152.72.1' /var/log/zypp/history
# 2021-04-19 18:09:03 kernel-default-5.3.18-lp152.72.1.x86_64.rpm installed ok
2021-04-19 18:09:03|install|kernel-default|5.3.18-lp152.72.1|x86_64||repo-update|39409391ec8f147ce3fbb81c64d18baf4cf016da6353e4b76f0992f4be401bd8|
Depends on your mirror you switched with download.opensuse.org…
Hehe, thanks - and sorry. I was just moaning about my personal posting speed. :shame:
Maybe turn off hardware immu in the BIOS. I had to do that sever versions back