My switch to the 5.10 kernel with update 2020-12-30

  1. Installed rebuild-detector as recommend in the announcement:

    [2020-12-31T09:50:27+0300] [PACMAN] Running 'pacman -S rebuild-detector'
    [2020-12-31T09:51:01+0300] [ALPM] transaction started
    [2020-12-31T09:51:01+0300] [ALPM] upgraded archlinux-keyring (20201028-1 ->    20201210-1)
    ....
    [2020-12-31T09:51:04+0300] [ALPM-SCRIPTLET] gpg: next trustdb check due at 2021-08-02
    [2020-12-31T09:51:04+0300] [ALPM] upgraded manjaro-system (20201014-1 -> 20201211-1)
    [2020-12-31T09:51:04+0300] [ALPM-SCRIPTLET] ==> Maintaining video driver nvidia-455xx
    [2020-12-31T09:51:04+0300] [ALPM-SCRIPTLET] rm: cannot remove '/var/lib/mhwd/local/pci/video-nvidia-450xx/': No such file or directory
    [2020-12-31T09:51:04+0300] [ALPM-SCRIPTLET] cp: cannot stat '/var/lib/mhwd/db/pci/graphic_drivers/nvidia': No such file or directory
    [2020-12-31T09:51:05+0300] [ALPM] transaction completed
    [2020-12-31T09:51:05+0300] [ALPM] running '30-systemd-update.hook'...
    [2020-12-31T09:52:08+0300] [ALPM] transaction started
    [2020-12-31T09:52:08+0300] [ALPM] installed parallel (20200322-1)
    [2020-12-31T09:52:08+0300] [ALPM] installed pacutils (0.10.0-1)
    [2020-12-31T09:52:08+0300] [ALPM] installed rebuild-detector (4.1.5-1)
    [2020-12-31T09:52:08+0300] [ALPM] transaction completed
    
  2. Updated system with pamac CLI, and noticed these pacman logs:

    [2020-12-31T10:19:52+0300] [ALPM] removed lib32-nvidia-455xx-utils (455.45.01-1)
    [2020-12-31T10:19:52+0300] [ALPM-SCRIPTLET] xorg configuration symlink valid...
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-455xx (455.45.01-1)
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-450xx (450.80.02-1)
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-440xx (440.100-1)
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-435xx (435.21-1.0)
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-430xx (430.64-1.0)
    [2020-12-31T10:19:52+0300] [ALPM] removed mhwd-nvidia-418xx (418.113-1)
    

    Seemed ok so far…

    [2020-12-31T10:19:55+0300] [ALPM] warning: /etc/systemd/homed.conf installed as /etc/systemd/homed.conf.pacnew
    

    I never touched that file yet…

    [2020-12-31T10:20:03+0300] [ALPM] upgraded mhwd-nvidia-390xx (390.132-1 -> 390.138-1)
    [2020-12-31T10:20:03+0300] [ALPM] installed mhwd-nvidia (455.45.01-3)
    [2020-12-31T10:20:03+0300] [ALPM] upgraded mhwd-db (0.6.5-4 -> 0.6.5-7)
    ....
    [2020-12-31T10:20:03+0300] [ALPM] installed lib32-nvidia-utils (455.45.01-3)
    [2020-12-31T10:20:03+0300] [ALPM-SCRIPTLET] xorg configuration symlink valid...
    

    Seems lib32-nvidia-utils (455.45.01-3) got installed again…

    [2020-12-31T10:20:09+0300] [ALPM] upgraded linux59 (5.9.11-3 -> 5.9.16-1)
    [2020-12-31T10:20:09+0300] [ALPM-SCRIPTLET] >>> NOTE, 5.9.16 was the last maintenance release by Greg Kroah-Hartman.
    [2020-12-31T10:20:09+0300] [ALPM-SCRIPTLET]     This kernel series is now marked EOL (end of life).
    [2020-12-31T10:20:09+0300] [ALPM-SCRIPTLET]     
    [2020-12-31T10:20:09+0300] [ALPM-SCRIPTLET]     It is recommend to move on to linux510 series.
    [2020-12-31T10:20:09+0300] [ALPM-SCRIPTLET]     Use followed cmd to do that: 'sudo mhwd-kernel -i linux510'
    

    We get an heads-up to upgrade to the 5.10 kernel, okay we will…

    [2020-12-31T10:20:19+0300] [ALPM] warning: /root/.zshrc installed as /root/.zshrc.pacnew
    

    Why did this happen :thinking: (ohh well lets ignore i guess?)

    [2020-12-31T10:20:21+0300] [ALPM] upgraded pamac-flatpak-plugin (10.0.3-1 → 10.0.3-4)
    [2020-12-31T10:20:22+0300] [ALPM-SCRIPTLET] error: Can’t load uri https://flathub.org/repo/flathub.flatpakrepo: Error resolving “flathub.org”: Name or service not known
    Must be a DNS issue?
    (Although i reported about this before on the git…)

  3. Lets install the new kernel as instructed:
    sudo mhwd-kernel -i linux510

    ....
    Packages (3) linux510-5.10.2-2  linux510-broadcom-wl-6.30.223.271-9  linux510-headers-5.10.2-2
    ....
    Optional dependencies for linux510
        crda: to set the correct wireless channels of your country [installed]
    ....
    ==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'default'
      -> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64.img
    ==> Starting build: 5.10.2-2-MANJARO
      -> Running build hook: [base]
      -> Running build hook: [systemd]
      -> Running build hook: [autodetect]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
      -> Running build hook: [keyboard]
      -> Running build hook: [keymap]
      -> Running build hook: [sd-encrypt]
      -> Running build hook: [sd-lvm2]
      -> Running build hook: [filesystems]
      -> Running build hook: [bootsplash-manjaro]
      -> Running build hook: [fsck]
    ==> ERROR: module not found: `nvidia'
    ==> ERROR: module not found: `nvidia_modeset'
    ==> ERROR: module not found: `nvidia_uvm'
    ==> ERROR: module not found: `nvidia_drm'
    ==> Generating module dependencies
    ==> Creating gzip-compressed initcpio image: /boot/initramfs-5.10-x86_64.img
    ==> WARNING: errors were encountered during the build. The image may not be complete.
    

    :warning:Seems we won’t be able to boot with this kernel yet !

