[Testing Update] 2021-03-09 - Kernels, Firefox-Dev, Thunderbird, KDE Apps 20.12.3, LibreOffice 7.1.1

Announcements Testing Updates
,
#1

Hello community,

Another testing branch update with some usual updates for you.

2048Ă—979 191 KB

We are currently optimizing some MiniPCs from Beelink. Visit their shop to get more infos!

  • Most of the Kernels got updated
  • Thunderbird is now at 78.8.1
  • New point-release of KDE-Apps got added
  • LibreOffice pushed out another minor-release: 7.1.1
  • Other regular upstream updates including python and haskell

Get our latest daily developer images now from Github: Plasma, Gnome, XFCE. You can also help us with the Stable-Review images, so the upcoming installer ISOs are solid for Newcomers!

Our current supported kernels

  • linux44 4.4.260
  • linux49 4.9.260
  • linux414 4.14.224
  • linux419 4.19.179
  • linux54 5.4.103
  • linux59 5.9.16 [EOL]
  • linux510 5.10.21
  • linux511 5.11.4
  • linux512 5.12-rc2
  • linux54-rt 5.4.93_rt51
  • linux59-rt 5.9.1_rt19

Packages Changes (Tue Mar 9 09:54:34 CET 2021)

  • testing community x86_64: 1047 new and 1069 removed package(s)
  • testing core x86_64: 27 new and 25 removed package(s)
  • testing extra x86_64: 635 new and 626 removed package(s)
  • testing kde-unstable x86_64: 193 new and 193 removed package(s)
  • testing multilib x86_64: 8 new and 8 removed package(s)

A detailed list of all package changes can be found here.

  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes i am currently experiencing an issue due to the update. (Please post about it)

0 voters

Check if your mirror has already synced:

6 Likes
#2

Known issues and solutions

This is a wiki post; please edit as necessary.
Please, consider subscribing to the Testing Updates Announcements RSS feed

New issues:

  • OS prober does not run and add other operating systems

    Please click the â–ş at the beginning of this line to view this solution

    Manualy add the line GRUB_DISABLE_OS_PROBER=false to /etc/default/grub
    Run sudo update-grub

    For more information, see opening post in [Stable Update] 2021-03-08.

Recent Arch Linux news:

PHP 8.0 and PHP 7 legacy packages are available

PHP 8.0 and PHP 7 legacy packages are available

2021-01-28 - Pierre Schmitz

The php package has been updated to version 8.0. Please refer to the upstream migration guide. As some applications are not compatible with PHP 8 yet we provide a php7 package which can be installed alongside version 8. Packages that depend on PHP reflect this update and will require php7 if needed. You might need to update your configuration accordingly. PHP 7 binaries and configuration have the “7” suffix:

  • /usr/bin/php → /usr/bin/php7
  • /etc/php → /etc/php7
  • /usr/bin/php-fpm → /usr/bin/php-fpm7
  • /usr/lib/systemd/system/php-fpm.service → /usr/lib/systemd/system/php-fpm7.service
  • /run/php-fpm → /run/php-fpm7

We also provide third party modules compiled for PHP 7:

Note that support for php7 will be limited and likely be dropped in about a year depending on how soon the majority of applications will be compatible with version 8.

https://archlinux.org/news/php-80-and-php-7-legacy-packages-are-available/

Chromium losing Sync support in early March

Chromium losing Sync support in early March

2021-02-03 - Evangelos Foutras

Google has announced that they are going to block everything but Chrome from accessing certain Google features (like Chrome sync) starting on March 15. This decision by Google is going to affect Arch’s chromium package a bit earlier, on March 2, when Chromium 89 gets released.

We know for sure that data syncing will stop working (passwords, bookmarks, etc.). Other features such as geolocation or enhanced spell check might continue to function for a bit longer. Extensions integrating with Google Drive might misbehave and LibreOffice will lose access to documents stored there.

Other distros such as openSUSE and Fedora have already removed the soon-to-be-limited API keys from their Chromium 88 packages. Fedora’s advisory provides a great deal of perspective on this and I also found this Hackaday post to be quite informative.

https://archlinux.org/news/chromium-losing-sync-support-in-early-march/

Older Issues

