I have run into a strange problem that I hope someone can explain.
I run several different operating systems on a single drive. I have been
using GRUB legacy as the boot manager to select what system to boot.
All of the bootable Linux partitions are formatted as EXT4.
The disk itself uses MBR partitioning, and the machine boots non-UEFI.
When doing installations of a new OS, I usually let the installation format
the partition where the OS will be installed. This has worked well up until now.
Yesterday I attempted to install Suse-Tumbleweed on a partition on this disk.
When the installation finished, GRUB was unable to load the kernel (Error 14).
I CAN Chain-Load the partition (which runs GRUB-2 on the Tumbleweed partition),
but this adds a lot of overhead to the boot (one of the many reasons I have stuck with
GRUB legacy).
It appears that the Tumbleweed installation formats an EXT4 partition a bit
differently than prior SUSE releases, and GRUB is unable to read the partition.
If I format the partition BEFORE the installation ((using GPARTED on one of the other Linux partitions)
and do NOT format the drive during installation, GRUB is able to load the kernel and
boot the system.
Can someone enlighten me as to what the Tumbleweed installation is doing
differently for an EXT4 format?
The Tumbleweed install disk is identified as 12/11/2017.
Although I haven’t yet seen what you describe, it’s still easily explained…
First, the file format you use (EXT4) should have nothing to do with the method your system uses to boot… either “legacy” MBR or “current” UEFI. How the disk is read and loaded is exclusive of the file format in the partitions on the disk. Perhaps what you’re seeing is that the MBR is unable to find the new EXT4 bootable partition? It’s hard to know for sure without knowing exactly how your disk now loads (see my comment below about UEFI supports both MB$ and GPT).
MBR is simple, but it’s 32-bit so is limited in the drive it can support, and where the boot partition can be located.
UEFI is 64-bit, and has no practical limitations because it maps your drives using GPT.
Because UEFI is much larger, there are also optional new features like “secure boot” which is supposed to address a number of theoretical (I think only within the last year a real attack was created) injection vulnerabilities during bootup.
UEFI should not be slower or “have more overhead”(whatever you may mean by that) compared to MBR.
Hardware supporting UEFI started appearing about 2008 or so, IIRC.
BTW - I haven’t seen it mentioned in these forums but some recent UEFI documentation I’ve read including the MAN pages says that UEFI supports both GPT and MBR… So, if your main bootloader is UEFI you should be able to point directly to OS on both GPT and MB$ disks/partitions without any problem without chain loading.
So,
With the above in mind it shouldn’t be particularly surprising that a leading edge distribution like TW might be pushing a UEFI based install today more than in the past, although I personally wouldn’t agree with that decision since TW is also our 32-bit distro so might be installed on older hardware that wouldn’t support UEFI.
I think you’ve already pretty much figured out your installation options for achieving what you want, so relatively little comment there.
First, the file format you use (EXT4) should have nothing to do with the method your system uses to boot… either “legacy” MBR or “current” UEFI. How the disk is read and loaded is exclusive of the file format in the partitions on the disk. Perhaps what you’re seeing is that the MBR is unable to find the new EXT4 bootable partition? It’s hard to know for sure without knowing exactly how your disk now loads (see my comment below about UEFI supports both MB$ and GPT).
MBR is simple, but it’s 32-bit so is limited in the drive it can support, and where the boot partition can be located.
UEFI is 64-bit, and has no practical limitations because it maps your drives using GPT.
Because UEFI is much larger, there are also optional new features like “secure boot” which is supposed to address a number of theoretical (I think only within the last year a real attack was created) injection vulnerabilities during bootup.
If this was a new partition being created, that MIGHT be a problem. However, the partitions on the disk are already created (using GPARTED) prior to installation of the
OSs. The ONLY thing different is whether or not I allow the installation to FORMAT the partition. Since the partition is (theoretically) in the same location on the disk regardless
of how it is formatted, I cannot see how this should make a difference, but it does…
To verify the problem, I made a TAR backup of the Tumbleweed partition, reformatted and restored the TAR file to the partition.
GRUB was happy after this… There is something new added with Tumbleweed’s EXT4 formatting.
UEFI should not be slower or “have more overhead”(whatever you may mean by that) compared to MBR.
Hardware supporting UEFI started appearing about 2008 or so, IIRC.
As per overhead, I was referring to chain loading the partition that uses GRUB-2 (not UEFI/ vs non-UEFI).
instead of direct load (KERNEL/INITRD statements).
Doesn’t the latest ext4 have some new features? Perhaps OP’s grub simply can’t handle the latest ext4 features. Use “tune2fs -l /dev/sda1” (that’s dash lower case L) to see what’s going on in the “Filesystem features:” field. Mine looks like,
Humm, My filesystem (the one that works) seems to be missing needs_recovery and 64bit
That COULD be what the issue is. I don’t see anything on the installation partition format menu that allows (or disallows) these options.
Are these EXT4 ‘features’ now mandatory in Tumbleweed?
It depends on how old are your other systems (or better what e2fsprogs version they have). E.g. e2fsprogs 1.43.1 enables 64 bit support by default. You can compare feature set of filesystems created by TW and other installations using tune2fs or debugfs.
ext4 is moving (albeit slowly) target. If you want to avoid incompatibility with unmaintained software, use ext2 for boot partition.
I continue to wonder if you ever try to understand the question before jumping to keyboard …
And, if I understand the above correct, that brings us to the question if that Grub you use is the one belonging to the same TW version. Because in that case, it should be compatible with the ext4 defaults of that TW. But if the Grub is from another distribution (and I understand you use several in multi-boot), that could be the problem.
That IS definitely the problem. The version of GRUB (legacy) is from SUSE 13.1. For a number of reasons, I have avoided moving to GRUB 2. I figured that as long as
I kept the partition formats the same, It would be OK. Based on the replies here it looks like that is NOT the case.
I would have thought that defaults for EXT4 formatting would not change, but then I keep forgetting about ‘progress’ :X
The mystery appears to be solved. Thanx to all who responded.
I guess I’ll be checking other file systems, I’d always assumed that whether a file system was 32-bit or 64-bit was determined by the hardware, and then the OS, and that a 64-bit version should exist for all commonly used fs, but that seems like a wrong assumption, or perhaps was unique only to EXT4. IMO EXT4 is late to the table since 64-bit computing and file systems were introduced as long ago as 2003 at least, and especially after Intel’s 64-bit CPUs in 2008.
I guess this is also interesting enough to verify that this preference/enforcement of the 64-bit flag isn’t applied when installing 32-bit TW.
I think that the @OP should submit a bug to https://bugzilla.opensuse.org as a possible bug.
I assume that there should already be code that disables 64-bit for certain scenarios, like older hardware and possibly a 32-bit TW DVD, and the scenario in this Forum thread probably got overlooked as a corner scenario.
When even a 64-bit install detects an existing older GRUB or GRUB2, the install should similarly disable the installation of incompatible file systems like 64-bit EXT4.
Anyway…
Submitting will at least pose the question, and then a decision would be made to do something or leave things as-is.