Upgrade Rocky 8 OS-Prober Package

Rocky Linux General
1

Hi nazunalika, jlehtone:

The subject recommendation is based on my recent experience with the
Rocky 8 package (version 1.74-9) which is invoked when updating the
grub2 bootloader chain list on a multi-partition PC with the command
grub2-mkconfig -o /boot/grub2/grub.cfg

A post on the Fedora forum describes the situation I was having with
Rocky 8 on my Compaq Presario machine:

This post seemed to be the latest one describing the problem, which was
occurring on Fedora 30, also using os-prober-1.74.

I determined that Fedora 31 was the original Fedora distro using
os-prober-1.77, so I downloaded the netinst .iso, and replaced my
Rocky 8 installation on the Compaq Presario test machine with it.

It should be noted that while os-prober is normally invoked by the
grub2-mkconfig command, it can be run separately (and tested)
from the command line, in /usr/bin, sudo os-prober.

os-prober worked fine on Fedora 31, with no error messages and no
omitted distros from the chainlist.

Because Rocky 9 does use os-prober-1.77-10, I am hopeful that
this version can be retrofitted to Rocky 8.

For your consideration …

Len E.

2

Hi,

os-prober won’t be upgraded unless RHEL do it. Rocky is 1:1 with RHEL. Rocky will not diverge from RHEL package versions.

I’m having problems trying to understand what your problem is with os-prober? Maybe you need to be opening a bug report? But we can only ascertain that when we know exactly what your problem is.

3

The way around the os-prober problem is to temporarily mount the /boot partitions of the other os’s under /mnt and then run grub2-mkconfig. I found that always worked for me.
RH recently dropped bugzilla for their products in favor of their in house bug tracking system “Jira”. Fedora bugs are still tracked on bugzilla.

4

Regardless of what RH uses for bugs, the “CentOS Stream 8” and “RHEL 8” bugs have to be reported to RH.

5

Hi nazunalika, jlehtone, iwalker:

I hope to describe the problem more clearly by explaining the context
for using Rocky 8 when requiring os-prober to work properly.

(A relevant detail: Debian/Ubuntu documentation states that the grub-update
command is a stub for the grub2-mkconfig -o /boot/grub2.grub.cfg command;
i.e. they are exactly the same thing).

When several distros are installed in separate partitions on a system disk, only one
of them can have the boot loader linked directly to the MBR. It is essential, to
avoid serious problems, that the distro linked to the MBR is utterly reliable, and
can function as a boot control for all distros on the disk. When a new test distro,
potentially buggy, is installed in a partition, its installation is immediately followed
by rebooting to the MBR-linked distro and running the grub2-mkconfig command
to update the chain list to include the new distro. In this manner, if the new test
distro behaves badly, it can readily be replaced without affecting to overall
integrity of the rest of the distros on the disk.

To rebuild the chain list, the grub2-mkconfig command invokes the os-prober
package to temporarily (using grub-mount) mount each partition to ascertain
the grub-related details of the distro to enable grub2-mkconfig to generate
a complete grub configuration file. If there are errors or omissions by os-prober,
linkages to some distros are lost. This problem was described in the Fedora
forum post referred to earlier, and is what I experienced with Rocky 8.

For years, the most popular choice for MBR-linked distros on multi-partition
test system has been a Debian or Ubuntu LTS distro. The sudo update-grub
command is simple to invoke, and the LTS os-prober packages have been
bug-free.

If you have Rocky 8 installed on a system, as a test, from the command line,
simply enter sudo os-prober. If there happens to be Windows n, or any other
distro on the system, you may well have an immediate example of the problem
being described herein.

****************************************************************
When I was searching the web for other reports of the problem, the Fedora forum
references were the only ones I found.

I don’t know how to access RHEL bug reports, so I would appreciate your advice
on how to do it, in order to check for any reports on this problem.

Thanks !

Len E.

6

If you are looking for historical data here is bugzilla:
RH Bugzilla

I’m a Fedora user for the last 17 years and am familiar with the legacy boot issues you describe. There are other issues with legacy boot besides multi-booting. One of the biggest issues is that the space allotted in the mbr for the install image is a fixed size and it is smaller than the images produced by current RH OS’s. Before I switched all my legacy boot systems over to UEFI grub2-install was failing with not enough space messages. I had to force the install, it worked but for how much in the future is a concern. This occurred on Rocky 8 and Fedora. The other issue is that RH has made it clear they do not want to maintain the grub code anymore. They prefer to support only UEFI boot and the simplicity of systemd boot. This was all covered in the Fedora forums. The biggest annoyance with grub for me is that for the other distros you are booting it does not include any extra kernel parameters that you may need to boot the other system with required functionality. Since I’ve moved to UEFI I use the firmware menu to boot the other distros because doing so loads that distros grub menu which includes the kernel parameters.

7

Hi jlehtone:

Through sheer timidity, I’ve avoided the mbr space problem you describe
with distros using grub2.