Problem with nVidia drivers:

  1. Reading Drivers removed - #9 by Aragorn,
    Had to manually remove nvidia-455xx-utils because the nvidia drivers will now be provided by nvidia-utils right?
    • pamac remove nvidia-455xx-utils
  2. Next running mhwd showed:
    >  mhwd                                     [1]
    Warning: config '/var/lib/mhwd/local/pci/video-nvidia-455xx/MHWDCONFIG' is invalid!
    > 0000:01:00.0 (0300:10de:1b06) Display controller nVidia Corporation:
    ....
    
  3. So had to manually remove that also:
    • sudo rm -R /var/lib/mhwd/local/pci/video-nvidia-455xx
  4. Next used the Auto Install Proprietary Driver option/button in the “Hardware Configuration” GUI from “Manjaro Settings Manager”
Click to see output of it in it's the window
Starting
> Using config 'video-nvidia' for device: 0000:01:00.0 (0300:10de:1b06) Display controller nVidia Corporation GP102 [GeForce GTX 1080 Ti]
> Installing video-nvidia...
Using default
Has lib32 support: true
Sourcing /var/lib/mhwd/db/pci/graphic_drivers/nvidia/MHWDCONFIG
Processing classid: 0300
Sourcing /var/lib/mhwd/scripts/include/0300
Processing classid: 0302
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
resolving dependencies...
looking for conflicting packages...

Packages (4) lib32-nvidia-utils-455.45.01-3  linux510-nvidia-455.45.01-8  linux59-nvidia-455.45.01-6  nvidia-utils-455.45.01-2

Total Download Size:   152.72 MiB
Total Installed Size:  473.51 MiB

:: Proceed with installation? [Y/n] 
:: Retrieving packages...
downloading nvidia-utils-455.45.01-2-x86_64.pkg.tar.zst...
downloading linux510-nvidia-455.45.01-8-x86_64.pkg.tar.zst...
downloading linux59-nvidia-455.45.01-6-x86_64.pkg.tar.zst...
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
installing nvidia-utils...
xorg configuration symlink valid...
==> If you run into trouble with CUDA not being available, run nvidia-modprobe first.
Optional dependencies for nvidia-utils
    gtk3: nvidia-settings [installed]
    xorg-server-devel: nvidia-xconfig
    opencl-nvidia: OpenCL support
installing lib32-nvidia-utils...
xorg configuration symlink valid...
Optional dependencies for lib32-nvidia-utils
    lib32-opencl-nvidia
installing linux510-nvidia...
In order to use nvidia module, reboot the system.
installing linux59-nvidia...
In order to use nvidia module, reboot the system.
:: Running post-transaction hooks...
(1/6) Creating system user accounts...
(2/6) Reloading system manager configuration...
(3/6) Arming ConditionNeedsUpdate...
(4/6) Updating module dependencies...
(5/6) Updating Kernel initcpios for Nvidia-DRM...
==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'default'
  -> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64.img
==> Starting build: 5.10.2-2-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [bootsplash-manjaro]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.10-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'fallback'
  -> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64-fallback.img -S autodetect
==> Starting build: 5.10.2-2-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [bootsplash-manjaro]
  -> Running bu
ild hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.10-x86_64-fallback.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux59.preset: 'default'
  -> -k /boot/vmlinuz-5.9-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.9-x86_64.img
