Two more workarounds, at least here on XFCE …
WIN + pamac-manager + Enter
WIN + add + Enter (matches Add/Remove Software)
1 Like
Reading as much as I could carefully before upgrading, and not wanted to be locked out of my system (which uses LUKS) I put cryptodisk and …CRYPTODISK=y into the grub config file. The update ran fine, and I don’t need to update-grub as that’s done by the update.
When rebooting, I still get the ‘Crypto disk not found’ error, but it continued booting. Do I need to reinstall grub? I notice that /boot/efi/EFI/boot/bootx64.efi has the same date that I first installed Manjaro.
regarding xsettingsd and hidpi and GTK: Thanks for this. Does it require configuration?
edit: No configuration needed. Install and reboot!
A small criticism and a suggestion for improvement.
With a friend who does not know so much about Linus, the update failed because he had a full hard disk.
Now nothing works and I do not have the time to fix the system. I will reinstall the system.
Why, manjaro does not recognize the available disk space and does not give an error message before the update that the disk space is too small? It shouldn’t even start downloading files unless there is at least 10GB of space.
Should implement sometime.
1 Like
You can activate the free space check in Pamac under the settings.
I think this is deactivated by default.
Thanks!
This did it for me:
i’m stuck after attempting to update via pamac which presented a message that rsgain-git conflicts with intel-tbb
my system is AMD, but tbb is required by easyeffects and i need both easyeffects and rsgain
This update was mostly smooth (thank you!), but the hdf5-openmpi package is messed up, and my code that uses HDF5 libraries won’t build any more.
The problem is that the hdf5-openmpi package includes an internal build directory in its setting, resulting in configuration errors for other software like this:
Imported target "VTK::hdf5" includes non-existent path
"/build/hdf5-openmpi/src/hdf5-1.14.0/src/H5FDsubfiling"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
Arch has released patches for hdf5, hdf5-openmpi, and related libraries. Please merge in those updates when you get a chance.
I had not changed anything in the settings. Whatever went wrong there, now it’s reinstalled. I also swapped the hard drives. now the larger one is the system drive. The system should deny the download in advance, so that it does not come to such problems.
The nvidia black flickering just fixed now, if you still waiting, you fine to update now.
Answers/Links in my first Posting.
1 Like
hey majik 
Did you refreshed your mirrors befor you updated?
sudo pacman-mirrors --fasttrack
Maybe create a timeshift snapshot and just try to force the update and when something goes wrong you can still rollback.
i wasn’t affected by that,i already installed it.
Thanks
No (emphasis mine):
well some say don’t put the cryptodisk to the preload-modules line: [LVM on LUKS] GRUB error - no such cryptodisk found. It is simple:
- if your system boots and you have to press a button, well it is a nag
- if you find out how to fix it, all power to you
You can try to do several things with the /etc/default/grub file and call update-grub after. Do a reboot. Always have a USB-Stick with Manjaro on it ready to fix if you break too much. Installing grub into UEFI/MBR I always see as last resort but might fix your problem to get the warning/error away.
To clarify the issue you have to provide more info. Do you use ext4 or btrfs. Did you use the automatic partitioning of Calamares or did some manual one on your own? When did you install your system? Ask other persons who had the issue and fixed it what surroundings they have. And participate at the official discussion of the problem @Arbitrary: Can't boot LUKS encrypted install after 2023-03-31 stable update - #7 by philm
hey @Kobold - i solved the problem by uninstalling rsgain-git > performing the upgrade > installing rsgain-git
I had no issues after install, but after I left the PC for a couple hours, coming back and logging back in, the second screen was black.
More importantly why was the decision made to use a New feature branch which is even more unstable than the BETA driver for the stable branch of Manjaro instead of the production version?
@philm
Completely untrue. Where did you come up with that?
The latest NVIDIA driver is always used which is normally the new feature branch. Arch does the same.
However, unlike Arch we have kept the 470 and 390 legacy branches in the repos for older graphics cards.
What beta driver? We never have provided a beta NVIDIA driver.
I had been using the 530.30.02 beta driver on my own before the 530.41.03 stable release on my RTX 3060 Mobile with no issues.
From what I understand in the grub docs, GRUB_PRELOAD_MODULES will simply insert insmod <module> for each one you list at the top of /boot/grub/grub.cfg when you run grub-mkconfig. From /etc/grub.d/00_header:
for i in ${GRUB_PRELOAD_MODULES} ; do
echo "insmod $i"
done
Cryptodisk is also loaded further down before it calls cryptomount.
GRUB_ENABLE_CRYPTODISK=y will add insmod cryptodisk and insmod luks where necessary in /boot/grub/grub.cfg, and embed the cryptodisk module into the grub binary in /boot/efi/EFI/Manjaro/grubx64.efi when you run grub-install.
If the /boot is encrypted, the grub efi binary needs this module embedded, otherwise it can’t unlock and read its config file. It will prompt for the drive password before showing the boot menu.
It seems like for people that get the grub error, they are seeing it after unlocking the volume, and it seems to stem from here in the grub source:
This makes me think the error is about not being able to find a disk that’s encrypted, not the cryptodisk module. This is the only place in the source I could find this error message.
I think the people who get the error should check their /etc/fstab and correlate the encrypted volume with what’s passed to cryptomount -u <uuid> in /boot/grub/grub.cfg.
I think what’s allowing these people to continue to boot is the fact that they’ve already unlocked the volume, and grub can still find the kernel, etc.
3 Likes
I’m glad I decided to read this post before updating as I needed to edit my grub config in order to boot with my encrypted boot disk. Still getting the “press any key” message though, but booting works fine.
Is it just me, or is this something that should never have made it into a “stable” update? I can only imagine how many people don’t read the announcement post before updating (I normally don’t) and how many folks got screwed by this update. Even after fixing the grub config, needing to press any key still doesn’t feel “stable”
Kind of defeats the purpose of running Manjaro… might as well be on Arch if updates need intervention like this. At the very least Manjaro should intervene and automatically fix the config if the user is booting from an encrypted drive.
Or you know… not move to an unreleased version of grub in the first place.