When I was initially moving to Linux, I avoided disturbing my system’s
Windows distro and it’s direct link to the MBR for fear of messing up/losing
my accumulated data. Instead, I installed a separate 1GB boot partition for
the boot control distro. As Debian/Ubuntu installers typically have a PBR
option for grub installation, the distro was easy to install. This approach
required an external boot loader on CD, plop or super-grub, for initial access
to the 1GB partition, but from that point onward, everything proceeds as I’ve
previously described.

To utilize this setup with Rocky 8, I defined a separate boot partition for it,
and utilized the installation method described in the CentOS forum post,
https://forums.centos.org/viewtopic.php?t=47241

Given my antiquated PC equipment, I’ll never be moving to Rocky 9, and
I’ll continue with Rocky 8 as long as it’s feasible.

Thank you for the RH Bugzilla link !

Len E.

8

The reason for Windows to remain “undetectable” on legacy was trivial:
Windows is on NTFS volume and EL/Rocky does not support that filesystem by default.
Therefore, os-prober cannot mount the volume nor see the “OS” there.
If one does install NTFS-support (from EPEL), then NTFS is mountable and the
Windows entry can be generated.

That could explain other OS too, if they use unsupported filesystems
(e.g. something on the bleeding edge).

EFI should not have that issue as bootloaders are within ESP volume(s) – a more ubiquitously supported FAT.

9

Hi jlehtone: an FYI

My test Rocky 8 distros have the EPEL package, ntfs-3g installed, and all linux-related
partitions except for the swap are ext4 file systems.

Len E.

10

Hi all:

I’m surmising that the Koji expert, Hedayat Vatankhah, who has maintained the os-prober
package for some years, could create a version 1.77 for el8 in short order without much
difficulty.

Len E.

11

Anyone on my team could update the version. Just because someone else can doesn’t mean we couldn’t and it also doesn’t mean we should. Doing so would mean we are no longer 1:1 with RHEL. The version will not change in 8 unless it changes upstream in RHEL.

You can easily take a source RPM of the version you have, build it in mock for Rocky 8, and install it on your own system. After that, you’re on your own in terms of supporting your own system.

1 Like
12

Hi naunalika: Two questions regarding this proposed change:

i) Is there a mechanism in place whereby the Rocky executive can request such a
change be implemented in RHEL 8.9 (which of course would benefit CentOS 8.9
Stream users also) ?

ii) From the Rocky Release Engineering perspective, does this proposed change have merit ??

Please advise.

Len E.

13

Go to issues.redhat.com and file your request. You can ask them to either A) fix the bug, B) provide a workaround, or C) rebase. Note: Due to 8.9 coming in November and maintenance only support starting in 8.10 in May of 2024, it is unlikely to make it.

We support and maintain UEFI with secure boot as one of the primary functions for Rocky Linux. It’s safe to say that my whole team is not using legacy boot for our own systems and infrastrcture, nor are we dual booting. The expectation is that systems are single-use, though we are aware of cases of users who dual boot. So then the question now is, what “merit”? For legacy boot users? For dual boot users who are not on UEFI? This is starting to sound more and more like a niche case. This is why I suggested you build the updated package yourself via mock and use it, with the stipulation that you are on the hook for supporting your system.

My opinion only and does not reflect the view of my team: I really don’t see a point of upgrading this package just for an edge case: legacy users and dual boot with Windows. Legacy systems are on the way out, whether we like it or not. Most, if not all systems should be using UEFI. Even our cloud images utilize UEFI for cloud providers that have it (which should be the major ones). It is very, very likely that Red Hat will have a similar view on this. They may see upgrading the version as unneeded and not greatly benefiting the wider users of RHEL 8/CentOS Stream 8.

2 Likes
14

Hi nazunalika: Thank you for the clarification !

Len E.

15

I’ve followed up on two of the possibilities suggested by Nazunalika:

i) Jira Upgrade Request filed

I accessed https://issues.redhat.com, and registered on the system dashboard.

With help from the RHEL staff, especially Raju Anumala, my request,
RITM1595635 (OS-Prober Jira Request) was created.
Unfortunately, my basic login on the system dashboard is not sufficient to
access the request details to view its status.

ii) Mock rebuild of os-prober

I was fortunate to find an easy-to-follow procedural document at
https://blog.packagecloud.io entitled
“Building RPM packages with mock”.

Using the configuration file, rocky+epel-8-x86_64.cfg,
I rebuilt os-prober-1.77-3.el8.x86_64.rpm from the fc31 source rpm,
os-prober-1.77-9.el8.x86_64.rpm from the fc36 source rpm, and
os-prober-1.77-10.el8.x86_64.rpm from the Rocky 9 source rpm.

In all 3 cases, the resultant rpm’s installed fine, but did nothing.
Invoking them with sudo os-prober produced no screen output.
Running grub2-mkconfig -o /boot/grub2/grub.cfg with each of
them installed in turn did not show any distros other than Rocky itself
in the grub.cfg file.

If there are any errors or omissions in the mock rebuild procedure I used,
I would appreciate hearing about it.

Thanks !
Len E.

16

A peculiarity I’ve noticed with all of the attempts to perform a successful mock
rebuild of os-prober is the appearance, at the start of the rebuild, of a warning
message:

