4

After a Fedora distro upgrade (27->28) with dnf, I tried to manually resolve conflicts between package versions (needed to keep older OS versions functional; effective OS version is selected at boot time in GRUB2 menu).

dnf security checks prevented the removal of conflicting packages and I used rpm -e xxx --force to do that. I inadvertently removed glibc and the PC immediately errored out.

I want to avoid rebuilding my computer from scratch because:

  1. I don't exactly remember all applications I installed years ago (they were automatically upgraded by dnf system-upgrade), and
  2. there would be a huge configuration work in /etc to restore custom settings for my network environment plus the servers on the machine.

Using a rescue disk, I could boot and examine the hard disk. Everything seems relatively "clean". Files from glibc package are simply missing.

I could not complete chroot to the former root (in order to run rpm -i glibc) because chroot tries to launch /bin/bash which is missing.

Is there a way to tell rpm to do its usual job but to install files in, say, /mnt/hard_disk/ instead of /?

I'll take care afterwards of package database consistency and integrity.

Improve this question
0

2 Answers 2

Reset to default
6

chroot can take a command to run to this might work:

chroot /mnt/hard_disk rpm -i glibc*.rpm

Also, rpm has the --root option so this is another option:

rpm -i --root /mnt/hard_disk glibc*.rpm
Improve this answer
2
  • chroot … rpm … doesn't work because bash is needed to launch command and it was erased. I tried /bin/rpm (where I found rpm) or bin/rpm to no avail. rpm -i --root … is the right solution. PC can reboot now.
    – ajlittoz
    May 12, 2018 at 11:41
  • Everything back to normal. Conflicts resolved. Apparently they were cause by package(s) missing in the new repo (not updated yet?) causing dnf system upgrade to fail, leaving configuration in a mixed state.
    – ajlittoz
    May 12, 2018 at 13:12
3

There is a way to do this, though it doesn't use the rpm command. You'll need to have the rpm2cpio binary available, and then you simply do:

# cd /mnt/hard_disk
# rpm2cpio <rpmfile> | cpio -idmv

As you mentioned, you'll need to deal with RPMDB integrity issues afterwards, but that will get the files into place for you. There are numerous web pages with information and more details about this available through a simple google search, one of them is https://blog.packagecloud.io/eng/2015/10/13/inspect-extract-contents-rpm-packages/.

Improve this answer
5
  • Thanks @John, I'll have a try. A small difficulty: the rescue disk is a DVD-ROM and I can't add utilitities. In particular, I can't run rpm -i rpm2cpio on it. Since package rpm2cpio seems to spawn files in numerous locations, how do I solve that? Also the suggested command(s) do not run the pre- & post-scripts in the rpm.
    – ajlittoz
    May 11, 2018 at 20:41
  • Can't you? Most rescue environments I've seen are built on a ramdisk-based root filesystem.
    – telcoM
    May 11, 2018 at 20:57
  • The suggested rpm2cpio <rpm> | cpio -idmv will extract relative to the current directory, so if you are in /mnt/hard_disk when executing that, any files in the RPM that would normally extract to /lib will go to /mnt/hard_disk/lib instead. The aim is to restore the essential files of glibc and the dynamic loader first, as a quick fix. Once you can successfully run chroot /mnt/hard_disk bash, you will be able to use rpm --reinstall glibc-*.rpm to achieve a "proper" reinstallation - but to run rpm, glibc and the dynamic loader must be in place.
    – telcoM
    May 11, 2018 at 21:08
  • @ajlittoz if you don't have rpm2cpio, you can use script like this instead
    – Matija Nalis
    May 11, 2018 at 21:22
  • @Mark Wagner's solution is better since it uses rpm without tweak. Thanks anyway.
    – ajlittoz
    May 12, 2018 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .