Windows is difficult to repair mainly because of the registry, IMHO. Microsoft’s claims that it should never require cleanup doesn’t really make sense… it’s the most practical advice given how convoluted it is, but the fact that a database that keeps getting written to constantly doesn’t ever need any kind of maintenance just doesn’t make sense to me.
To be fair, average users would never (or should never) encounter such an issue. The person asking uses Arch (I think?) which is by far not an “average person” distribution.
I think the key would be figuring out where this extra UUID is coming from. Maybe next time you try this, make a note of all the UUIDs on your system (including the bootable USB) and see which one ends up in the bootloader config.
Knowing what’s happening can help guide your Googling to find out why it’s happening and how to fix it.
I presume these are filesystem UUIDs. I also presume from your other post, that you used a live USB to fix nvidia drivers? Note that nvidia driver installers/packages trigger a initrd rebuild, and if you do that in a live environment, it’s possible that you will get the UUID of your live USB filesystem and not your actual boot drive… at least that’s my guess.
If you booted into a live USB you need to make sure that you chroot into your install on your disk whenever doing any operations on the boot loader. That involves mounting your actual disk (eg, /dev/nvme0p1) somewhere on the live USB (eg, /mnt/example), then bind-mounting the proc, sys, dev, tempfs filesystems under /mnt/example/proc, /mnt/example/sys, etc. You may also need to mount /efi under /mnt/example/efi or boot/efi (wherever you have it in your system). Next, chroot to /mnt/example. You should now have a fully functional install you normally boot into, with the only difference being that the kernel booted off the USB drive. Now you can try reinstalling drivers, rebuilding initrd, reconfiguring the bootloader, etc. Since you’re chrooted, the system should see the proper UUIDs, in theory…
If you want a more comprehensive tutorial on how to do this, look for bootloader fixing tutorials.
Ok, just updated to 1.11.0 (latest app store release at the time of writing) and it behaves exactly the same. The icon changed after updating, however, subsequent attempts to change it are ineffective as before, even if the app is swiped up from the task selector to “kill” it. It seems like swiping up doesn’t really kill the app, however, installing/reinstalling/updating from the app store does.
To test this, I’ll try offloading the app (delete app but not app data) and reinstalling to see if my hypothesis about updating/reinstalling is correct.
Interesting; it’s consistently not working for me. I managed to change the app icon once, but subsequent attempts keep failing. The icon changes within the app’s settings screen, however, it does not change from the previous selection when I go into the app switcher or the launcher. Killing/restarting the app from the app switcher doesn’t help either.
EDIT: the symptoms above are happening on app store version 1.10.1. I’m about to update to 1.11.0 to see if it helps.
I’m guessing this is a school and not a university? At a university students have more clout/rights, at least on paper.
In any case, getting your own machine is the way to go. You can run whatever you want on it. You could still (cautiously) use the school network, as long as you use a VPN; basically treat the school network as a “hostile” environment. That’s assuming VPN use is not against the school rules. :)
Is there an IT policy at your school? I suggest perusing it for 2 reasons:
Understanding the consequences of tampering/tinkering with the spyware.
Understanding how much authority the IT department really has, and whether or not what they’re doing with the spyware constitutes overreach.
#2 in particular is for your own knowledge/benefit. Since you’re not an employee, but a student, you may have some inherent rights under this policy, which the IT department may be violating.