no match found for the following plugin patterns: local, spacewalk, versionlock

On the assumption/hope that the message explains the failed rebuilds,
I checked for the dnf-plugins installed, yum list dnf-plugin*
The core plugin was the only one installed.

(As far as I can determine, python3-dnf-plugin-versionlock.noarch
is the same as dnf-plugin-versionlock.noarch, and
python3-dnf-plugin-spacewalk.noarch
is the same as dnf-plugin-spacewalk.noarch )

I installed the two python3 modules, but they made no difference.
The warning message is still the same at the start of the rebuild,
and the result is the same: the installed package does nothing.

Any insights as to what is going on would be most welcome.

Len E.

17

A RITM is for ServiceNow and is unrelated to Jira. There is nothing in Jira that is related to your request and such issues filed in Jira are generally not private.

This does not affect the build in any shape or form and is only related to dnf and its plugins.

18

Hi Nazunalika:

Thanks for the update !

One other variation in my mock rebuild testing iterations was to use a different

configuration file, rocky-8-x86_64.cfg, but it made no difference.

At all times, I checked the /etc/default/grub file to make sure that the

statement, GRUB_DISABLE_OS_PROBER=false was there.

Regards,

Len E.

19

A disappointing but not unexpected result today:

I downloaded and installed the newly-available

AlmaLinux-8.9-beta-1-x86_64-minimal.iso

The os-prober package is unchanged at version 1.74-9, which means

it won’t be changed in RHEL 8.9 when it’s released either.

Len E.

20

An interesting experiment today:

I thought that possibly if I upgraded Rocky-8 with a Fedora kernel for

the release from which I’m rebuilding the os-prober package, then os-prober

might work properly. Or possibly, because the Fedora os-prober x86_64.rpm’s

also install directly with no errors, if the rebuilt package doesn’t work, perhaps

the x86_64 Fedora package will.

I chose the Fedora 31 updated kernel, because, although fc31 is the earliest use

of os-prober-v.177, the grub2 package is the closest (v.2.02-110) to the

Rocky-8 grub2 package, v 2.02-148.

The 12 Fedora 31 kernel rpm’s were assembled in a Fedora31Kernel sub-directory:


kernel-5.8.18-100.fc31.x86_64.rpm

kernel-core-5.8.18-100.fc31.x86_64.rpm

kernel-cross-headers-5.8.18-100.fc31.x86_64.rpm

kernel-devel-5.8.18-100.fc31.x86_64.rpm

kernel-headers-5.8.18-100.fc31.x86_64.rpm

kernel-modules-5.8.18-100.fc31.x86_64.rpm

kernel-modules-extra-5.8.18-100.fc31.x86_64.rpm

kernel-modules-internal-5.8.18-100.fc31.x86_64.rpm

kernel-rpm-macros-143-1.fc31.noarch.rpm

kernel-tools-5.8.18-200.fc31.x86_64.rpm

kernel-tools-libs-5.8.18-200.fc31.x86_64.rpm

kernel-tools-libs-devel-5.8.18-200.fc31.x86_64.rpm

Because AlmaLinux-8.9-beta-1-x86_64-minimal had just been installed on the

test machine with a separate boot partition in the manner described earlier, it was

used as the test platform.

-From the Fedora31Kernel sub-directory,

a sudo yum –nogpgcheck localinstall k*.rpm installed 67 packages in all plus

3 upgrades.

-Then, sudo yum install fuse3 installed 3 packages in all.

-Then, the /etc/default/grub file was edited to

add the GRUB_DISABLE_OS_PROBER=false line, and change the

GRUB_ENABLE_BLSCFG value from true to false

-Then, the os-prober-1.77-3.fc31.x86_64.rpm package was local installed,

upgrading the resident os-prober-1.74-9 package.

-Then, the sudo grub2-mkconfig -o /boot/grub2/grub.cfg command was entered,

which seemed to generate an abbreviated grub.cfg file.

-Then, reboot, which made the Fedora 31 kernel the default

Under the Fedora 31 kernel, the os-prober-1.77-3.fc31.x86_64 package

behaved as before, with nothing happening with a sudo os-prober comand.

Then I downgraded with a sudo yum downgrade os-prober command to the

original 1.74-9 version, and to my surprise when I entered the sudo os-prober

command again, all the other Linux distros, but not Windows XP were listed !!!

I repeated the command and again it listed all the Linux distros accurately.

I upgraded to the os-prober-1.77-3.el8.x86_64 mock-rebuilt package, but it did

nothing as before.

I downgraded again to the original 1.74-9 version, and the

sudo grub2-mkconfig -o /boot/grub2/grub.cfg command generated

a configuration file listing all distros except Windows XP.

I rebooted again, and this time from SuperGrub 2.04s1 accessed the

AlmaLinux boot partition directly which allowed access to any one of the

Linux distros on the disk.

I have no idea why os-prober-1.74-9 performs reliably under the Fedora 31 Kernel

and is so erratic under the el8 kernel.

I plan to investigate further when Rocky 8.9 is released.

Len E.