Upgrade Rocky 8 OS-Prober Package

[LenE]

An omission yesterday:

On AlmaLinux-8.9-beta-1-x86_64, I forgot to install ntfs-3g.

Accordingly, sudo yum install epel-release and

sudo yum install ntfs-3g installed it and its library.

The command sudo os-prober now detected and listed Windows XP

as well as the linux distros on the disk.

The command sudo grub2-mkconfig -o /boot/grub2/grub now included

Window XP in the boot list, and it was accessed with no problem from

the AlmaLinux boot partition entered from SuperGrub 2.04s1.

I work exclusively with Debian, Ubuntu, and CentOS derivatives, so I

don’t encounter the difficulties reported with boot loaders and other distros.

Len E.

[LenE]

Found a way to make os-prober-1.77-3 work on Rocky 8.

The dependencies for os-prober-1.77-3 and os-prober-1.74-9 are
the same except for 1 item: whereas the latter depends on
device-mapper, the former depends on grub2-tools-minimal.

This suggests that it is essential that os-prober-1.77-3 must have
the same grub2 version, 2.02-110 or 2.02-100, that it has on fc31.

I’ve belatedly realized that although grub2 has many x86_64 components,
there is only one .src rpm behind it all.

Accordingly, I downloaded the grub2-2.02-110.fc31.src.rpm and ran
mock -r rocky-8-x86_64 --rebuild grub2-2.02-110.fc31.src.rpm, which
created 21 x86_64 and noarch rpm’s.

Typically, Rocky-8 has only 11 of those packages installed, with the rest available.
Therefore, I consolidated the 11 replacement packages in a directory,
grub2v2.02-110:

grub2-common-2.02-110.el8.noarch.rpm
grub2-efi-ia32-2.02-110.el8.x86_64.rpm
grub2-efi-ia32-cdboot-2.02-110.el8.x86_64.rpm
grub2-efi-x64-2.02-110.el8.x86_64.rpm
grub2-efi-x64-cdboot-2.02-110.el8.x86_64.rpm
grub2-pc-2.02-110.el8.x86_64.noprpm
grub2-pc-modules-2.02-110.el8.noarch.missingrpm
grub2-tools-2.02-110.el8.x86_64.rpm
grub2-tools-efi-2.02-110.el8.x86_64.rpm
grub2-tools-extra-2.02-110.el8.x86_64.rpm
grub2-tools-minimal-2.02-110.el8.x86_64.rpm

---

The module listing illustrates a problem encountered with the grub2
mock rebuild: the results did not include the grub2-pc-modules package.
(A mock rebuild on the grub2-2.02-100.fc31.src.rpm was performed as
a check: it had the same problem).
To achieve a successful install, it was necessary to remove the current
grub2-pc-modules package, sudo yum remove grub2-pc-modules.
Fortunately, the only other package removed was grub2-pc.

In the directory grub2v2.02-110, sudo yum --nogpgcheck localinstall g*.rpm
installed the replacement grub2.

NB-- it is essential, that after a grub2 replacement, the file etc/default/grub
be examined to ensure that the following 2 lines are present:
GRUB_DISABLE_OS_PROBER=false
GRUB_ENABLE_BLSCFG=false

The mock-rebuilt os-prober-1.77-3 was installed, and sudo os-prober
detected all distros on the disk repetitively without fail.
The grub2-mkconfig -o /boot/grub2/grub.cfg command produced a
correct chain bootlist, but listed the other distros on the disk twice.
As has been documented historically, os-prober-1.77-3 runs slowly,
and the grub2-mkconfig command took about 15 minutes to complete.

---

When Rocky 8.9 is released, further investigation is desirable to determine
if a newer os-prober/grub2 pair can solve the current missing module and
speed problems.

Len E.

[LenE]

Hi Nazunalika:

Given that your knowledge of, and experience with, mock rebuilds is vastly
superior to mine, I’m hoping you can shed some light on the missing module
problem that I described on my previous update to this post.

I’ve run some additional tests in trying to diagnose the problem in the form
of mock rebuilds on additional os-prober/grub2 pairs:

-Fedora 33 release packages, os-prober-1.77-6.fc33.src.rpm
and grub2-2.04-31.fc33.src.rpm

