my partner hadn’t updated since July 1, so she was about 4 updates (counting this one) back.
I ran sudo pacman -S install-grub pacman-static to kick things off before diving into sudo pacman-static -Syu for the full update with “toolchain safety”.
Ultimately things went well (including the new grub hook) but what we noticed was that the update download section started with saying it was downloading x of 686 updates… and then completed at having downloaded 591 of 591 updates, verified 591 packages, and installed 591 packages.
Where’d the other 95 packages go? Might it have been counting multiples of the same package (different version number)?
Ran sudo pacman -Syu to see if it would catch any more packages, but only received the warning to downgrade ksystemstats; taken care of via sudo pacman -Syuu
All in all everything went well, but odd that is miscounted 95 packages. I guess I’ll just blame pacman-static as it was the first and only time I’ve used it.
Note: It looks like the new ‘install-grub’ hook is also running a grub menu update… so with both hook 98 and 99 installed, the grub menu update happens twice which is redundant.
You’re not pedantic or dense. They don’t know what they’re talking about.
Of course you can’t use pacman if it doesn’t work nor should you. pacman-static is a compiled binary with included libs for that very reason – you can copy/download it however you want and run it (from wherever you want).
This update broke access to KDE Wallet of already authorized apps. I had to remove any authorized app from KDE Wallet so apps would try to reconnect. Without removing the apps from the authorized list, access to KDE Wallet would silently fail, requiring me to enter a bunch of passwords at login.
Indeed using pacman to install pacman when it is broken is a bit stupid Giving the direct link is right thou - you just have to unzip it, instead of installing.
If the worst happens one can always do it from the live usb…or just use the live usb pacman
But on this Stable update I’m again noticing my idle VRAM usage being higher compared to the previous Stable.
It went up from ~700Mb idle to ~990>1100Mb (fluctuates) on a fresh login with, auto started apps are FF, OpenRGB, CoreCTRL and Steam (set to sw rendering).
When checking amdgpu_top fdinfo list and adding up VRAM usage, nothing is out of the ordinary comraped to previous stable. But reported usage does not add up to the listed app usage ~840Mb. The discrepancy is about ~150Mb that is loaded but not listed.
Any idea how to check what it taking up the non listed 150Mb?
(edit typo’s)
12:30 a thing to add. After resuming the system from sleep, the reported VRAM usage did drop significantly to about ~780Mb. What would have expected on a fresh boot.
See my reply here earlier. This workaround should also fix your problem.
Most likely you’ll NOT be able to reboot successfully in the current state (you should be good tho if you additionally still use the default installed mkinitcpio). After applying the workaround, you can fix dracut by either reinstalling some kernel in manjaro hardware manager, or alternatively reinstalling dracut using pacman.I haven’t tested the latter.
I think you misunderstood that other comment too. Dracut is not deprecated. The dracut-hook package is (because dracut now has those hooks included), but that seems to be no problem for you since it would have caused a different error. There is no need to switch to any other package here.
When the updates are available, after install them I usually check kernels and switch to the last one, then remove previous.
This time I needed to remove linux-meta package and then was everything OK.
Today I noticed that in KDE Kate and KColorChooser there were no custom colors. I add some, for test, but after restarting KColorChoose, custom colors were gone ?!
I also have those pacnews. I backed up the original files and overwrote the settings with pacnews, and tested if my QEMU/KVM Windows guest still works. Turned out they worked as usual, so I then removed the backup files.
Conclusion: I think you can safely overwrite the config files with pacnews. Back up the original files if you worry that something may break in the future.
If I’m understanding you correctly then no action is needed, despite the dracut-install error shown in the middle of the update? Or is the best course of action to follow 7tvd’s advice and edit the /usr/bin/fsck.overlay file?
I also chose to use the .pacnew files. I launched my virtual machine and everything was okay.
I then shut the VM down and re-checked the files. All of them had been overridden automatically after I launched the VM. So I think in the end a user should be okay no matter what chose is made with keeping or discarding the .pacnew files.
I have two encrypted systems, on both of them I now have to enter the decryption passphrase twice, first just after power up and second a short while after the boot menu. It’s an easy problem to live with but before the updates the passphrase was required only the once after power up. Otherwise all seems well with the updates.
I assume this is a grub related issue, perhaps as mentioned in Known issues and solutions, but I am uncertain if I need to run install-grub or something else?
I had the same issue, probably because I moved (and renamed) /crypto_keyfile.bin on a fresh installation to /etc/cryptsetup-keys.d. Solution is to edit /etc/mkinitcpio.conf and /etc/default/grub just as described in the ArchWiki:
This might be ok in this case, but I would rather recommend to check the differences between the files in any case.
Even if the files were autogenerated, there might be new options, or deprecated options or some other important changes.
manjaro-pacnew-checker should be installed on your system anyway, I guess?
If not, you might want to install that package, which will check for .pacnew files after any update and use Meld to display the differences, so YOU can verify and choose wisely, which file to keep or which changes to merge from .pacnew to the original file.
There is a slight difference between making an informed decision and guessing it might be ok…
Giving the direct link is right thou - you just have to unzip it, instead of installing. 