2 non-bootable, non-chrootable OMV systems: Missed (lacking) pkg dependencies?

Have a nice day, everybody!

On 2 of my PC systems sporting an OpenMandriva partition, the most recent major system upgrade or the last update to bash lead to a non-bootable operating system.

Furthermore, on both PCs it was not even possible for local secondary/tertiary Linux-based operation systems to arch-chroot or (on another OMV partition) chroot into the defective OMV system.

Investing many hours, I was able to repair both partitions myself.

Long story short:

Trying arch-chroot/OMV’s chroot, both failed with an error message/info remark stating (a “symbol”/”bash symbol” in?) “rl_completion_rewrite_hook” cannot be found/is missing. Web search for “rl_completion_rewrite_hook“ guided me mostly to the “readline” software and bash.

On my arch-based OS, I downloaded the archive “readline-8.3.tar.gz” and the “libreadline8-8.3-1-omv2590.x86_64.rpm” package from pkgs.org. I extracted their contents and copied the following files manually to every place where very similar files already existed.

  1. libreadline.so
  2. libreadline.so.6
  3. libreadline.so.7
  4. libreadline.so.8
  5. libreadline.so.8.3
  6. libhistory.so
  7. libhistory.so.8
  8. libhistory.so.8.3
  9. chardefs.h
  10. history.h
  11. keymaps.h
  12. readline.h
  13. rlconf.h
  14. rlstdc.h
  15. rltypedefs.h
  16. tilde.h

For already existing older files of the exactly same name I decided to rename them by adding a “-_-“ string both in front of and at the very end of its original name.

I reckon only some of the above files and/or directory paths were/would have been necessary, don’t know.

After those manual file additions and replacements, both non-bootable & non-chrootable OMV partitions were working again almost like nothing had ever happened. The exception(s) were warning/info remarks on the upper end of Konsole decrying a lack of some “libncurses” package. So I used dnf to install everything “libncurses”-esque. Then the Konsole message/prompt had vanished.

.

So, my question to myself (and perhaps to OMV maintainers) is: Could it be OMV repos are lacking dependencies for/on/of bash or anything, namely readline-8.3 and/or libreadline8-8.3-1?

(Possibly that “libncurses” thing is also wanted/Wanted For, but I cannot tell an exact package name. And Konsole or dnf itself called attention to that being absent. Most importantly, this problem did not hinder booting.)

Maybe someone wants to dig into the issue.

Kind regards

Tachyonenstrahl

.

[EDIT/P.S.: (The screenshots show the second defective OMV partition’s file system. That second one is quite old. I used it for reproduction and research/troubleshooting. So do not get puzzled/in surprise by the old software on the screenshot. My current OMV was hit be this “rl_completion_rewrite_hook“ lack problem first, then I repeated/reproduced it on the unused old kinsman.)]

Moving to Development > QA even though it probably should be part of already reported issues with ROME UM, systemd, and sddm pertaining to packages being broken.

I’m also not sure why your screenshots are blurred out. If you have sensitive material we can come up with other ways to share that info. Otherwise, it’s an added step that wastes time (both yours and anyone else that may assist you with this).

Updating and loading repositories:
 OpenMandriva Cooker - Non-free - x86_64                                   100% |   2.7 KiB/s |   2.4 KiB |  00m01s
 OpenMandriva Cooker - Restricted - x86_64                                 100% |   2.7 KiB/s |   2.4 KiB |  00m01s
 OpenMandriva Cooker - Extra - x86_64                                      100% |   2.7 KiB/s |   2.4 KiB |  00m01s
 local-builds                                                              100% |   6.6 KiB/s |   1.5 KiB |  00m00s
 OpenMandriva Cooker - x86_64                                              100% |  10.5 KiB/s |   2.4 KiB |  00m00s
 brave                                                                     100% |   8.7 KiB/s |   2.0 KiB |  00m00s
Repositories loaded.
Installed packages
lib64readline-devel.x86_64     8.3-1        cooker-x86_64
lib64readline8.x86_64          8.3-1        cooker-x86_64

Available packages
lib64tclreadline.x86_64        2.4.1-1      cooker-x86_64
lib64tclreadline-devel.x86_64  2.4.1-1      cooker-x86_64
libreadline-devel.x86_64       8.3-1        cooker-x86_64
libreadline8.x86_64            8.3-1        cooker-x86_64
perl-Term-ReadLine-Gnu.x86_64  1.46-1       cooker-x86_64
perl-Term-ReadLine-Perl.noarch 1:1.30.300-4 cooker-x86_64-extra
php-readline.x86_64            3:8.4.14-1   cooker-x86_64
readline-doc.noarch            8.3-1        cooker-x86_64
tcl-tclreadline.x86_64         2.4.1-1      cooker-x86_64
tcl-tclreadline-cli.x86_64     2.4.1-1      cooker-x86_64

