YES - it works -Thank You
After upgrading from Kernel version
6.2.8-1, I get the error message:
$ journalctl --no-pager -p 3 -b --output=cat spl: version magic '6.2.7-2-MANJARO SMP preempt mod_unload ' should be '6.2.8-1-MANJARO SMP preempt mod_unload ' spl: version magic '6.2.7-2-MANJARO SMP preempt mod_unload ' should be '6.2.8-1-MANJARO SMP preempt mod_unload '
It looks like version magic of spl doesn’t match kernel version.
$ modinfo spl filename: /lib/modules/6.2.8-1-MANJARO/extramodules/spl.ko.xz version: 2.1.9-1 license: GPL author: OpenZFS description: Solaris Porting Layer srcversion: 0248BCBBFA4DFB290E4D2F0 depends: retpoline: Y name: spl vermagic: 6.2.7-2-MANJARO SMP preempt mod_unload
Install(But the ZFS module is not loaded.)
zfs-dkms. The error messages are gone.
OpenZFS 2.1.9 is not compatible with Kernel 6.2.8, because building the zfs module failed, but it has no issue with Kernel 6.2.7.
Switch back to Kernel 6.1 LTS, no error message in journalctl
The known issue:
NVIDIA 530.41.03 drivers will be available shortly.
Note that there is now compatibility for Linux kernels with Indirect Branch Tracking (IBT). The
ibt=off kernel parameter is no longer required.
VirtualBox still needs this kernel parameter when using Intel 11th CPU.
Why? More info, please?
Either way, that has nothing to do with the NVIDIA driver.
I tested VirutalBox on Intel11th CPU. If I removed this kernel parameter, then I still get the same issue as before:
6 posts were split to a new topic: Substring instead of substituted value after mkinitcpio update
Best solution for me:
I created a new KVM/QEMU to setup a small NAS with separate Kernel 6.1 LTS and ZFS that directly access my external physical disks as pass-through disks via PCI without virtual.
- Host: Kernel 6.2 is now running on my PC without ZFS.
- Guest: Kernel 6.1 LTS is running on my KVM with ZFS on the same PC.
Both communicate via a local NFS share (Speed ~31Gb/s). NFS preserves all file permissions , Samba does not.
They plan to have a proper fix for this in the 2.1.10 release, see this comment on that issue.
Please make a backup and test
There should be no issues on EFI systems. The main thing is making sure it still works with Legacy BIOS.
I have no issue with it now.
no issues here, using Legacy mode.
Looks good with legacy mode and sorted out .pacnew.
edit: reinstalled GRUB via chroot , no issues.
Nullo problemo - efi
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck --verbose
Not exactly legacy, but UEFI and CSM (due to graphics card).
No problems so far.
Seems to be a slight oddity with full disk encryption with the
grub 2.06.r456.g65bc45963-1 update.
Both my boot and root are encrypted. When I originally installed Manjaro, I used the default encryption setup in Calamares
I get this error after grub prompts me for my disk key:
error: no such cryptodisk found. Press any key to continue...
But it continues to boot fine after.
Including some system details.
System: Kernel: 6.2.8-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.1 Desktop: GNOME v: 43.4 Distro: Manjaro Linux base: Arch Linux Machine: Type: Desktop Mobo: ASRock model: X670E PG Lightning serial: <filter> UEFI: American Megatrends LLC. v: 1.18.AS04 date: 02/16/2023 CPU: Info: 12-core model: AMD Ryzen 9 7900X bits: 64 type: MT MCP arch: Zen 4 rev: 2 cache: L1: 768 KiB L2: 12 MiB L3: 64 MiB Speed (MHz): avg: 3212 high: 4700 min/max: 3000/5733 boost: enabled cores: 1: 4700 2: 3000 3: 4700 4: 3000 5: 3000 6: 3000 7: 3000 8: 3000 9: 3000 10: 3000 11: 3000 12: 3000 13: 3000 14: 4700 15: 3000 16: 3000 17: 3000 18: 3000 19: 3000 20: 3000 21: 3000 22: 3000 23: 3000 24: 3000 bogomips: 225272 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm Graphics: Device-1: AMD Navi 31 [Radeon RX 7900 XT/7900 XTX] vendor: XFX driver: amdgpu v: kernel arch: RDNA-3 bus-ID: 03:00.0 Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] vendor: Sapphire driver: vfio-pci v: N/A arch: GCN-4 bus-ID: 04:00.0 Device-3: Sunplus Innovation 1080P Webcam type: USB driver: snd-usb-audio,uvcvideo bus-ID: 1-5:5 Display: server: X.Org v: 23.1 with: Xwayland v: 23.1.0 driver: X: loaded: amdgpu unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu resolution: 2560x1440~60Hz API: OpenGL v: 4.6 Mesa 22.3.7 renderer: AMD Radeon RX 7900 XT (gfx1100 LLVM 15.0.7 DRM 3.49 6.2.8-1-MANJARO) direct-render: Yes Audio: Device-1: AMD driver: snd_hda_intel v: kernel bus-ID: 1-3.3:6 Device-2: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] vendor: Sapphire driver: vfio-pci bus-ID: 04:00.1 Device-3: AMD Family 17h/19h HD Audio vendor: ASRock driver: snd_hda_intel v: kernel bus-ID: 1b:00.6 Device-4: SteelSeries ApS Arctis 7 type: USB driver: hid-generic,snd-usb-audio,usbhid Device-5: Blue Microphones Yeti Stereo Microphone type: USB driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-4:3 Device-6: Sunplus Innovation 1080P Webcam type: USB driver: snd-usb-audio,uvcvideo bus-ID: 1-5:5 Sound API: ALSA v: k6.2.8-1-MANJARO running: yes Sound Server-1: PulseAudio v: 16.1 running: no Sound Server-2: PipeWire v: 0.3.67 running: yes Network: Device-1: Realtek RTL8125 2.5GbE vendor: ASRock driver: r8169 v: kernel port: d000 bus-ID: 11:00.0 IF: enp17s0 state: up speed: 1000 Mbps duplex: full mac: <filter> IF-ID-1: virbr0 state: down mac: <filter> Drives: Local Storage: total: 3.64 TiB used: 1.93 TiB (52.9%) ID-1: /dev/nvme0n1 vendor: Crucial model: CT1000P5SSD8 size: 931.51 GiB temp: 41.9 C ID-2: /dev/sda vendor: Crucial model: CT2000MX500SSD1 size: 1.82 TiB ID-3: /dev/sdb vendor: Crucial model: CT1000MX500SSD1 size: 931.51 GiB Partition: ID-1: / size: 915.52 GiB used: 459.7 GiB (50.2%) fs: ext4 dev: /dev/dm-0 mapped: luks-d20ac551-a64c-451a-8849-4c7f7927e453 ID-2: /boot/efi size: 299.4 MiB used: 440 KiB (0.1%) fs: vfat dev: /dev/nvme0n1p1 Swap: ID-1: swap-1 type: file size: 32 GiB used: 0 KiB (0.0%) file: /swapfile Sensors: System Temperatures: cpu: 49.8 C mobo: N/A gpu: amdgpu temp: 44.0 C Fan Speeds (RPM): N/A gpu: amdgpu fan: 0 Info: Processes: 487 Uptime: 4m Memory: 31.06 GiB used: 2.96 GiB (9.5%) Init: systemd Compilers: gcc: 12.2.1 clang: 15.0.7 Packages: 1609 Shell: Zsh v: 5.9 inxi: 3.3.25
GRUB_DEFAULT=saved GRUB_TIMEOUT=5 GRUB_TIMEOUT_STYLE=hidden GRUB_DISTRIBUTOR="Manjaro" GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=d20ac551-a64c-451a-8849-4c7f7927e453:luks-d20ac551-a64c-451a-8849-4c7f7927e453 root=/dev/mapper/luks-d20ac551-a64c-451a-8849-4c7f7927e453 splash apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 iommu=pt" GRUB_CMDLINE_LINUX="" # If you want to enable the save default function, uncomment the following # line, and set GRUB_DEFAULT to saved. GRUB_SAVEDEFAULT=true # Uncomment to disable submenus in boot menu #GRUB_DISABLE_SUBMENU=y # Preload both GPT and MBR modules so that they are not missed GRUB_PRELOAD_MODULES="part_gpt part_msdos" # Uncomment to enable booting from LUKS encrypted devices GRUB_ENABLE_CRYPTODISK=y # Uncomment to use basic console GRUB_TERMINAL_INPUT=console # Uncomment to disable graphical terminal #GRUB_TERMINAL_OUTPUT=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command 'videoinfo' GRUB_GFXMODE=auto # Uncomment to allow the kernel use the same resolution used by grub GRUB_GFXPAYLOAD_LINUX=keep # Uncomment if you want GRUB to pass to the Linux kernel the old parameter # format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx" #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries GRUB_DISABLE_RECOVERY=true # Uncomment this option to enable os-prober execution in the grub-mkconfig command GRUB_DISABLE_OS_PROBER=false # Uncomment and set to the desired menu colors. Used by normal and wallpaper # modes only. Entries specified as foreground/background. GRUB_COLOR_NORMAL="light-gray/black" GRUB_COLOR_HIGHLIGHT="green/black" # Uncomment one of them for the gfx desired, a image background or a gfxtheme #GRUB_BACKGROUND="/usr/share/grub/background.png" GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt" # Uncomment to get a beep at GRUB start #GRUB_INIT_TUNE="480 440 1" # Uncomment to ensure that the root filesystem is mounted read-only so that # systemd-fsck can run the check automatically. We use 'fsck' by default, which # needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be # removed from 'mkinitcpio.conf' to make 'systemd-fsck' work. # See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking #GRUB_ROOT_FS_RO=true
# vim:set ft=sh # MODULES # The following modules are loaded before any boot hooks are # run. Advanced users may wish to specify all system modules # in this array. For instance: # MODULES=(usbhid xhci_hcd) MODULES=(vendor-reset vfio_pci vfio vfio_iommu_type1) # BINARIES # This setting includes any additional binaries a given user may # wish into the CPIO image. This is run last, so it may be used to # override the actual binaries included by a given hook # BINARIES are dependency parsed, so you may safely ignore libraries BINARIES=() # FILES # This setting is similar to BINARIES above, however, files are added # as-is and are not parsed in any way. This is useful for config files. FILES=(/crypto_keyfile.bin) # HOOKS # This is the most important setting in this file. The HOOKS control the # modules and scripts added to the image, and what happens at boot time. # Order is important, and it is recommended that you do not change the # order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for # help on a given hook. # 'base' is _required_ unless you know precisely what you are doing. # 'udev' is _required_ in order to automatically load modules # 'filesystems' is _required_ unless you specify your fs modules in MODULES # Examples: ## This setup specifies all modules in the MODULES setting above. ## No RAID, lvm2, or encrypted root is needed. # HOOKS=(base) # ## This setup will autodetect all modules for your system and should ## work as a sane default # HOOKS=(base udev autodetect modconf block filesystems fsck) # ## This setup will generate a 'full' image which supports most systems. ## No autodetection is done. # HOOKS=(base udev modconf block filesystems fsck) # ## This setup assembles a mdadm array with an encrypted root file system. ## Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices. # HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck) # ## This setup loads an lvm2 volume group. # HOOKS=(base udev modconf block lvm2 filesystems fsck) # ## NOTE: If you have /usr on a separate partition, you MUST include the # usr, and fsck hooks. HOOKS=(base udev autodetect modconf keyboard keymap plymouth encrypt block filesystems fsck) # COMPRESSION # Use this to compress the initramfs image. By default, gzip compression # is used. Use 'cat' to create an uncompressed image. #COMPRESSION="gzip" #COMPRESSION="bzip2" #COMPRESSION="lzma" #COMPRESSION="xz" #COMPRESSION="lzop" #COMPRESSION="lz4" #COMPRESSION="zstd" # COMPRESSION_OPTIONS # Additional options for the compressor #COMPRESSION_OPTIONS=() # MODULES_DECOMPRESS # Decompress kernel modules during initramfs creation. # Enable to speedup boot process, disable to save RAM # during early userspace. Switch (yes/no). #MODULES_DECOMPRESS="yes"
Decided to post here in case others are in the same boat. Will update this post as I find a solution.
Starting my research journey here: [SOLVED] error: no such cryptodisk found / Newbie Corner / Arch Linux Forums
Added cryptodisk to grub preload modules in /etc/default/grub
GRUB_PRELOAD_MODULES="cryptodisk part_gpt part_msdos"
Updated grub config and rebuild initramfs
sudo update-grub sudo mkinitcpio -P
This alone did not fix the error, I then reinstalled grub.
Error gone and everything boots as normal.
With grub 2.06.r456.g65bc45963-2 I reverted a change to also support installs with in-proper grub updates. Here the background:
A normal user will install grub only once. This happens when our installer Calamares does it for you. If you update the grub package via pamac or pacman you won’t update grub itself in your master boot record (MBR) or UEFI. This means you may still run an outdated grub on your system to boot your OS. Some grub updates however have security fixes which need to call grub-install. However, that most of you have different installs and there is now standard way like Asahi-LInux may do on their end calling grub-install is more riskier to break your bootability than not installing grub in your MBR.
Wait a minute, if I update grub I actually don’t? Yep, that is the case here. But why is it now a potential issue if the grub package gets updated? Well with a certain commit late 2022 the application fwsetup got a flag added to test for a function your UEFI firmware may or may not have. Those who have the support were fine, others not. Also the initial support called that application on legacy BIOS systems. That was fixed by upstream.
The background story of this can be found here: FS#75701 : grub 2:2.06.r322.gd9b4638c5-1 issue and here Re: [Regression] efi: Don't display a uefi-firmware entry if it's not su.
For me it is better to not call fwsetup at all and have a potential grub menu entry to enter the UEFI firmware from the grub menu, which potentially may fail in rare cases, than causing infinite bootloops into the UEFI firmware and not being able to boot Linux or any OS at all …
To be secure read our wiki on how to reinstall grub as needed: GRUB/Restore the GRUB Bootloader - Manjaro
@philm After reading the bug reports and discussions, I have tried installing it on my EFI machine, and it doesn’t have this problem where choosing UEFI settings via the grub selector causes a bootloop. Thank you for applying the fix, and I completely agree about not calling fwsetup.
If one follows the protocol of not changing any settings other than in /etc/default/grub, even calling grub-install and grub-mkconfig via pamac should be fine, should you one day decide to push it, but in rare cases where people use custom.cfg for grub menus and specific fw paths for multiboot, it might create conflicts with os_prober (it didn’t in my case).
So if I am understanding this right, security has been sacrificed for the sake of stability? If someone has been using Manjaro for years without knowing this, they could be open to tons of CVEs that they believe had been patched on their system.