How to Revert to a different /boot image after having boot problems
SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to Revert to a different /boot image after having boot problems
I recently had some issues where SUSE 15.3 was having a problem updating due to this message.
Quote:
the to be installed patchpenSUSE-2022-109-1.noarch conflicts with 'libvlccore9.x86_64
I noticed that libvlccore9.x86_64 was associated with Kaffeine player and I believe that was conflicting with VLC.
So, I removed Kaffeine and rebooted and then did the updates via "Yast Online Updater". The updater still found some conflicts with VLC and/or Kaffeine and I told it to remove some stuff. I think it was getting mixed info between pacman repos and the SUSE repo's or something.
After I did this the system got hung rebooting. I then tried rebooting but was unable to get it to boot.
It was hanging up saying something like this>
Quote:
huh, entered softirq 0 HI ....
So I used advanced boot and was able to get it to boot up by manually selecting the 59.87 preempt or the 59.87 default. I already went in and removed a few snapshots but I'm worried I might brick something if I remove anything else. Here's what I currently have in Yast Admin "File System Snapshots". I want to remove the 59.90 preempt and default and just boot off 59.87 so I can try to get my updates applied correctly.
I don't believe I should just delete these out of my /boot?
Bootable (Want to make default)
-rw------- 1 root root 17244996 Aug 26 10:18 initrd-5.3.18-150300.59.87-default
-rw------- 1 root root 17229580 Aug 26 10:19 initrd-5.3.18-150300.59.87-preempt
Unbootable > (want to remove)
-rw------- 1 root root 17781676 Aug 26 10:19 initrd-5.3.18-150300.59.90-default
-rw------- 1 root root 17775892 Aug 26 10:19 initrd-5.3.18-150300.59.90-preempt
Here's a picture I took on boot up showing these menus under "advanced" boot option. Not sure how to post images on herfe? https://i.imgur.com/xKIVZ5z.jpg
Here's a picture of my snapshots that didn't have the "important=yes" message in them. I'm not going to remove anymore of these. https://i.imgur.com/sdkD7Tw.png
I found a "temporary" work-around by using Yast Boot Loader and changing the Default Boot section to 59.87 default.
Now when I boot it selects the advanced menu and then selects this image and boots up fine. However, I would prefer to get this back to using the "openSUSE leap 15.3" default boot menu in boot loader settings > bootloader options.
I think it was getting mixed info between pacman repos and the SUSE repo's or something.
Could "or something" be that you have enabled a VLC repo? VLC repos and Packman repos should never be enabled at the same time. Enable either one or the other, not both.
Never delete files from /boot/ manually. Let the package management system do its job. If you want a kernel removed, use zypper or yast.
Whatever the reason 59.90 kernels won't boot, it's not a problem to remove them whilst booted to any older kernel.
Online updaters make poor resolvers. When any kind of conflict arises in the updater, zypper should be employed to apply updates instead of any desktop updater trying to apply patches instead of packages. It does a better job of explaining what's going on, and deciding what needs doing, giving you choices when necessary.
Whenever you want to share a screenshot, please do not use one that depends on scripts. Most distros provide a free way to do so with no script risk or encumbrance. openSUSE provides susepaste for the purpose. https://i.imgur.com/ is not available here.
Assuming you have only one or the other of VLC and Packman repos enabled, you can probably resolve the libvlccore9 issue and kernel situation both thusly:
Code:
sudo zypper ref
sudo zypper up
sudo zypper rm kernel-preempt-5.3.18-150300.59.90.1 kernel-default-5.3.18-150300.59.90.1
sudo zypper al kernel*5.3.18-150300.59.90*
In order for this to work, the online updater must not be running. The easy way to do this is to not login at the GUI greeter, but to keyin Ctrl-Alt-F3 to reach a text console, then run those commands. As a consequence of the 59.90 removals, the grub menu will be regenerated, leaving the most recent remaining kernel as default in Grub. Alt-F7 to return to the GUI login greeter when finished to login normally or reboot.
Great! Thanks for this excellent information. I'm going to work on this Sunday with you recommended solution! Also I tried to give you rep points but it said I need more points.
Hello, I realized I have a new problem. When I choose Windows to boot off of in Grub menu I get this error and it wants to try and do different options. I tried changing to my Windows boot partition in BIOS and I'm greeted with the same message.
windows 10 0xc000000e
This error basically indicates Windows has a problem with the boot loader and gives a blue screen with different options I mentioned above. F8 For setup, Enter UEFI BIOS, etc.
I tried changing it back to how it was in bootloader options with the Top SUSE menu. I think I have to try to boot off Windows recovery drive and then run these commands.
bootrec /scanos
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd
I'm probably going to try that but I was wondering if that's going to overwrite the GRUB and prevent me from booting in SUSE? I'm not sure if a few of the smaller snapshots I deleted cause it to mess up the BCD boot loader?
Appreciate any additional pro tips before I try the recovery method above to get back into Windows 10.
What Windows will do in recovery depends on how it and openSUSE were installed. If boot mode was UEFI for both, then a Windows boot repair should not affect openSUSE directly. It can be expected to make itself the default boot option as part of its repair process. This you should be able to easily change back either via BIOS setup priority reordering, or using the BBS menu to select openSUSE, from which you can use YaST or efibootmgr (what I always use) to reinstate openSUSE as the default. Most Windows 10 installations are using UEFI, and openSUSE is usually later installed in the same mode as Windows.
If Windows and openSUSE are both installed in legacy BIOS/MBR mode, and Grub is installed in the MBR, then Windows will replace the Grub code with neutral code that will make Windows the default. As a result it will be necessary to boot some live Linux media from which you can reinstall Grub.
If Windows and openSUSE were installed in opposite modes, then it's more complicated to fix. It's least likely this is what you have. If could be helpful if you were able to boot openSUSE and collect output to paste here from:
Code:
sudo parted -l
cat /etc/fstab
sudo lsblk -f
I'm totally unfamiliar with how snapshotting may affect the bootloader, as I only ever use EXTx filesystems for openSUSE, on which snapshotting is not available.
The easiest fix is probably just to let Windows do its repair, use Windows to create openSUSE 15.4 installation media, then use it to upgrade 15.3 to 15.4.
What Windows will do in recovery depends on how it and openSUSE were installed. If boot mode was UEFI for both, then a Windows boot repair should not affect openSUSE directly. It can be expected to make itself the default boot option as part of its repair process. This you should be able to easily change back either via BIOS setup priority reordering, or using the BBS menu to select openSUSE, from which you can use YaST or efibootmgr (what I always use) to reinstate openSUSE as the default. Most Windows 10 installations are using UEFI, and openSUSE is usually later installed in the same mode as Windows.
If Windows and openSUSE are both installed in legacy BIOS/MBR mode, and Grub is installed in the MBR, then Windows will replace the Grub code with neutral code that will make Windows the default. As a result it will be necessary to boot some live Linux media from which you can reinstall Grub.
If Windows and openSUSE were installed in opposite modes, then it's more complicated to fix. It's least likely this is what you have. If could be helpful if you were able to boot openSUSE and collect output to paste here from:
Code:
sudo parted -l
cat /etc/fstab
sudo lsblk -f
I'm totally unfamiliar with how snapshotting may affect the bootloader, as I only ever use EXTx filesystems for openSUSE, on which snapshotting is not available.
The easiest fix is probably just to let Windows do its repair, use Windows to create openSUSE 15.4 installation media, then use it to upgrade 15.3 to 15.4.
Thanks again for your response and info. My primary concern is restoring Windows because I don't want to loose my Licence. I has Windows 8 on this older laptop and then upgraded to 8.1 and then installed SUSE after that. I've upgraded multiple releases in 15.x versions since then. I upgraded this laptop from Windows 8.1 to 10 a few months back and was able to retain my SUSE 15.3 Dual boot then. I'm almost certain it's in UEFI mode as can be seen in some of my partition screen shots below.
I captured a few screen shots in addition to the output you requested. I'm going to probably backup my SUSE data now.
I was thinking of Setting SUSE 15.3 to the use this image to use since it works.
I wasn't sure if it mattered if I use default or preempt but I suppose I'll stick with default.?
-rw------- 1 root root 17244996 Aug 26 10:18 initrd-5.3.18-150300.59.87-default
-rw------- 1 root root 17229580 Aug 26 10:19 initrd-5.3.18-150300.59.87-preempt
Then I was going to reboot with and select Windows partition boot in Grub at which point I'll get the windows 10 0xc000000e BCD Windows boot blue screen. Then I'll select boot from Recovery with my USB Win 10 recovery drive to see if I can try this.
1st) Attempt automatic recovery or repair OS for me method. If that doesn't work I was going to move on to
2nd) Attempt recovery via Win 10 recovery boot USB drive at admin command prompt. Run the following>
I'm hoping one of these two methods might recover Windows and retain the Grub Dual boot and fix Windows boot within the Grub menu?
I was also thinking a few other ways or things might potentially fix this.
-Running an update in Suse where it updates the latest Linux Kernel and it usually also rescans the Boot sector and See's usually sees Windows parition while scanning and updating with the Suse automatic update tool. Or manual update. or zypper update? LOL.
I was even thinking of using boot-repair USB boot utility to see if that might fix this issue. I'm also going to backup my Suse Data I want in case of any issues. Either way, I should take the best approach and greatly appreciate the pro tips!
I was also checking where my efi where the bootloader resides. I would imagine with windows diskpart utility after booting with recovery USB I can locate the boot drive and see which one is set to active.
UUID=4032-6F74 /boot/efi vfat defaults 0 0
I confirmed this via the "partitioner" tool built into Yast System Control Center.
Did you resize the efi partition at sometime. The efi partition created and used by windows is normally only 100M, whereas your efi parition is 300M. Post the contents of the /boot/efi/EFI
Last edited by colorpurple21859; 08-28-2022 at 08:02 PM.
Did you resize the efi partition at sometime. The efi partition created and used by windows is normally only 100M, whereas your efi parition is 300M. Post the contents of the /boot/efi/EFI
Hi, here's my EFI partition details. I never resized it and it's always been 300M from what I recall.
I also included the parted -l mrmazda asked for previously. Appreciate any additional insight. I'm debating on trying to upgrade from 15.3. to 15.4 using zypper to see if that might some how correct the Windows boot. It's not likely to fix it so I appreciate any input. The only thing I've done is make sure I can boot from my Windows 10 recovery USB drive.
It thinks I have Windows 8.x installed though because it says repair Windows 8 when I start up with the USB Recovery I created in Windows 10 a few months back.
Code:
# parted -l
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 945MB 944MB ntfs Basic data partition hidden, diag
2 945MB 1259MB 315MB fat32 EFI system partition boot, esp
3 1259MB 1394MB 134MB Microsoft reserved partition msftres, legacy_boot
4 1394MB 181GB 179GB ntfs Basic data partition msftdata
5 181GB 181GB 540MB ntfs hidden, diag
6 181GB 181GB 8389kB bios_grub
7 181GB 184GB 2147MB linux-swap(v1) swap
8 258GB 384GB 125GB ntfs Basic data partition msftdata
9 384GB 500GB 116GB btrfs
Model: ST500LT0 12-9WS142 (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 500GB 500GB ntfs Basic data partition msftdata
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
...
5 181GB 181GB 540MB ntfs hidden, diag
6 181GB 181GB 8389kB bios_grub
7 181GB 184GB 2147MB linux-swap(v1) swap
8 258GB 384GB 125GB ntfs Basic data partition msftdata
This is an invalid mess. There cannot be three different partition types starting at 181GB yet ending different places. There's no good reason for a bios_grub partition on the same disk as an ESP for an average user PC either. This looks like Linux has been installed in legacy/BIOS mode, reason enough for multiboot with Windows trouble. What do
Hi colorpurp & mrmazda. Is this what you want? I'm going to boot off my Recovery Drive and run diskpart to see which partition is set to active. I would imagine it should be my efi/UEFI partition. Again, appreciate all the valuable input from both of you!
Code:
asus2:/sys/firmware/efi # ls -ltr
total 0
drwxr-xr-x 2 root root 0 Aug 29 13:44 efivars
drwxr-xr-x 87 root root 0 Aug 30 10:34 vars
-r-------- 1 root root 4096 Aug 30 10:34 systab
drwxr-xr-x 2 root root 0 Aug 30 10:34 secret-key
drwxr-xr-x 36 root root 0 Aug 30 10:34 runtime-map
-r--r--r-- 1 root root 4096 Aug 30 10:34 runtime
drwxr-xr-x 2 root root 0 Aug 30 10:34 mok-variables
-r--r--r-- 1 root root 4096 Aug 30 10:34 fw_vendor
-r--r--r-- 1 root root 4096 Aug 30 10:34 fw_platform_size
-r--r--r-- 1 root root 4096 Aug 30 10:34 config_table
Also, here's my repos. It looks like I only have packman enabled. I don't see a repo specific to VLC.
FYI, I just booted with my Win 10 recovery USB drive and ran disk part. I see that partition 2 volume 3 is set to active. That is,
Label 4032-6F74
What's odd is it shows C as recovery and D where Windows is installed. Normally when I get into Windows C: is where Windows is and D: is my secondary partition instead of E listed in diskpart. Appreciate any additional input before I attempt any recovery.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
How to Revert to a different /boot image after having boot problems
