Current system has SuSE 13.1 on sdb (and Windows) and boots there by default. Installed Leap 42.1 on sda2 but set YaSTst bootloader back to 13.1. Now cannot access or see 42.1 in bootloader under options.
Installed recent grub2 security patch:
CVE-2015-8370: Fix for overflow in grub_password_get and grub_user_get functions (bnc#956631)
openSUSE 13.1: zypper in -t patch openSUSE-2015-957=1
but would not expect this to alter configuration files and have not seen anything to this effect in the forums or on web.
Modified /etc/grub.d/40_custom as follows:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "openSuSE 42.1" {
set root=(hd0,1)
linux /boot/vmlinuz
initrd /boot/initrd.img
}
ran in YaST and then:
linux-3:~ # grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.10-29-desktop
Found initrd image: /boot/initrd-3.11.10-29-desktop
Found linux image: /boot/vmlinuz-3.11.10-21-desktop
Found initrd image: /boot/initrd-3.11.10-21-desktop
No volume groups found
Found Microsoft Windows XP Professional on /dev/sda1
Found openSUSE 42.1 (x86_64) on /dev/sda2
done
linux-3:~ #
Leap 42.1 still doesn’t appear. I can mount the entire file system and see the files - just can’t enable them in grub.
I could reinstall (probably take much less time than all of this investigation).
Yes, if I recall correctly when I installed 42.1 on Dec. 1, 2015, the YaST bootloader offered both options. I configured the pc for triple boot, with 13.1 retaining the bootloader.
As stated previously, I maintained the 13.1 bootloader; during the install of 42.1, I took the defaults and did not set up a new bootloader. (I’ve done this previously on another workstation.)
Here is the output from os-prober:
linux-3:~ # os-prober
No volume groups found
/dev/sda1:Microsoft Windows XP Professional:Windows:chain
/dev/sda2:openSUSE 42.1 (x86_64):SUSE:linux:btrfs:UUID=8981a635-b29a-4959-89f7-51c65aa079cc:subvol=@/.snapshots/1/snapshot
linux-3:~ #
I did not understand arvidjaar’s request; as I stated, I am unfamiliar with many of these tools.
Regarding what I believe is your reference to today’s post, I felt that my questions here were not properly focused and am seeking specific information in the other post, namely, how does one format the 40_custom file. It is not my intent to abuse this forum - as you can tell from my ID, I am a novice, characterized as a “Student Penguin,” and I post infrequently.
If linux-boot-prober doesn’t find it, IMHO there is no way to solve the problem via 40_custom configuration.
As to why this happens, hope that arvidjaar shows up again…
Thank you. First, I created the problem and hoped to better understand what happened. A fix seemed tantalizingly close. I can see the install - just can’t access it.
One thing I did notice this morning. I have 13.2 on another machine and 42.1 on yet another. In both, YaST bootloader shows the boot loader in the root partition, not the MBR as on the 13.1 machine. Perhaps for two different reasons. The 13.2 machine is triple boot, with the 13.2 added to an existing 13.1/XP double boot installation, and during install I did not write a new MBR. In the case of the 42.1 machine, that is a single OS installation, so I suspect that MBR and root partition might be one and the same on that PC.
Nevertheless, I might just simply reinstall the Leap OS – I could have done that about ten times already in the time devoted to my investigation. But I have no regrets. I’ve been using SuSE for over ten years (started with 9.x) and it has been very rewarding. And I have learned much with your assistance and the feedback of arvidjaar (I learned about os-prober) - thank you.
Learning is always welcome… then if you manage to boot the new Leap someway (a rescue disk, PartedMagic …) it might be enough to install the Leap Grub2 to replace the 13.1 one, and the new bootloader should be able to find your other OSes.
Having the 13.1 Grub on the MBR might be part of the problem: there is simply not enough room in the MBR for the BTRFS options Leap (or 13.2) usually need.
So the standard practice now with legacy (MBR) booting is writing “generic code” to the MBR and installing the bootloader proper on the /root partition (as is apparently the case with your other systems). Since 13.1 had no (default) BTRFS option, that was not needed a couple of years ago…
It’s tough to recall precisely, but I do remember booting into Leap from the combined bootloader after the install and then changing it to 13.1 until I would have time to finish configuring the install. When I went back a few days ago, the option seems to have disappeared from the YaST bootloader!
I mentioned this briefly at the outset - could the grub2 security patch have done this? I don’t see how - typically patches do not alter config files.
As I said, the remedy all along was reinstall - easily done - something I have already done a few dozen times over the years and I keep fairly detailed documentation about my each of my installs (although apparently I failed to keep track of what I did here!!).
Well, if linux-boot-prober outputs nothing you also do not get anything in GRUB menu. Open bug report for 13.2, component Bootloader, it may be possible to update os-prober to support it.
I do not see how they are related. You always can add something manually.
Don’t know enough about linux to give a definitive solution here…
I have multiple OSS on my system (Windows 7, Manjaro, Linuxmint cinnamon, tumbleweed and Leap). I used Manjaro for writing MBR and generating the grub menu, all other Linux OSs write to their root partitions. The last OS I installed was Leap. After installing and rebooting system. I boot into Manjaro to update the grub menu, thus adding Leap to it menu.
Everytime the Kernel is updated in any of the Linux OSs I would do this. The reason I use manjaro for generating the grub menu is it is the only OS that works and allow me to boot any of the OSs.
I had tried to use 13.2 previously to write the MBR and generate the grub menu and although it saw manjaro it would not boot it when selected, Tumbleweed and Leap also failed to boot manjaro when they wrote the MBR and generated the grub menu.
After you installed leap did you update the grub menu in your preferred system 13.1 so it sees the new OS to update it grub menu, if not the OS listed in your grub menu is not then one just installed. You need to generate the grub menu again in 13.1
Note… I do not use BTRFS on my systems (do not understand it enough as yet)
root = ext4
home = xfs
I reinstalled Leap 42 - but now the 13.1 system fails to boot, despite being listed in the bootloader. I suspect the problem may be that mentioned by OrsoBruno in post #14 - the MBR space issue, but I don’t have enough facility with grub2 and the file systems to know.
I now question whether my selection of BTRFS over Ext4 was a mistake and whether going forward I should opt for Ext4. Would that make a difference? And what would be the potential downsides?
I was about to install Leap 42 on the triple-boot machine (Windows XP, SuSE 13.1, and SuSE 13.2), but will not move forward until I clear up this issue (and a few others associated with the contemplated installation).
On a positive note, the Leap 42 installation went very smoothly and the system is clearly “faster” on the same hardware (vs. 13.1).
With Grub_legacy, SystemV init, Ext4 I used to solve the occasional boot problem myself, but Systemd+Grub2+BTRFS overwhelms me too
That said, if now Leap boots, there should be no problem opening Yast-Bootloader and install “generic code” to the MBR and Grub2 to the Leap /root partition; as long as you don’t delete that partition you should be good to go if you hit the space limit on the MBR. I don’t know if there might be a special problem with your 13.1 install, but on my test laptop the Leap bootloader installed that way finds and boots every kernel installed.
As for BTRFS vs. Ext4, the discussion is still on in some threads.
Generally speaking, I think BTRFS might have benefits in a corporate environment, but on a laptop the only one I see is availability of snapshots and (easy?) rollback if you do a lot of testing or development.
But maybe Snapper and snapshots might be available for Ext4 as well if you really need, even if not installed as a default.
As a downside, BTRFS is still little known by most users (as two of us at least may witness…) and many filesystem tools are still not up to date, so you may end up with a lot of sysadmin docs to learn before really being able to debug filesystem troubles, making Ext4 generally a safer choice if you plan to tinker with your system.
I’m not in a position to advise one way or the other; I use BTRFS in my test setup when beta-testing OpenSUSE, because that is the default “maker’s choice”, but still have Ext4 on my main Leap workhorse.