Goodmorning,
On my system I have the following partitions setup:
-> a / EXT4 partition with openSUSE Linux 15.1;
-> another / EXT4 partition but entirely encrypted with Ubuntu 18.04.4;
-> a /boot partition with GRUB (originally created by Ubuntu).
Recently, I have noticed that after a kernel update, openSUSE updates GRUB removing other entries and leaving just the one about openSUSE itself, (it happens in both cases other entries are GNU/Linux distributions, Windows or BSDs). I have seen this happen in the last versions of Leap (if I correctly remember it didn’t happened on openSUSE 13.1 or 13.2).
Since the Ubuntu partition in this case is encrypted, I think it is somewhat justified that he cannot find another OS, so I would like to know if someone has an idea about the best way to configure GRUB on the openSUSE side to handle correctly this situation.
The best solution, yet uncomfortable, I thought is to configure on the YaST side
-> Custom boot partition on the same /boot
-> every other check disabled (so it does not touch the boot loader)
and whenever openSUSE gets a new kernel I run update-grub / os-prober from Ubuntu.
What do you think about that? Does someone has a better solution for this problem?
Use the “cryptsetup” command (from root command line) to decrypt the Ubuntu partition;
Run (as root in openSUSE)
grub2-mkconfig -o /boot/grub2/grub.cfg
Long term solution: edit “/etc/grub.d/40_custom” to add booting options of Ubuntu. If you want Ubuntu to control the booting, then do that editing on your Ubuntu system. Otherwise do it on the openSUSE system.
What I use, in such a situation, is the “configfile” command in grub – I put that in the “40_custom” file.
Let’s suppose that Ubuntu is controlling the booting. There is a kernel update on openSUSE. Your grub menu entry (from Ubuntu) uses “configfile” to jump to the “grub.cfg” in openSUSE, and that already uses the new kernel because the kernel update has taken care of that. And it works similarly if openSUSE is controlling the booting.
I could give more details if I know more about your system. The output from
fdisk -l
would be helpful here, with accompanying notes as to which partition is used for which linux system.
Interesting. I never ran into that problem, but perhaps that’s because I am not using “btrfs”.
Hmm, there was also a compatibility issue with secure-boot. I took care of that by generating “grub.altcfg” on Ubuntu systems, and using configfile on that. To create “grub.altcfg”, I changed every “linux” to “linuxefi” and every “initrd” to “initrdefi”. But that’s no longer needed now that openSUSE (Tumbleweed and 15.2) is using grub 2.04.
Hi,
so basically are you saying that openSUSE should handle the MBR and point through chainload the Ubuntu /boot partition?
If so, how can I do that in openSUSE?
Following, my fdisk -l (recently, due to some job tasks, I had to install Windows 7, so… it changed the panorama a little bit but the objective is still the same):
$
[sudo] password di root:
Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EFRX-68F
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xccfe69c8
Dispositivo Avvio Start Fine Settori Size Id Tipo
/dev/sda1 2048 206847 204800 100M 7 HPFS/NTFS/exFAT # <----------------------------- Windows 7 boot partition
/dev/sda2 206848 512206847 512000000 244,1G 7 HPFS/NTFS/exFAT # <----------------------------- Windows 7 data partition
/dev/sda3 1433808894 1953523711 519714818 247,8G 5 Esteso # <----------------------------- Ubuntu Linux
/dev/sda4 512206848 1433808893 921602046 439,5G 83 Linux # <-------------------------- openSUSE Linux 15.1
/dev/sda5 * 1433808896 1434787839 978944 478M 83 Linux # <----------------------------- /boot partition made from Ubuntu
/dev/sda6 1434789888 1953523711 518733824 247,4G 83 Linux # <----------------------------- Ubuntu Linux
Partition 3 does not start on physical sector boundary.
Partition table entries are not in disk order.
Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x916ff918
Dispositivo Avvio Start Fine Settori Size Id Tipo
/dev/sdb1 * 2048 921602047 921600000 439,5G 7 HPFS/NTFS/exFAT # <----------------------------- Windows 7 main partition
/dev/sdb2 921602048 1953519615 1031917568 492,1G 7 HPFS/NTFS/exFAT # <----------------------------- Windows 7 data partition
$