Can't boot after update, can't boot live USB either

So, like many others, the latest update was not kind to me. When I try to boot normally, I get a black screen, and my keyboard and mouse are unresponsive (not even lit up).

So I pull out my USB with a live install that I keep on hand and try to boot into that. Get the following:

mount: /run/miso/sfs/rootfs: wrong fs type, bad option, bad superblock on /dev/loop3, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
ERROR; Failed to mount ‘/dev/loop3’
Falling back to interactive prompt
You can try to fix the problem manually, log out when you are finished
sh: can’t access tty; job control turned off
[rootfs ~]#

What can I do about this? I can still boot into Windows so I could try to remake the live media, but this USB has worked fine before so it seems more likely to me this is a further side effect of the broken update. And while I’m here, what exactly can I do once I’m in the live media to repair the install? I backup my files but I have not been backing up the entire OS; clearly I’ll have to start doing that, but what are my options for repair/recovery from the live media?

I’m typing all this on my phone so if you need details about my hardware just look at one of my older posts, it hasn’t changed.

Thanks in advance.

How exactly could the update of your installed operating system have affected the live image on a USB stick that wasn’t even plugged in when you updated your system?

Your profile states that you are using Plasma — which is probably part of your problem right now, and that is why I’ve added the plasma tag — and when it comes to Plasma, there are certain steps that need to be taken into account before applying updates, and especially so when upgrading from one major version number (Plasma 5) to another (Plasma 6).

Some of these steps have been outlined on the pertinent Stable Updates thread — among which, the recommendation to log out of Plasma and to run the update/upgrade process from a tty — but it’s a little more involved than that, and several recommendations have been made here at the forum — both on the aforementioned announcement thread and elsewhere — to empty ~/.cache/ from a tty while completely logged out of Plasma, and preferably also before updating/upgrading your system.

Another potential pitfall would be if you happen to have any third-party widgets, applets or themes that are not (or no longer) compatible with Plasma 6. The responsible thing to do would have been to remove all of those before doing the update/upgrade, exactly because Plasma 6 is such a major overhaul under the hood — it’s entirely based upon qt6, whereas those widgets, applets and themes were developed for qt5.

Without further information, and pending the results of your efforts at cleaning out your ~/.cache/ — and possible deleting or renaming all of your ~/.config/plasma* files and your ~/.config/Trolltech.conf file — I’ll leave you with these two links for now… :point_down:

Download manjaro again

Download and install [ventoy] on your Windows system - prepare the USB using ventoy - drag and drop the manjaro ISO onto the usb.

That depends on what is causing your issue - there is no :magic_wand: you can use.

But since you are experiensing black screen one thing to ensure is that your gpu and kms is configured correct.

How that is configured is depending on your GPU or combination if it is a laptop with iGPU and dGPU.

There is a huge amount of topics on black screen - take apick

2 Likes
1 Like

Only because the media worked fine before the update, and did not work anymore afterward. I know correlation doesn’t equal causation but like, what happened then? Software rot?

So as suggested I downloaded the newest live iso and put it into the ventoy drive that I was already using, and it’s working now.

That’s great, thanks, but I don’t see how this answers my question of what I can do now, after having bungled the update, from the live media. The searching I’ve done suggests I can mount my main drive? But I can’t find any complete instructions anywhere, and piecing together half-instructions from multiple different sources sounds dangerous.

I feel like if I can just repair the install enough to boot directly into a tty (which to be clear I currently can’t do), then from the tty I could clear the cache like you said, and then try running pacman -Syyu and see if it can upgrade whatever packages couldn’t be upgraded because I was in the GUI. And if that didn’t work I’d try downgrading. Or if that’s a bad plan, please let me know what I should do instead. But first I need to know what I can do from the live install to even do anything.

Oh and don’t worry, I read your handy guide and I’ll be sure to stop using Manjaro once I get out of this! (I mean I do have backups of my important files but I would prefer to get back into Manjaro before switching.)

Currently sitting on a tty in the live media.

First, boot up from the live USB. Then open up a terminal and issue the following command… :point_down:

sudo su -

If your drive is encrypted, you must first open up the encrypted container. :point_down:

cryptsetup open name-of-the-container

Now, mount your root filesystem and chroot:point_down:

1. If your root filesystem is on ext4 :point_down:

manjaro-chroot -a

2. If your root filesystem is on btrfs (and assuming it is /dev/sda2, and that your EFI partition is /devsda1 — change these to what’s appropriate for your setup) :point_down:

mount -t btrfs -o subvol=@ /dev/sda2 /mnt
mount -t btrfs -o subvol=@home /dev/sda2 /mnt/home
mount -t btrfs -o subvol=@log /dev/sda2 /mnt/var/log
mount -t btrfs -o subvol=@cache /dev/sda2 /mnt/var/cache
mount -t vfat  /dev/sda1 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sysfs /mnt/sys
mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars
chroot /mnt /bin/bash

Now, empty the .cache of your regular user and back up your old Plasma configuration files — you can delete them later… :point_down:

