[SOLVED] broken pacman on a computer without cdrom

manouchk · 2017-06-17 00:56:36

Hi,

I've broken pacman on my system. It was already problematic but after trying to update firefox (in order to solve problem related to somtehing else, selenium), I got a broken firefox and then I broke pacman..

Here is what is in /var/log/pacman.log after upgrading firefox:

[2017-06-16 13:56] [PACMAN] Running 'pacman -S firefox'
[2017-06-16 13:57] [ALPM] transaction started
[2017-06-16 13:57] [ALPM] upgraded firefox (51.0.1-1 -> 54.0-1)
[2017-06-16 13:57] [ALPM] transaction completed
[2017-06-16 13:57] [ALPM] running 'gtk-update-icon-cache.hook'...
[2017-06-16 13:57] [ALPM] running 'systemd-update.hook'...
[2017-06-16 13:57] [ALPM] running 'update-desktop-database.hook'...
[2017-06-16 14:00] [PACMAN] Running 'pacman -Suy'
[2017-06-16 14:00] [PACMAN] synchronizing package lists
[2017-06-16 14:00] [PACMAN] starting full system upgrade
[2017-06-16 19:48] [PACMAN] Running 'pacman -Suy'
[2017-06-16 19:48] [PACMAN] synchronizing package lists
[2017-06-16 19:48] [PACMAN] starting full system upgrade
[2017-06-16 19:50] [PACMAN] Running 'pacman -S icu'
[2017-06-16 19:50] [ALPM] transaction started
[2017-06-16 19:50] [ALPM] upgraded icu (58.2-1 -> 59.1-1)
[2017-06-16 19:50] [ALPM] transaction completed
[2017-06-16 19:50] [ALPM] running 'systemd-update.hook'...
[2017-06-16 20:08] [PACMAN] Running 'pacman -Suy'
[2017-06-16 20:08] [PACMAN] synchronizing package lists
[2017-06-16 20:08] [PACMAN] starting full system upgrade
[2017-06-16 20:17] [PACMAN] Running 'pacman -Suy'
[2017-06-16 20:17] [PACMAN] synchronizing package lists
[2017-06-16 20:17] [PACMAN] starting full system upgrade
[2017-06-16 20:23] [PACMAN] Running 'pacman -U --force /var/cache/pacman/pkg/openssl-1.0.2.k-1-x86_64.pkg.tar.xz'
[2017-06-16 20:23] [ALPM] transaction started
[2017-06-16 20:23] [ALPM] downgraded openssl (1.1.0.f-1 -> 1.0.2.k-1)
[2017-06-16 20:23] [ALPM] transaction completed
[2017-06-16 20:23] [ALPM] running 'systemd-update.hook'...

At some point i did run:

sudo tar -xvpf /var/cache/pacman/pkg/icu-58.2-1-x86_64.pkg.tar.xz -C / --exclude .PKGINFO --exclude .INSTALL || exit 1

When I run pacman -Suy, I get:

pacman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

Then I modified a script known to help recover pacman cf https://bbs.archlinux.org/viewtopic.php?id=95007 that I actualized like this:

# more ./recover_pacman
#!/bin/bash
arch=x86_64
mirror=http://mirror.rit.edu/archlinux
# link to cache (or download) and extract: openssl,libarchive,libfetch,pacman
cd /tmp
openssl-1.1.0.f-1
libarchive-3.3.1-5
pacman-5.0.2-1
#removed libfetch-2.30-3
for pkg in openssl-1.1.0.f-1 libarchive-3.3.1-5 pacman-5.0.2-1; do
pkgname=${pkg}-${arch}.pkg.tar.xz
if [[ -e /var/cache/pacman/pkg/${pkgname} ]]; then
ln -sf /var/cache/pacman/pkg/${pkgname} .
else
wget ${mirror}/core/os/${arch}/${pkgname} || exit 1
fi
sudo tar -xvpf ${pkgname} -C / --exclude .PKGINFO --exclude .INSTALL || exit 1
done
# now reinstall using pacman to update the local pacman db
sudo pacman -Sf openssl libarchive libfetch pacman || exit 1
# now update your system
sudo pacman -Syu

