I upgraded an old box from Leap 15.0 to 15.2 Beta (Build 617.1, legacy MBR booting). Everything looked OK until…
I tried to boot an old Ubuntu in an EXT3 partition on the same disk: instead of booting the desired 2.6.32 kernel, a reboot occurs.
The old system is sound, SuperGRUB2 disk can boot it, even using the grub.cfg installed by the Leap 15.2 installer (that is, os_prober finds it and configures accordingly).
Is this a new intended behaviour, regression, bug or ? Anybody seeing something similar?
The situation described is admittedly a corner case and I’m not too worried since I have a workaround, but if anybody is interested I have a setup and willingness to contribute testing.
Hmm. Leap 15.2 is using grub2-2.04 (same as Tumbleweed). But Leap 15.1 used grub2-2.02.
I don’t think I have any “ext3” systems to test.
If a reboot occurred, that suggests that grub2 did load kernel and initrd. Grub2-2.04 apparently made some changes to how it loads a kernel. Maybe there’s something odd about Ubuntu kernels that doesn’t quite fit with that.
It turned out that GRUB2-2.04 is no longer able to boot i586 and i686 kernels.
That has nothing to do with EXT3 (Leap 15.2 on EXT3 boots as expected).
Nor is it due to Debian (openSUSE 11.1 i586 doesn’t boot as well).
So the case is even more corner-ish than I thought and it might well be intended behaviour, something like deprecation of 32 bit architectures, but I didn’t find anything related in the changelog.
Would be interesting to see what TW-i586 does in a similar setting.
The problem is reproducible in VBox, e.g. by installing Leap 15.2 multibooting with another 32 bit install: trying to boot the 32 bit kernel leads to a “Guru meditation” of the VM.
I think that a bug report will just get a “WONTFIX” for a 64-bit only distro.
Hmm. I just installed TW-586 on Saturday. It’s on the same external drive as TW-x86_64. And I’m using TW-x86_64 to boot it.
I normally plug it into a KVM virtual machine for booting (I have not yet tried on real hardware). It boots with legacy boot. It boots with EFI-32bit boot (ia32). And it even boots with 64-bit EFI booting, but in that case it complains about the architecture mismatch and “efibootmgr” does not recognize that it is in an EFI environment.
I suppose I should try using the 32-bit system to boot the 64-bit system. I expect that to work for legacy and 32-bit efi.
Maybe I should try with 15.2 and tw-586 on one KVM virtual machine.
I tried this the easy way. I booted a KVM virtual machine running Leap 15.2 with legacy boot. I then plugged in my external drive, and rebuilt the grub2 boot menu. Then, rebooting, I selected the menu entry to boot Tumbleweed on “/dev/sdb6”. And that booted tw-586.
Maybe it is only Ubuntu 586 systems or older 586 systems that cannot be booted.
In any case, I agree that it probably isn’t worth filing a bug report in this case.
I installed Leap 15.2 and Slackware 12.1 side by side in a KVM virtual machine.
Leap 15.2 could not boot Slackware 12.1. Note that slackware 12.1 is very old. It uses “ext3” (maybe “ext4” did not yet exist back then). And it takes its hard drive to be “/dev/hda”. I installed on the first partition. When grub 2.04 tried to boot it, the command line (as I recall) was:
linux /boot/vmlinuz root=/dev/sda1
I edited that (the ‘e’ key in grub) changing the last part to “root=/dev/hda1”.
It did not boot. Instead, it reset the VM, with no messages about why.
Plugging in a USB drive with Leap 15.1, the grub there was able to boot slackware (with the same change of “sda1” to “hda1”. So grub-2.04 cannot boot it, but grub-2.02 can. I should add that Slackware 12.1 uses “lilo”, and chainloading from 2.04 does work.
I next downloaded the iso for openSUSE 13.2 (586), and installed that to replace Slackware. And grub-2.04 had no difficulty with booting that.
Wireless at the moment and not always with the best speed/quality during these lockdown days, so a network problem might be a factor… going to retry with a better connection if possible.
BTW, same boot problem with (old) Fedora14 on EXT4, kernel 2.6.35. So filesystem is not relevant, kernel 2.6.x the main suspect?
I have also a few 2.4 kernels in my wastebin, but I’m not going that far
So I installed openSUSE 11.4 (586) alongside 15.2.
That uses a 2.6.37 kernel. And it seems to be the most recent version of openSUSE with a 2.x kernel.
It doesn’t boot with grub 2.04. I can boot by chainloading, but not directly using the boot menu entry for 11.4.
And then I decided to try openSUSE 11.4 (x86_64). And that does not boot either. So it seems to be a problem with older kernels, regardless of whether 32-bit or 64-bit.
Thanks Neil, I can confirm that and I found that systems up to openSUSE 12.2 with 3.4.6 x86_64 kernel do not boot.
So apparently something changed between 3.4.6 (does not boot) and 3.16.6 (13.2 boots normally).