rm -rf /home/your-user-name/.cache/*
cd /home/your-user-name/.config/
for i in plasma* ; do mv $i $i.bak ; done
mv Trolltech.conf Trolltech.conf.bak
cd -

Update your system… :point_down:

pacman-mirrors -f && pacman -Syu
grub-install && update-grub
1 Like

I got all the way to here just fine, but after it synced the mirrors, I got this error:

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

I found this post with a similar issue. like them, “pacman -Qm” and “pamac list -m” give the same error. I’m not about to try the suggested bandaid fix (temporary link) on a different library because I do not know enough. next post will contain my output of “ldd /usr/bin/pacman”

ldd /usr/bin/pacman
        linux-vdso.so.1 (0x0000739db53ae000)
        libalpm.so.14 => /usr/lib/libalpm.so.14 (0x0000739db5301000)
        libarchive.so.13 => /usr/lib/libarchive.so.13 (0x0000739db5232000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000739db5046000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x0000739db4a00000)
        libcurl.so.4 => /usr/lib/libcurl.so.4 (0x0000739db4f7f000)
        libgpgme.so.11 => /usr/lib/libgpgme.so.11 (0x0000739db4f2b000)
        libacl.so.1 => /usr/lib/libacl.so.1 (0x0000739db4f20000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x0000739db4eed000)
        libzstd.so.1 => /usr/lib/libzstd.so.1 (0x0000739db4921000)
        liblz4.so.1 => /usr/lib/liblz4.so.1 (0x0000739db48fc000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x0000739db4eda000)
        libz.so.1 => /usr/lib/libz.so.1 (0x0000739db48e3000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x0000739db4790000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000739db53b0000)
        libnghttp3.so.9 => /usr/lib/libnghttp3.so.9 (0x0000739db476d000)
        libnghttp2.so.14 => /usr/lib/libnghttp2.so.14 (0x0000739db4743000)
        libidn2.so.0 => /usr/lib/libidn2.so.0 (0x0000739db4721000)
        libssh2.so.1 => /usr/lib/libssh2.so.1 (0x0000739db46d8000)
        libpsl.so.5 => /usr/lib/libpsl.so.5 (0x0000739db46c4000)
        libssl.so.3 => /usr/lib/libssl.so.3 (0x0000739db45eb000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0000739db4597000)
        libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x0000739db4588000)
        libassuan.so.0 => /usr/lib/libassuan.so.0 (0x0000739db4573000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x0000739db454d000)
        libicuuc.so.75 => not found
        libm.so.6 => /usr/lib/libm.so.6 (0x0000739db4462000)
        libunistring.so.5 => /usr/lib/libunistring.so.5 (0x0000739db42b2000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0000739db41da000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0000739db41ac000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x0000739db4ecc000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0000739db419e000)
        libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x0000739db4197000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x0000739db4185000)
        libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x0000739db4162000)

Perform the update again and this time please provide the full command output (including the command itself) and not just the part you think might be relevant. This is something you should always do when command output is requested so that others can easily see other potentially contributing factors.

3 Likes

um. sure okay, here you go. hope it helps :slight_smile:

[manjaro kitt]# pacman -Syu
pacman: error while loading shared libraries: libicuuc.so.75: cannot open shared object file: No such file or directory

In this case it has.

You need elevated privileges when using pacman to perform an update:

sudo pacman -Syu

This is a fun (short for fundamental) fact you should already have been aware of. Try again with this astounding new knowledge.

Cheers.

1 Like

Oh thanks so much for your helpful tip, but if you were following along you may have noticed that I was already using elevated privileges when I ran the command. I’m glad you’re trying though.

You might need to use pacman-static

And yet, not in your last example.

Naturally, in the chroot environment you are already the root user, and as such you have elevated privileges. There didn’t seem enough time for you to reboot into a Live installer, enter a chroot environment and perform any actions; in the time between my post and your response; unless you were already there; or happen to be The Flash™. :slight_smile:

This seems related, and with a possible workaround:

1 Like

Alright this helped significantly. pacman-static gave me conflicting package errors for qt5-webkit and electron25, which based on what I’ve read was common and expected. I checked, nothing still depended on them, so I removed them and ran a full upgrade. I don’t have the full output of that because I then tried to boot back into my main OS install, which didn’t work. I then realized I’d spent so long on this step I’d forgotten there was a step after it, so I went back into the live media, and this is what happened next:

[manjaro /]# grub-install && update-grub
Installing for i386-pc platform.
grub-install: error: install device isn't specified.
[manjaro /]# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

my filesystem is ext4 by the way
I take it I shouldn’t have tried to do update-grub on its own? because now even grub won’t load. I can still boot windows or the live media from the uefi.

yep, I was already there, good solve

These are two commands, chained together.
The first one failed because it was incomplete:

The second one was successful - even though the word Error appears in the output.

I can’t tell you how to (re)install grub - there are wikis here and perhaps someone else knows and will tell you.

According to Arch wiki:

grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB

99% sure you replace esp with /boot/efi

https://wiki.archlinux.org/title/GRUB#UEFI_systems

Probably more like

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck

But the /boot/efi depends on the actual mount point.
/boot/efi is the old standard, but is now discouraged.
Mine is at /efi.

Though this can all be avoided by the handy script install-grub

sudo pacman -Syu install-grub
sudo install-grub

It should figure out all the things for you.
And it provides a hook to reinstall grub (update the installed bootloader) when needed.

Didn’t anyone notice this?

The install-grub script might be the better resolution here. One thing I’ll add is that after using this script, the machine might not boot as expected. This can happen especially if multibooting; it can be corrected by booting to BIOS and changing the default boot order. That is all. Cheers.

Whats to notice?
They didnt use proper syntax and it defaulted to i386 before failing because it wasnt pointed at anything.
(which are both remedied by the correct syntax and/or install-grub script in the subsequent replies)