Nvidia card owners

  • We simplified nVidia driver installation. This means we dropped legacy drivers.

    • We recommend to switch over to Nouveau drivers if your card is mentioned here and the feature you need is not in red TO DO here for your particular card.

    • If you however still need proprietary drivers, you may want to execute the following to ensure all parts of the nVidia drivers get installed properly:

      sudo mhwd -a pci nonfree 0300
      If proprietary drivers don't fix everything, please click the â–ş at the beginning of this line to view more info
      1. try installing kernel 5.4 LTS (Long Term Support)
      2. If that doesn’t fix it, take a full system backup, go to a console using Ctrl+Alt+F2 and:

      • Backup /etc/X11/mhwd.d/nvidia.conf if you ever edited that manually

      • remove all nVidia related drivers and applications:

        pacman --remove nvidia*

      • Note which applications are being removed and keep them handy in a list

      • Install the driver first:

        mhwd --install video-hybrid-XXX-nvidia-prime

        (Where XXX is amd or intel if you have hybrid graphics or the whole thing is video-nvidia if you’re on an nVidia-only system)

      • reboot and see if you at least get a screen.

      • Install all the other applications from your handy list that you still need one by one.

      • Restore /etc/X11/mhwd.d/nvidia.conf if you ever edited that manually

      • If that wouldn’t solve the issue open a new issue here referring to this update and posting at a minimum the full output of:

        inxi --admin --verbosity=7 --filter --no-host --width

      If you however still have issues with your Nvidia card, you may open a new thread in our forum: https://forum.manjaro.org/c/support/Graphic-Cards/33 or look at our tutorial on compiling old Nvidia drivers.

For AMD GPU users having a black screen with kernel 5.10

Please click the â–ş at the beginning of this line to view more info

Due to a bug in the AMD drivers, please try the following first:

For GRUB:

  1. Open a terminal or a TTY
  2. Open /etc/default/grub in your favourite CLI editor (nano vi, emacs`)
  3. Find the line: GRUB_CMDLINE_LINUX_DEFAULT="
  4. Add amdgpu.dc=0
  5. Save
  6. Execute sudo update-grub and reboot

For systemd-boot:

  1. Open a terminal or a TTY
  2. Open /boot/loader/entries/manjarolinux5.10.conf in your favourite CLI editor (nano vi, emacs`)
  3. Add amdgpu.dc=0 to the end of the line options
  4. Save & reboot

