12510198
sudo sed -i 's/libalpm.so.14/libalpm.so.15/g' /usr/bin/paru
I figure that the administrators of your homeserver could see your IP address, I doubt that it would be sent to anyone you are just chatting with.
Ive only had to setup a nvidia system once, so I might be missing some packages, but I think pacman -Rns nvidia nvidia-utils lib32-nvidia-utils
should get rid of all of it.
WARNING: doing this will absolutely DESTROY YOUR SYSTEM, PERMANENTLY!!!
But if you wish to continue, you can erase all the EFI variables using the rm utility, I dont think you will be able to completely zero out the chip on the system from inside of Linux as its read-only.
But to delete all the EFI variables, cd into /sys/firmware/efi/efivars
, if this directory is not availiable, either the efivarfs is not mounted, or you are booted in legacy BIOS mode. But once you are in this directory, run chattr -i ./*
as root or sudo to remove the immutable bit on all the files, then run rm ./*
as root. This WILL break your system. Only do this if you know how to restore your system using like a chip programmer.
This happened to me too. I had to grab the box that comes up and resize it like I would with a normal window, mine glitched a lot when I tried it, try resizing it as far as you can, it will try and glitch back, but just keep fighting it until it becomes a usable size, then log out of Plasma and log back in, and then you can size it back down to a normal size. Hopefully there will be an official fix for this soon
What about something like this:
for i in /media/johann/5461-000B/DCIM/100MEDIA/*.AVI; do newpath="$HOME/Public/240321/$(basename "$i" | sed 's/^IMAG/240321_/g')"; ffmpeg -i "$i" -ss 00:00:00 -t 00:00:20 "$newpath" && rm "$i"; done
If its just /
owned by the mint user, you should just able to run chown root:root /
as root/sudo, dont use -R
. This should make root become the owner of /
. Now if all files and directories in the partition are owned by the mint user, this might be a bigger problem
Alright, could you see what the root variable is in the grub console before manually setting it by running echo $root
, and if it prints anything, could you run ls /
in the grub console and see if you see like home dev etc, or the directories you would expect to see in / inside linux, and if you do see anything, could you run ls /boot/grub/
and see if you see grub.cfg
. But if you are already inside linux, go ahead and install grub with --removable
, it wont overwrite your current installation. I dont want you to format the efi partition, incase something goes wrong and you wont be able to boot into linux at all
I think anything that can be done with a fresh format can be done with the current one, when you ran grub-install
after the issue with not running it as root, did you only do it with --removable
? If so, the old grub is might be getting picked over the new grub installed at the removable fallback path, because it has a proper entry in the boot order. I dont know what key it is on your system, but if you can get into the boot order menu where it shows all the different boot devices, like where you can pick where you want to boot from, id look for one that just says something like "UEFI boot " or something like along those lines, it wont say like grub or your distro name, if there is such an option available, could you try booting from that option?
Oh its no worries, it sounds like you just need to regenerate the grub config, you can do this by running
sudo grub-mkconfig -o /boot/grub/grub.cfg
or if your distro has it, you can just run
sudo update-grub
then grub should see the config on boot and put you in the normal graphical menu
Nheko is my favourite client, it uses QT and is written in C++, its lightweight and works well on my machines with low resources, it also respects my system theme