==> Starting build: 5.9.16-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [bootsplash-manjaro]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.9-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux59.preset: 'fallback'
  -> -k /boot/vmlinuz-5.9-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.9-x86_64-fallback.img -S autodetect
==> Starting build: 5.9.16-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [bootsplash-manjaro]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.9-x86_64-fallback.img
==> Image generation successful
(6/6) Updating the desktop file MIME type cache...
nvidia-utils: install reason has been set to 'explicitly installed'
lib32-nvidia-utils: install reason has been set to 'explicitly installed'
linux510-nvidia: install reason has been set to 'explicitly installed'
linux59-nvidia: install reason has been set to 'explicitly installed'
xorg configuration file: '/etc/X11/mhwd.d/nvidia.conf'
> Successfully installed video-nvidia


Done ...

So seems to have successfully installed…
(will need to test with a reboot in few)

But i noticed it reverted my current x-config selection back to the default:

>  mhwd-gpu                                                                                                              
:: status
  xorg configuration file: '/etc/X11/mhwd.d/nvidia.conf'

Which i had changed to a custom version in different file, so need to modify that later after this first reboot with new kernel…

2 Likes
  1. Ok tried to reboot and could not boot the new kernel, because the systemd-boot-manager(0.9-1) package still created a wrong config:
    (fallback version is similar, just different ramdisk)

    • bootctl list
         title: Manjaro Linux 5.10 (manjarolinux5.10.conf)
            id: manjarolinux5.10.conf
        source: /efi/loader/entries/manjarolinux5.10.conf
         linux: /10eef4bb59134395bc85dfb713b67a70/vmlinuz-5.10-x86_64
        initrd: /10eef4bb59134395bc85dfb713b67a70/amd-ucode.img
                /10eef4bb59134395bc85dfb713b67a70/intel-ucode.img
                /initramfs-5.10-x86_64.img (No such file or directory)
       options: root=UUID=da54bb75-506a-4659-996c-f9bfcf94b2b7 rw cryptdevice=UUID=2d2d4f8f-d805-48f1-8ebb-dcf6ff0f77bd:luks2 apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 add_efi_memmap intel_iommu=on modeset=1 nvidia-drm.modeset=1
      
    • manjarolinux5.10.conf:
      title	Manjaro Linux 5.10
      linux	/10eef4bb59134395bc85dfb713b67a70/vmlinuz-5.10-x86_64
      initrd	/10eef4bb59134395bc85dfb713b67a70/amd-ucode.img
      initrd	/10eef4bb59134395bc85dfb713b67a70/intel-ucode.img
      initrd	/initramfs-5.10-x86_64.img
      options	root=UUID=da54bb75-506a-4659-996c-f9bfcf94b2b7 rw cryptdevice=UUID=2d2d4f8f-d805-48f1-8ebb-dcf6ff0f77bd:luks2 apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 add_efi_memmap intel_iommu=on modeset=1 nvidia-drm.modeset=1
      
    1. :warning: As can be seen it still generates an invalid entry for the kernel’s ramdisk, because it is located in same directory as the kernel instead of the root of the filesystem…
      A bug report to the package maintainer in past was closed without fixing this, and thus still present…
      I will try to report this to him in same issue with a link to this post.
    2. :warning: It still generates a wrong root= option for my full-disk LUKS root file-system setup.
      Reported at: Wrong configs generated when using LUKS2 (#8) ¡ Issues ¡ dalto / systemd-boot Manager for Manjaro ¡ GitLab
    3. It still generates a cryptdevice= option which is not used, will need to check if it causes problems, because the functionality is handled by the /etc/crypttab inside the ramdisk.
      See :woman_teacher:[HowTo] Boot without a password for encrypted root partition
  2. So I will need to create a config manually again:
    (fallback version is similar, just different ramdisk)

    • sed ‘s|5.9|5.10|g’ manjaro5.9.conf > manjaro5.10.conf
      manjaro5.10.conf:
      #/loader/entries/manjaro5.10.conf
      title		Manjaro Linux
      version		5.10
      machine-id	10eef4bb59134395bc85dfb713b67a70
      architecture	x64
      linux		/10eef4bb59134395bc85dfb713b67a70/vmlinuz-5.10-x86_64
      initrd		/10eef4bb59134395bc85dfb713b67a70/intel-ucode.img
      initrd		/10eef4bb59134395bc85dfb713b67a70/initramfs-5.10-x86_64.img
      #options	resume=/dev/mapper/luksSWAP root=UUID=dfd082e3-5928-4dd9-95f5-50bc074a5faa bootsplash.bootfile=bootsplash-themes/xxxxx/bootsplash
      options		root=/dev/mapper/Linux-ManjaroArchitect ro apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 add_efi_memmap intel_iommu=on modeset=1 nvidia-drm.modeset=1 bootsplash.bootfile=bootsplash-themes/manjaro/bootsplash
      
    • sed ‘s|5.9|5.10|g’ manjaro5.9-fallback.conf > manjaro5.10-fallback.conf
      manjaro5.10-fallback.conf:
      #/loader/entries/manjaro5.10-fallback.conf
      title		Manjaro Linux
      version		5.10-fallback
      machine-id	10eef4bb59134395bc85dfb713b67a70
      architecture	x64
      linux		/10eef4bb59134395bc85dfb713b67a70/vmlinuz-5.10-x86_64
      initrd		/10eef4bb59134395bc85dfb713b67a70/intel-ucode.img
      initrd		/10eef4bb59134395bc85dfb713b67a70/initramfs-5.10-x86_64-fallback.img
      options		root=/dev/mapper/Linux-ManjaroArchitect ro apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 add_efi_memmap intel_iommu=on modeset=1 nvidia-drm.modeset=1 bootsplash.bootfile=bootsplash-themes/manjaro/bootsplash
      

Time to try to boot in new kernel again…

1 Like

Ok seems all is working fine so far including a Steam game, both on the new 5.10 & older 5.9 kernels boots.

The only issue is that sometimes my DNS resolution doesn’t work, need to find the cause of that later.

  • Easy fix systemctl restart systemd-networkd
    Followed by a check resolvectl query forum.manjaro.org

Hope the info in this thread is useful for some others also :innocent:

1 Like

This should be fixed. However, it has been some time since I have done a formal release because it takes an immense investment in testing.(~40 hours) It is possible that the fix has not made it into Manjaro’s version of systemd-boot-manager. If that is not the case than I will look into it but based on your output I strongly suspect it is.

I am not sure it is wrong so much as not matched to your highly specific setup. Since your needs are so specific, it may not make sense for you to use systemd-boot-manager. The intention of it is to provide a transparent way to manage systemd-boot without needing any understanding of systemd-boot.

You are the opposite of the intended user for this. Not only are you familiar enough systemd-boot to manage it yourself but you have a highly specific way you would like it to work.

Uhmm :thinking:
As it is in the official repo’s and is installed by default when you use systemd-boot instead of grub, plus no statement that it is not compatible with a Full-Disk Encrypted setup:

  • I don’t see why i’m outside the intended user base in that case…
    It could be made to be compatible with encrypted root file-systems.
    That is un-related with my usage of LVM or BTRFS inside the encrypted container…
    I’m sure more people would use sd-boot, if it worked “as-expected” for both plain and encrypted setups…

Not really…It’s just encryption that the current script does not support, that can hardly be labeled like that :wink:

Using the UUID instead of /dev/mapper shouldn’t make it not compatible with full disk encryption. We have many people using this successfully with full disk encryption.

There have been many changes made to support this use case. I would also try testing it with the latest code and see if that resolves your issue.

Also, I test with many different encryption cases which is why testing is such a large burden.

1 Like

It does in this case, see: lsblk --fs

NAME                       FSTYPE      FSVER    LABEL        UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                        crypto_LUKS 2        WD40EZRZ-00W 2d2d4f8f-d805-48f1-8ebb-dcf6ff0f77bd                  
└─luks2                    LVM2_member LVM2 001              CNMSPt-srmi-XlU3-4tSf-CuQY-jMCA-sPyhuy                
  ├─Linux-Home             ext4        1.0                   c594117e-bd1e-468c-a6b8-e3ef43c1bea5      5.5G    38% /home
  ├─Linux-ManjaroArchitect ext4        1.0                   da54bb75-506a-4659-996c-f9bfcf94b2b7     80.7G    13% /
  └─Linux-SteamGameLib     ext4        1.0      SteamGameLib c757ec1d-b406-45ff-974f-24b607697362                  
sdb                        btrfs                Backups      7f9302f6-0006-480e-84a5-771c9e185581                  
sdc                                                                                                                
└─sdc1                     vfat        FAT32    ESP          A694-9741                               765.5M    25% /efi
sdd                                                                                                                
sr0                                                                                                                
zram0                                                                                                              [SWAP]

Edit:

Ok i correct myself: Seems the UUID used was indeed correct one, sorry…
But anyway, this shows how hard it is to distinguish using UUID, while it makes more sense (and easier) to use mapper names when encryption is used…

Thanks It helped. I had problem with the nvidia drivers

I have just recently installed manjaro (5.9 kernel) after a few teething issues :slight_smile: . I am using systemd-boot. I have heard that there are some issues after updating a kernel if using sd-boot and that some additional manual steps are required. I’m not sure whether or not this is accurate? I just wanted to know what I need to do before upgrading from 5.9 to 5.10. Is it as simple as following this guide?

I have already installed rebuild-detector and systemd-boot-pacman-hook.

TIA