https://openmandriva.pkgs.org/cooker/openmandriva-main-release-x86_64/lib64readline8-8.3-1-omv2590.x86_64.rpm.html

https://openmandriva.pkgs.org/cooker/openmandriva-main-release-x86_64/lib64readline8-8.3-1-omv2590.x86_64.rpm.html

Just thought I would also include where you got the files from so it could possibly help others. Definitely don’t mix the arch versions with ours, though.

If you search through the Support forum among some of the latest posts about the update you will find how things broke and why. It was either sddm panicking from the rename, systemd not doing a clean update, or a combination of both. Especially if you tried to update sddm while in a graphical session and then held down the power button. It would have been nice to see if someone would have waited a few hours to see if the upgrade had completed successfully. I guess waiting like that would anger some people.

I put them into a spoiler. I thought it would make the pictures collapse (saving space and scroll time) for a viewer to expand them. For de-blurring/sharpening, you just have to click on them once.

.

I’m sorry for that misunderstanding.

.

What does UM mean, what is that? Update Management?

Is that the exactly same link twice?

I thought that, too, but hesitated to do it because I am not a veteran on this forum. Perhaps external links would have angered someone.

.

I did not.

I waited some days after ROME repo sync, read a number of forum posts, even threads about major upgrade problems, and asked in this forum whether a Plasma 5 –> Plasma 6 upgrade would be theoretical possible in the first place. The only reply was yours.

Un-Mentionable, due to its nature and when people want it to happen.

Yup. See you are much smarter than me :slight_smile:
Here we go:

https://openmandriva.pkgs.org/cooker/openmandriva-main-release-x86_64/lib64readline-devel-8.3-1-omv2590.x86_64.rpm.html

More info is better. You can’t please everyone, but you can help them be well informed.

That was a generalization. Not a you did that.

I just went through a Rock to ROME upgrade and it broke for me, too. It’s actually xlibre killing the xsession prior to upgrade. Since most people are going to use a method to update that requires an xsession, then it will fail and abort the entire update. Which means it will have to be sorted out in a terminal afterwards. This is the unfortunate byproduct of our distro being a volunteer association and not a distro funded by theft and authoritarianism. It also means we need more testing to happen. I get that people want things to just happen, but that isn’t going to occur without someone there to test it out.

Just my two cents, but I don’t think there should be 3 releases. We should have a stable and a dev, and if people want more frequent stable releases with newer packages, then there needs to be more user testing in Cooker. Thankfully, that is not up to me.

A question popped up in my mind some days after your last post: Does the sole existence of those lib*readline packages in OMV’s repo(s) also mean they are listed as dependencies for a bash update? It does not, does it?

So, basically, those lib*readline repo entries could lack a dependency connection “Required By” to the bash package(s), right?

Or the other way round, the ‘depends-on’ info “Requires” pointing to some readline package(s) could be missing in the bash repo entries. Am I correct on that?

There are sections called Provides and Requires at the pages in the links.

The former is the list of names you could use to provide as a dependency to another package, or as a means to install it, the latter explains what is required for the package at runtime. If what you are looking for is not listed under Requires, then it’s not required. We don’t bloat our packages with things that are not needed. Another distro putting something as a Requires (or their equivalent) to a package they built is not an indictment of our package not being built properly.

:backhand_index_pointing_up:

2 Likes

rugyada:

Yeah, I saw it shortly after writing that question. By the way, is that warning banner supposed to look …

… this way? Because at first I thought that is the full warning with an ending line beneath. Also, as you can see, there is no scroll bar … until …

… until I hover the mouse to the banner’s right edge.

.

.

Wait a sec, please let’s not jump to conclusions. I have definitely no interest in bloating packages by/or putting something as a requirement even though it is not required.

My reason for bringing that whole readline issue was & is asking:

Could some readline files perhaps be required but been missed/overlooked by the bash developers, bash packagers or the OMV team?

Where humans or machines/software/robots work, errors happen, that’s only natural.

I’m not here to throw stones at anyone.

The last time I tried it this worked for chrooting into any OMLx system:

How to use ‘Live’ OMLx iso to repair broken OMLx system

Like a lot of people I had used an older method for years going back to when I used Fedora (starting with FC3) but one day I discovered that no longer worked with OMLx systems. So I got those instructions from @bero.

It has been some months since I last tested this but I know of no reason why this would not still work.

1 Like

Thanks, @ben79, but I repaired both non-bootable, non-chrootable OMV systems before opening this thread, which is why I wrote in the opening post:

and

.

I just wanted to inform OMV team of my findings about readline, libncurses etc. packages.

Regardless of the scroll bar visible or not..