For rEFInd:

  1. Open a terminal or a TTY
  2. Open /boot/refind_linux.conf in your favourite CLI editor (nano vi, emacs`)
  3. Find the line: "Boot using default options" "root=
  4. Add amdgpu.dc=0
  5. Save & reboot

Possible 2 Min delay on shutdown with Gnome

Please click the â–ş at the beginning of this line to view more info
  • If you got the problem with shutdown delay (about 2min) on Gnome, here is a workaround:

    • Edit /usr/lib/systemd/user/gnome-session-restart-dbus.service in your favourite editor as root and add Slice=-.slice as a line all by itself like this:

      [Service]
Type=notify
Slice=-.slice
ExecStart=/usr/lib/gnome-session-ctl --restart-dbus

    • Click this link For more information

Touchpad on a ThinkPad stops working

  • Restart again, please.

You get [PKGNAME] warning: directory permissions differ on [Directory name]

followed by:

Filesystem: NNN package MMM

Please click the â–ş at the beginning of this line to view this solution

  • The solution:

    sudo chmod MMM DirectoryName

Where obviously MMM is the second number you see (the correct one)

  • The explanation:
    Your package expects the security permissions to be MMM but your system is set to NNN. This is just a warning (today) but to ensure you remain up-to-date with the latest and greatest security rules it’s advised to execute the above command.

Systemd error message: .slice: Failed to migrate controller cgroups

If you have a similar error message like this:

systemd[1004]: -.slice: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied

… you may need to add this Grub parameter to your /etc/default/grub file in line GRUB_CMDLINE_LINUX_DEFAULT: systemd.unified_cgroup_hierarchy=true. To update your grub menu, call: sudo update-grub. For more information on that issue, see also Arch Forum.

Python 3.9 Requires Rebuilds

Instructions for quickly and easily rebuilding affected AUR packages:

# Install yay
sudo pacman -S --needed --noconfirm yay

# Rebuild AUR python packages
yay -S --noconfirm $(pacman -Qqo "/usr/lib/python3.8/site-packages")

libtraceevent>=5.9-1 update requires manual intervention

2020-10-23 - SĂ©bastien Luttringer

The libtraceevent package prior to version 5.9-1 was missing a soname link. This has been fixed in 5.9-1, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get any of these errors

libtraceevent: /usr/lib/libtraceevent.so.1 exists in filesystem

when updating, use

pacman -Syu --overwrite /usr/lib/libtraceevent.so.1

to perform the upgrade.

https://www.archlinux.org/news/libtraceevent59-1-update-requires-manual-intervention/

OpenVPN connection times out.

Workaround: donwgrade openvpn (2.5.0-1 => 2.4.9-2).
For a proper solution follow this bug report on Arch Linux: FS#68480 : [openvpn] running unprivileged with iproute no longer working

PAM and PAMBASE got updated, which might prevent you from login

Due to updates from pambase and pam you might take care about any .pacnew files in /etc/pam.d as for example pam_tally, pam_tally2 and pam_cracklib got deprecated. Read in the ArchWiki about managing those files.

Typical issue:

For recovery, it is enough to boot with kernel option “systemd.unit=rescue.target”, then proceed into /etc/pam.d and merge “system-auth” and “system-auth.pacnew”

System takes a long time to boot

If you’ve got errors like Failed to start Network Manager Wait Online. you can try removing systemd from passwd and group in /etc/nsswitch.conf as described here
Update: If you can see the line
dbus-daemon[1453]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 45146ms)
in in your dbus log ( journalctl -b -u dbus ), the new/better workaround is to switch cups from service to socket as described here:
systemctl disable cups.service
systemctl enable cups.socket

I think I’ve some font problems

With the update of fontconfig some major rules how fonts get applied changed. Make sure that your system has ttf-dejavu installed. A more in depth explanation can be found here.

Gnome-shell-extension-pop-shell is currently incompatible with wayland

… and causes the system to freeze when the first window is tiled and can render it unbootable. Solution is a hard reset and disabling either pop shell or wayland. If the system becomes unbootable, use a live USB to edit /etc/gdm/custom.conf to disable wayland and reboot.

1 Like
#3

After updating to kernel 5.11.4-1, I got

Failed to start Load Kernel Modules.

and the graphical desktop could not be loaded.
In Xorg.0.log, I had the following errors:

[   168.106] (II) Loading sub module "ramdac"
[   168.106] (II) LoadModule: "ramdac"
[   168.106] (II) Module "ramdac" already built-in
[   168.108] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[   168.108] (EE) NVIDIA:     system's kernel log for additional error messages and
[   168.108] (EE) NVIDIA:     consult the NVIDIA README for details.
[   168.108] (EE) No devices detected.
[   168.108] (EE) 
Fatal server error:
[   168.108] (EE) no screens found(EE) 
[   168.108] (EE)

dmesg showed the following errors:

[    1.159347] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.168887] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.177875] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.231638] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.284749] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.296969] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '

Apparently, simply reinstalling the linux511-nvidia390xx package is not enough - the driver needs to be compiled against the new kernel.
After I re-created the linux511-nvidia390xx package from the PKGBUILD on GitLab (Packages / Extra / linux511-extramodules / nvidia-390xx · GitLab), re-installed it and also did sudo mkinitcpio -P, I was able to load the graphical desktop again after another reboot.

What remains interesting:
After cd /lib/modules/5.11.4-1-MANJARO/extramodules and sudo modinfo * | grep -E "filename|vermagic" I could verify that the version magic seems to be correct:

modinfo: ERROR: Module version not found.
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-drm.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-modeset.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-uvm.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload

However, the error message above still persists in the dmesg output:

[    1.159347] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.168887] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.177875] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.231638] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.284749] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
[    1.296969] nvidia: version magic '5.11.2-1-MANJARO SMP preempt mod_unload ' should be '5.11.4-1-MANJARO SMP preempt mod_unload '
#4

which version of nvidia-390 got installed on your system?

linux511-nvidia-390xx            390.141-5            390.141-7
#5

I have

local/linux511-nvidia-390xx 390.141-7 (linux511-extramodules)
    NVIDIA drivers for linux.
#6

Well I see no issue with that package we have in repos:

[phil@development nvidia-390]$ grep pkgver .PKGINFO 
pkgver = 390.141-7
[phil@development nvidia-390]$ grep build .PKGINFO 
builddate = 1615138226
[phil@development nvidia-390]$ grep packager .PKGINFO 
packager = Helmut Stult <helmut@manjaro.org>
[phil@development nvidia-390]$ modinfo usr/lib/modules/extramodules-5.11-MANJARO/* | grep -E "filename|vermagic"
filename:       /home/phil/dev/git/tmp/nvidia-390/usr/lib/modules/extramodules-5.11-MANJARO/nvidia-drm.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /home/phil/dev/git/tmp/nvidia-390/usr/lib/modules/extramodules-5.11-MANJARO/nvidia-modeset.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /home/phil/dev/git/tmp/nvidia-390/usr/lib/modules/extramodules-5.11-MANJARO/nvidia.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload
#7

Added os-prober issue to the wiki post (from yesterday’s stable release).

3 Likes
#8

That is exactly what puzzles me.
uname -r says here:

5.11.4-1-MANJARO

modinfo /usr/lib/modules/extramodules-5.11-MANJARO/* | grep -E "filename|vermagic" also, as described above, says

modinfo: ERROR: Module /usr/lib/modules/extramodules-5.11-MANJARO/version not found.
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-drm.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-modeset.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload 
filename:       /usr/lib/modules/extramodules-5.11-MANJARO/nvidia-uvm.ko.gz
vermagic:       5.11.4-1-MANJARO SMP preempt mod_unload

The driver is finally loaded, and the desktop appears but where does this version magic error come from?

#9

We are doing 5.11.5 currently anyway …

#10

What happened to linux-latest in the AUR?

1 Like
#11

As for that error in the dmesg output:

I now again did

sudo mkinitcpio -P
sudo update-grub

and rebooted. Now that error seems to have gone away. Strange…

#12

I have not found anything affecting my system, everything seems fine :joy_cat:

#13

If I understood it right they will drop it later

#14

Minor glitch, battery widget shows double mouse entries.

image

#15

This will be a huge change for people who wants to have dual booting, like the classic Manjaro/Windows dual boot. This is not really a bug in itself, as it is intentionally disabled and not by accident because of a programming error, but this choice means that people won’t be able to boot Windows from GRUB, which is something that we were usually able to do on Manjaro and with Linux OS in general and somehow has become the “de facto” standard in term of behavior.

Manjaro will most likely suffer from this choice for a time, and I do expect a lot of complains from the users, outcrying that “MY DUAL BOOT IS BROKEN CAN’T BOOT TO WINDOWS” or even worse, “OH MY GOD MANJARO DELETED WINDOWS HOLY CRAP” simply because they can’t see Windows in GRUB anymore.

Plus, any new user trying to do a dual boot will have an unpleasant surprise that they have to change the configuration of GRUB in order to have access to GRUB inside Windows, and I am afraid that Manjaro will be compared to Ubuntu, Linux Mint, etc., where it still works as it used to be (although there is no guarantee that it won’t change in the future).

For people that use UEFI, you can still boot Windows manually by selecting it in the boot override menu or whatever, although it is much less convenient than selecting it from GRUB I suppose.

I know it has been disabled for security reasons. But disabling it is not without consequence. Hopefully users will be able to accept this new reality. I would understand if Manjaro devs revert their decision for the sake of convenience and user-friendliness though.

Of course, people that use Manjaro as their only operating system has nothing to fear from this change, obviously.

EDIT: Just noticed that it was already a thing in Stable, which would explain (partly perhaps) the relatively bad result in the pool. My bad.

3 Likes
#16

Dual boot on 2 separat nvmes and you are Safe :wink:

#17

@pheiduck You would still have to go in the UEFI to manually select your OS, right?

#18

Yep, in my workflow it is the best way, I don’t want to mix partitions on a Single drive and fixing issues at night :wink: when the System won’t boot because Windows Overwrites something

1 Like
#19 
Linux chaplindev-arch 5.11.4-1-MANJARO #1 SMP PREEMPT Sun Mar 7 16:15:35 UTC 2021 x86_64 GNU/Linux 
NVRM version: NVIDIA UNIX x86_64 Kernel Module  460.56  Tue Feb 23 23:31:36 UTC 2021

Just updated, so far so good as expected, Thanks Manjaro Team :). Just some logs from jornalctd but does not interrupt the PC performance so far:

Screenshot from 2021-03-09 11-22-01
Screenshot from 2021-03-09 11-22-011715Ă—726 160 KB

#20

Its depressing just how many threads there have been since yesterday "my grub is broken ". Is it really that difficult to read the update thread before or even after you update?

2 Likes