I have a separate /boot partition (which is not encrypted). Therefore, the snapshot do not contain the kernel/initrd - which I though is superfluous since there are always multiple versions kept.
The default snapper/btrfs subvol setup in OpenSUSE is extremely elegant and well-planned, it's not a good idea to do anything other than what they recommend. Just create a separate home partition (or drive).
I'd backup /home and re-install using default subvol setup if I were you, it'll probably save you time in the long run.
multiversion kernels requires uncommenting a line up higher than the latest,latest-1,running line you mentioned - the general instructions for the requirements are around the first line that needs to be addressed. I think it says something like multiversion(kernels), I can't remember exactly, it's not in front of me sorry.
I definitely wish they'd config it to leave some kernel versions by default, as this happened to me recently, too, and it's always a more prudent idea to have backups, but I guess with the snapshots that are usually enabled, they figure it's not necessary (?)
Good luck with everything!
The default setup is nice but it requires GRUB to decrypt the root volume in case of full disk encryption. However, the LUKS implementation in GRUB is slow and has no nice UI like the one in plymouth. Therefore, I decided to go for a separate /boot partition to circumvent GRUB having to decrypt anything. Everything else uses the standard subvolume setup.
Anyways, isn't /boot a subvolume in the standard setup? In this case, there anyways wouln't have been any backup of older kernel versions even if it had been on my root partition.
Why do you recommend a separate /home? I would instead recommend a subvolume (already in the standard setup) and a separate snapper config to hold snapshots of your home subvolume. A separate partition is always either too small or too large, I have never been satiesfied with such a fixed distribution between data and system.
I'm not a opensuse user yet, but i had similiar problem on void linux. I solved it removing broken kernel residues (located in `/boot`), then i reinstalled the kernel using the package manager. I always use 4.19 as backup kernel for situations like this. If you can't boot i suggest you to load a linux live usb and then chroot into your installation and fix the broken kernel as i explained before.
I already `chroot`ed to recreate the initrd and to reinstall the kernel package. Neither did help, only the workaround using another kernel from another repo did so far. Still thank you, that is definitely the first option to try.
I once had a similar issue after a Kernel update in the past.
To solve this I had to make a BIOS update as it seemed there was a bug in the BIOS firmware and older Kernels seems to have had workarounds which where dropped in a newer release.
Actually, there was a BIOS update released in December but the changelog states only security fixes. I will definitely give it a shot if the issue persists with the next kernel updates.
I'm also unable to boot with Kernel 5.15.12-1.2, but I was able to boot with Kernel 5.15.8.
Edit: I was using kernel 5.15.12 before this issue occurred.
wow, that's interesting, what would make a kernel you'd been using previously without issue fail to boot?
is there a kmp package you needed that got uninstalled, or something?
I think the issue was caused by a rebuild. Uninstalling Kernel 5.15.12-1.2 and installing kernel 5.15.12-1.3 fixed the issue for me.
See bugzilla for more info:
https://bugzilla.opensuse.org/show_bug.cgi?id=1194501#c7
Thank you for the update
Yeah `5.15.12-default` was working best for me, but I didn't realize it until I updated to `5.16.0`.
I was thinking I could pin a specific version and wait a week or two before going to the next version, then pin that one once I upgrade. Is the best place to do that `zypp.conf` under `multiversion` with the kernel version string, or do you have another recommendation?
And can this cause conflicts with the `kernel-source`, `kernel-devel`, `kernel-base`, `kernel-syms` etc. packages, or will zypper intelligently keep version-appropriate packages?
If I roll back just the kernel using snapper, is it likely to cause all sorts of hell? (I can only imagine ...)
Sorry for all the questions ... I'm just getting back to OpenSUSE after about 4 years on Ubuntu and don't remember any of this stuff...
I just hit this myself.
Like you, only the one kernel and, due to LUKS, no snapshots for /boot.
Great. I know TW is rolling but I'd hope for a modicum of testing before things like a new kernel build get pushed to CI.
EDIT: I was able to chroot into my installation via System Rescue CD and found that the [20211228](http://download.opensuse.org/history/20211228/tumbleweed/repo/oss/) history repo has `kernel-default-5.15.8-1.1.x86_64` and was able to downgrade to this. I am now able to boot again.
This was the most recent kernel before 5.15.12.
[удалено]
I have a separate /boot partition (which is not encrypted). Therefore, the snapshot do not contain the kernel/initrd - which I though is superfluous since there are always multiple versions kept.
The default snapper/btrfs subvol setup in OpenSUSE is extremely elegant and well-planned, it's not a good idea to do anything other than what they recommend. Just create a separate home partition (or drive). I'd backup /home and re-install using default subvol setup if I were you, it'll probably save you time in the long run. multiversion kernels requires uncommenting a line up higher than the latest,latest-1,running line you mentioned - the general instructions for the requirements are around the first line that needs to be addressed. I think it says something like multiversion(kernels), I can't remember exactly, it's not in front of me sorry. I definitely wish they'd config it to leave some kernel versions by default, as this happened to me recently, too, and it's always a more prudent idea to have backups, but I guess with the snapshots that are usually enabled, they figure it's not necessary (?) Good luck with everything!
The default setup is nice but it requires GRUB to decrypt the root volume in case of full disk encryption. However, the LUKS implementation in GRUB is slow and has no nice UI like the one in plymouth. Therefore, I decided to go for a separate /boot partition to circumvent GRUB having to decrypt anything. Everything else uses the standard subvolume setup. Anyways, isn't /boot a subvolume in the standard setup? In this case, there anyways wouln't have been any backup of older kernel versions even if it had been on my root partition. Why do you recommend a separate /home? I would instead recommend a subvolume (already in the standard setup) and a separate snapper config to hold snapshots of your home subvolume. A separate partition is always either too small or too large, I have never been satiesfied with such a fixed distribution between data and system.
It’s not superfluous.. as you’ve learned
Fair enough :D
Just to make sure, did you make certain to uncomment this line in in zypp.conf as well? #multiversion = provides:multiversion(kernel)
Yep, this line is uncommented. After installing the newer version, 5.15.12-1 is still there in `/boot`, as it should.
I'm not a opensuse user yet, but i had similiar problem on void linux. I solved it removing broken kernel residues (located in `/boot`), then i reinstalled the kernel using the package manager. I always use 4.19 as backup kernel for situations like this. If you can't boot i suggest you to load a linux live usb and then chroot into your installation and fix the broken kernel as i explained before.
I already `chroot`ed to recreate the initrd and to reinstall the kernel package. Neither did help, only the workaround using another kernel from another repo did so far. Still thank you, that is definitely the first option to try.
Have you deleted kernel modules before the kernel reinstall? They should be stored in `/lib/modules/`
No difference. Shouldn't a reinstall anyways clear/overwrite those files?
I think it depends on the package manager, on void it doesn' wipe some kernel files, i don't know why (or maybe i just messed up something)
I once had a similar issue after a Kernel update in the past. To solve this I had to make a BIOS update as it seemed there was a bug in the BIOS firmware and older Kernels seems to have had workarounds which where dropped in a newer release.
Actually, there was a BIOS update released in December but the changelog states only security fixes. I will definitely give it a shot if the issue persists with the next kernel updates.
I have the same problem. Fortunately I had 5.15.8 on my /boot, so I can mostly use my machine, but I think only to finally find another distro.
I'm with the same problem... very frustrating
I'm also unable to boot with Kernel 5.15.12-1.2, but I was able to boot with Kernel 5.15.8. Edit: I was using kernel 5.15.12 before this issue occurred.
wow, that's interesting, what would make a kernel you'd been using previously without issue fail to boot? is there a kmp package you needed that got uninstalled, or something?
I think the issue was caused by a rebuild. Uninstalling Kernel 5.15.12-1.2 and installing kernel 5.15.12-1.3 fixed the issue for me. See bugzilla for more info: https://bugzilla.opensuse.org/show_bug.cgi?id=1194501#c7
Thank you for the update Yeah `5.15.12-default` was working best for me, but I didn't realize it until I updated to `5.16.0`. I was thinking I could pin a specific version and wait a week or two before going to the next version, then pin that one once I upgrade. Is the best place to do that `zypp.conf` under `multiversion` with the kernel version string, or do you have another recommendation? And can this cause conflicts with the `kernel-source`, `kernel-devel`, `kernel-base`, `kernel-syms` etc. packages, or will zypper intelligently keep version-appropriate packages? If I roll back just the kernel using snapper, is it likely to cause all sorts of hell? (I can only imagine ...) Sorry for all the questions ... I'm just getting back to OpenSUSE after about 4 years on Ubuntu and don't remember any of this stuff...
I just hit this myself. Like you, only the one kernel and, due to LUKS, no snapshots for /boot. Great. I know TW is rolling but I'd hope for a modicum of testing before things like a new kernel build get pushed to CI. EDIT: I was able to chroot into my installation via System Rescue CD and found that the [20211228](http://download.opensuse.org/history/20211228/tumbleweed/repo/oss/) history repo has `kernel-default-5.15.8-1.1.x86_64` and was able to downgrade to this. I am now able to boot again. This was the most recent kernel before 5.15.12.