-Fedora 34 release packages, os-prober-1.77-7.fc34.src.rpm
and grub2-2.06~rc1-3.fc34.src.rpm
(I tried a mock rebuild on the Fedora 34 update package,
grub2-2.06-9.fc34.src.rpm as well but the run aborted on a
package_version_compare undefined reference to ‘rpmvercpm’ error).

---

In the two completed rebuilds, the results were the same as reported previously:
the grub2-pc-modules noarch.rpm is missing.

The documentation provided by the Koji developers of the two grub2 packages
on the koji.fedoraproject.org website, and the presence of the missing
grub2-pc-modules on the archives.fedoraproject.org website clearly show that the
grub2-pc-modules were part of the corresponding grub2 src.rpm’s.

---

I’m guessing that the problem may relate to one of the many mock settings
described in /usr/share/doc/mock/site_defaults.cfg, but I don’t know which
one(s).

Hopefully submitted for your review and comment,
Len E.

[LenE]

I’ve stumbled onto a work-around for the OS-Prober and grub2-mkconfig problem
on Rocky 8.9 —> both commands work PROVIDED they are invoked from a
basic terminal/non-DE environment.

I was achieving success on Almalinux-8.9 minimal, installed into /boot, /root, and
swap partitions on my HP Compaq DC5800 test machine, to which I had not added
a desktop environment.

I booted up my various Rocky 8.n test installations by editing the grub boot menu
by adding a blank-3 to the end of the boot command line in order to bring up a
terminal-only session. In all cases, os-prober brought up all the partitions with
other distros without fail.

I had one Rocky 8.n installation, with a separate /boot partition installed on my
Compaq Presario test machine, which also was configured with the Fedora 29
kernel in effect. Both os-prober and grub2-mkconfig worked fine, with one
peculiarity: the distros in the other partitions on the disk were both listed twice
by os-prober, and appeared twice in the boot chain list created in the /boot
partition by grub2-mkconfig. This redundancy did not cause any problems.

---

The following comments have some political overtones, but contain some
valid/important technical information:

Some viewers would wonder why I’ve been so preoccupied, almost obsessed, with
the os-prober functionality on Rocky 8.n.

A major impetus has been provided by the direction taken in the latest Ubuntu
(22.04) and Ubuntu-derivative releases as illustrated in the following two
excerpts from Ubuntu 22.04 documentation:

[document]
We will now create four partitions for our Ubuntu 22.04 installation.
Partition details are shown below:
Ubuntu 22.04 requires an additional partition called a Reserved BIOS boot area with 1MB. So, create this partition at the before /boot or EFI partition.
UEFI System:
Reserved BIOS boot area – 1 MB
EFI – 1 GB
swap – 4 GB
/home – 400 GB
/ – Remaining (100 GB)
Legacy BIOS:
Reserved BIOS boot area – 1 MB
/boot – 1 GB
swap – 4 GB
/home – 400 GB
/ – Remaining (400 GB)

UEFI and BIOS boot
Other operating systems are not displayed in the boot menu anymore, unless Ubuntu has been installed alongside another operating system. Once all other operating systems are removed from the machine, detection of other operating systems is disabled, and to re-enable if after installing another OS, you will have to delete /boot/grub/grub.cfg and immediately run update-grub again.

[/document]

Ubuntu and Ubuntu-derivatives, for many years, as mentioned earlier, have been a
favourite choice as boot-control distros on multi-partition PC’s. These latest
“features” will clearly destroy such a capability for Legacy BIOS systems.
It certainly not clear why the Reserved BIOS boot area approach was required,
because other modern distros moving strongly to UEFI, as far as I know, haven’t
done that. It’s obvious that needing a partition dedicated to this 1 MB area is
critically wasteful for Legacy BIOS systems.

---

With Ubuntu 20.04 and derivatives the “end of the line” for boot-control purposes,
Rocky 8, and Almalinux 8, and Springdale 8, as distros continuing the
CentOS 8.5.2111 heritage of support of Legacy BIOS systems (Rocky until May 31, 2029), will fill an important gap caused by Ubuntu vacating that role with
release 22.04.

Len E.