Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

bcarraghan · 2018-05-26 02:18:04

According to this topic:
https://bbs.archlinux.org/viewtopic.php?id=237397

The incorrect way to approach this error was to remove the files "/usr/lib32/libwayland-egl.so", etc.

I've already removed these files and installed the update. Everything is working correctly, but according to that thread that is technically a --force and it is the wrong thing to do.

Is there anyway I can fix/reverse that change?

Or will this be automatically fixed when the package gets fixed in an update?

Update:
I just realized that this update was giving me extremely low fps in steam games. So I removed steam and lib32-nvidia-utils (which also removes lib32-mesa + lib32-wayland). Then when im trying to reinstall im getting the error:
/usr/lib32/libwayland-egl.so exists in both 'lib32-wayland' and 'lib32-mesa'

So I'm assuming if I wait until that package is fixed I should be all right.

Another update:
I followed the guide to downgrading packages here: https://wiki.archlinux.org/index.php/do … g_packages
sudo pacman -U /var/cache/pacman/pkg/lib32-wayland-1.14.0-1-x86_64.pkg.tar.xz
sudo pacman -U /var/cache/pacman/pkg/lib32-mesa-18.0.3-1-x86_64.pkg.tar.xz

And I reinstalled steam and all seems to be good. Running sudo pacman -Syu will showcase these two packages:
Packages (2) lib32-mesa-18.0.4-1 lib32-wayland-1.15.0-1

I will wait until they are fixed to update them.

I updated this incase someone else came across the same issue and tried to resolve it in the same way that I did. If there is something behind the scenes that potentially needs to be fixed feel free to let me know. I always look into trying to fix things the correct way.

Last edited by bcarraghan (2018-05-26 04:02:02)

Lone_Wolf · 2018-05-26 14:08:56

Once you have the updated versions, run pacman -Qkk | grep error to check for problems.

( the "| grep error" is the simplest way i know to suppress the "foo: xyz total files, 0 altered files" lines ).

Trilby · 2018-05-26 16:09:21

That "| grep error" is really a no-op. You could grep for any unlikely string, or just the stdout to /dev/null as the warnings and errors are sent to stderr (which bypasses grep anyways). You might just want to use -Qkkq instead.

Last edited by Trilby (2018-05-26 16:09:58)

bcarraghan · 2018-05-27 02:27:10

Updated to the newest mesa package.
Errors seem to be ok. This is the output:

warning: filesystem: /etc/arch-release (Modification time mismatch)
warning: grub: /boot/grub/grub.cfg (Permissions mismatch)
warning: intel-ucode: /boot/intel-ucode.img (Permissions mismatch)
warning: intel-ucode: /boot/intel-ucode.img (Modification time mismatch)
libgpg-error: 92 total files, 0 altered files
warning: linux: /boot/vmlinuz-linux (Permissions mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.alias (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.alias (Size mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.alias.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.alias.bin (Size mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.builtin.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.dep (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.dep (Size mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.dep.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.dep.bin (Size mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.devname (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.softdep (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.symbols (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.symbols (Size mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.symbols.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/4.16.11-1-ARCH/modules.symbols.bin (Size mismatch)
warning: xorg-fonts-encodings: /usr/share/fonts/encodings/encodings.dir (No such file or directory)
warning: xorg-fonts-encodings: /usr/share/fonts/encodings/large/encodings.dir (No such file or directory)

I'm assuming these warnings can be ignored.

Last edited by bcarraghan (2018-05-27 02:29:17)

Lone_Wolf · 2018-05-27 12:57:00

warning: xorg-fonts-encodings: /usr/share/fonts/encodings/encodings.dir (No such file or directory)
warning: xorg-fonts-encodings: /usr/share/fonts/encodings/large/encodings.dir (No such file or directory)

Those 2 should be present, re-install xorg-fonts-encodings .

warning: grub: /boot/grub/grub.cfg (Permissions mismatch)
warning: intel-ucode: /boot/intel-ucode.img (Permissions mismatch)
warning: intel-ucode: /boot/intel-ucode.img (Modification time mismatch)
warning: linux: /boot/vmlinuz-linux (Permissions mismatch)

IF /boot is on a filesystem that supports linux permissions, this would be a problem.
Incase /boot is on fat32 like on most EFI-systems, this is normal.

Trilby wrote:

That "| grep error" is really a no-op.

That was my intention.
pacman -Qkkq lacks the info which problem the files have.
re-routing std output to /dev/null does give the same info as "| grep something-unusual" and feels cleaner.

pacman -Qkk 1>/dev/null

Is my new standard solution for this usecase.
Thanks for the hint.

bcarraghan · 2018-05-28 05:24:52

I was able to solve the xorg-fonts-encodings warning with reinstalling the package like you said.

I am using EFI with /boot on fat32. So I'm assuming those errors would be normal for that partition type?

sudo file -s /dev/sd*
/dev/sda:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 976773167 sectors, extended partition table (last)
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 1126400 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1104, reserved 0x1, serial number 0x14e1b884, unlabeled
/dev/sda2: Linux rev 1.0 ext4 filesystem data, UUID=c5f6b14c-72b1-4e5f-bfc0-dda6ec30d2f0 (needs journal recovery) (extents) (64bit) (large files) (huge files)

Thanks

Last edited by bcarraghan (2018-05-28 05:26:04)

Lone_Wolf · 2018-05-28 10:36:16

I am using EFI with /boot on fat32. So I'm assuming those errors would be normal for that partition type?

yes, fat32 is unable to handle linux permissions so a permission mismatch on fat32 is expected behaviour.

bcarraghan · 2018-05-28 18:06:15

Awesome, good to know. Thanks for the help.

Arch Linux

#1 2018-05-26 02:18:04

Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#2 2018-05-26 14:08:56

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#3 2018-05-26 16:09:21

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#4 2018-05-27 02:27:10

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#5 2018-05-27 12:57:00

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#6 2018-05-28 05:24:52

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#7 2018-05-28 10:36:16

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

#8 2018-05-28 18:06:15

Re: Undoing forced upgrade for 'lib32-wayland' and 'lib32-mesa'

Board footer