The above pacamn -Sf does not work. I tried manually removing libfetch which does not exist anymore (aparently).

Now I get that:

# pacman -Sf openssl libarchive pacman
pacman: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
[root@localhost recover]# pacman -Suy
pacman: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Last edited by manouchk (2017-06-18 11:29:22)

mpan · 2017-06-17 15:13:09

Now do reinstall-system --force && tatoo-on-your-forehead 'I’ll never use --force again.'. pacman was warning you that you are breaking your system. You asked it to shut up, you’ve have achieved the goal.

The live distribution works from USB sticks too. From it (mountpoint is where you have mounted your Arch root filesystem):

# pacman -S --cachedir=mountpoint/var/cache/pacman/pkg --root=mountpoint pacman openssl

After that run Arch normally and -Syu from it. Next remove all files that were sprayed all over your system by the tar — you have to do that manually, file by file. Finally do:

# pacman -S icu

manouchk · 2017-06-18 11:28:15

Thank you. Seems solved. Using the live USB is much more practical than a CD. I just had to run mkinitcpio -p linux after upgrading because it failed to boot with warning /lib/modules/4.11/5-1-ARCH/modules.devname not found and then would not found /dev/sda2 which is the internal hard drive. I did it by chrooting my archlinux from the live USB.

eschwartz · 2017-06-18 21:18:06

mpan wrote:

From it (mountpoint is where you have mounted your Arch root filesystem):
# pacman -S --cachedir=mountpoint/var/cache/pacman/pkg --root=mountpoint pacman openssl
After that run Arch normally and -Syu from it.

Alternatively, the LiveUSB is perfectly capable of handling a full `-Syu` (rather than merely the `-S pacman openssl`) by itself...

mpan · 2017-06-18 22:12:19

Eschwartz:
Is it also capable of handling broken icu installation that left conflicting files in the mounted filesystem? Will it cope well with other things that may already be broken, but we don’t know about them yet?

I offer commands that fix things in small steps, because if anything fails, we know where we are. Also if the user wants to play Jedi again, it is known what to look at. Easier to grasp a small bite than a deluge of possibly broken or inaccessible logs.

eschwartz · 2017-06-18 22:22:41

If it weren't, it wouldn't have been able to handle pacman and openssl either. But instead you seem to be recommending that people run yet another partial update.

The standard recommendation in such cases is always to run a full -Syu from a LiveUSB to get the dependency tree back in order.
The only thing that was broken, was having the wrong versions of things (a *standard* partial update), which prevented the /usr/bin/pacman binary from loading. You could solve that by running a statically compiled pacman binary, which doesn't exist. Or by running pacman from a system that has a working binary.

Either way, the only point to anything here, was to do a full system upgrade and thereby fix the partial upgrade.

Anything that wasn't fixed by -Syu'ing from the LiveUSB wouldn't be fixed by -Syu'ing from the rebooted system with a reinstalled pacman/openssl. Which is only to be expected, since it is literally the same thing, except you suggested running a pacman -Syu in two distinct transactions. :blink:

(As for a broken icu installation with conflicting files, that is what --overwrite in pacman 5.1 will be for, and what `pacman -r /mnt/archlinux -Sy --force icu && pacman -r /mnt/archlinux -Su` would fix. Again, it is literally the same action no matter which pacman binary you use, with the obvious exception of needing to set the --root and --cachedir.)

Last edited by eschwartz (2017-06-18 23:33:41)

Arch Linux

#1 2017-06-17 00:56:36

[SOLVED] broken pacman on a computer without cdrom

#2 2017-06-17 15:13:09

Re: [SOLVED] broken pacman on a computer without cdrom

#3 2017-06-18 11:28:15

Re: [SOLVED] broken pacman on a computer without cdrom

#4 2017-06-18 21:18:06

Re: [SOLVED] broken pacman on a computer without cdrom

#5 2017-06-18 22:12:19

Re: [SOLVED] broken pacman on a computer without cdrom

#6 2017-06-18 22:22:41

Re: [SOLVED] broken pacman on a computer without cdrom

Board footer