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.
Hi, I’m using KDE environment on a laptop with 4k display, hybrid drivers (intel, nvidia) and 225% scaling and everything was working correctly before this update, but after the update the gtk applications (meld for example) are not scaled correctly. I cannot upload a picture here to show the problem but the close, minimize, maximize buttons are really small for example
1 Like
First of all @spacecase-25. None of our developers uses FDE at all. Hence we also DONT test this at all from our end. If the community want to encrypt their drives, simply go for it. You made that decision and you’re in the driver seat.
Regarding grub: Arch doesn’t maintain grub updates as it should be normally. You have to have some monolithic approach to have the binaries shipped by the grub package and the installation of grub in MBR or UEFI in-sync. Manjaro and all the other deviates are using Ubuntu’s update-grub script, which only updates the menu but not grub itself. As Arch already stated, it is really hard to know how you installed grub to begin with. You can read my indepth statement on this matter if you want.
Stable branch never means that you get fully tested packages and if you update you don’t have to worry that your system may break. Do a web search. Manjaro is not the only distro which may have that error. As soon as you encrypt your installation there must be some sort of understanding on how to get back to that data when some went wrong.
The Manjaro user community is on the problem and will provide a guideline on how to solve the issue if you have the issue. If your system boots, well fine. If you want to get rid of the “nag screen” even better. Not every installation is the same so we can’t do some simple magic to “fix” something which is not broken.
Well if you read the Arch post, that is the way you’re pointing at: [SOLVED] error: no such cryptodisk found / Newbie Corner / Arch Linux Forums. We just have to write it down in a way that everyone may understand what to do …
Strangely, my wifi driver module is now missing after update and so I am unable to get the TP-Link AC600 Archer T2U working
inxi -Fxz
Network:
Device-1: Intel Ethernet I219-V vendor: Micro-Star MSI driver: e1000e
v: kernel port: N/A bus-ID: 00:1f.6
IF: enp0s31f6 state: down mac:
Device-2: TP-Link 802.11ac WLAN Adapter type: USB driver: N/A
bus-ID: 1-12:4
From memory I was using the ‘rtl88xxau-aircrack-dkms-git’ module and suddenly it is not installed anymore!?
UPDATE: It seems to be working OK when I reinstall with ‘yay rtl88xxau-aircrack-dkms-git’
despite an error in the output:
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [######################] 100%
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
(2/2) checking available disk space [######################] 100%
:: Running pre-transaction hooks...
(1/1) Remove DKMS modules
==> dkms remove --no-depmod rtl8812au/r176.4fa0ce3 -k 5.15.104-2-MANJARO
==> dkms remove --no-depmod rtl8812au/r176.4fa0ce3 -k 6.1.21-1-MANJARO
==> depmod 5.15.104-2-MANJARO
==> depmod 6.1.21-1-MANJARO
:: Processing package changes...
(1/1) removing rtl8812au422-dkms-git [######################] 100%
(1/1) installing rtl88xxau-aircrack-dkms-git [######################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Install DKMS modules
==> dkms install --no-depmod rtl88xxau/r1246.fe71d83 -k 6.1.21-1-MANJARO
==> dkms install --no-depmod rtl88xxau/r1246.fe71d83 -k 5.15.104-2-MANJARO
Module version v5.6.4.2_35491.20191025 for 88XXau.ko.xz
exactly matches what is already found in kernel 5.15.104-2-MANJARO.
DKMS will not replace this module.
You may override by specifying --force.
Error! Installation aborted.
==> WARNING: `dkms install --no-depmod rtl88xxau/r1246.fe71d83 -k 5.15.104-2-MANJARO' exited 6
==> depmod 6.1.21-1-MANJARO
EDIT: seems to have happened during a kernel upgrade to linux61
==> dkms install --no-depmod rtl88xxau/r1211.e7a4a39 -k 6.1.21-1-MANJARO
Error! Bad return status for module build on kernel: 6.1.21-1-MANJARO (x86_64)
Consult /var/lib/dkms/rtl88xxau/r1211.e7a4a39/build/make.log for more information.
==> WARNING: `dkms install --no-depmod rtl88xxau/r1211.e7a4a39 -k 6.1.21-1-MANJARO’ exited 10
DUAL MONITORS ISSUE
After this update i rebooted the pc and the system switched my 2 monitors: the main became the secondary and viceversa.
I use LXQt with KWin, the graphics card has 3 outputs: HDMI (main monitor fullHD), DVI (secondary monitor 1680x1050) and VGA (not connected).
I tried to solve this using xrandr and the monitor settings in the Settings, but nothing changed.
I switched from KWin to Openbox and with xrandr it works but temporarily (anyway the system bar keeps staying in the secondary monitor, i have to change its settings manually), if i reboot the section or the pc, monitors switch again.
It seems that the system is not able to save the settings.
Any help or ideas? (If you need any output please post the command you need, thanks)
Thanks for sharing! Having the same problem with a setup that’s not really that customized. Please, let us know if you find a better workaround/solution than disabling OpenCL.
In the end I managed to get rid of intel-oneapi-compiler-shared-opencl-cpu. Though I had to remove searxng-git (from AUR) then install it directly - for some reason the AUR bundle has a vast array of dependencies that the package doesn’t actually need.
1 Like
search this topic for xsettingsd
3 Likes