[Testing Update] 2019-06-01 - Kernels, Xorg-Server, FF-Dev, Haskell, Python

Hello community,

I am happy to announce another Testing Update!

This update holds the following changes:

  • We updated most of our Kernels
  • Xorg-Server is now at 1.20.5
  • Firefox-Dev and some Python updates
  • Some more Haskell package updates
  • We also released new Preview-ISOs of our upcoming Juhraya release: XFCE, KDE, Gnome

Give us the usual feedback and let us know what you think about this update.


Current supported Kernels

  • linux316 3.16.67
  • linux318 3.18.140 [EOL] (it is now really EOL!)
  • linux44 4.4.180 (no legacy nvidia-340 module!)
  • linux49 4.9.179
  • linux414 4.14.123
  • linux419 4.19.47
  • linux420 4.20.17 [EOL]
  • linux50 5.0.20
  • linux51 5.1.6
  • linux51 5.2-rc2 (few extramodules build, but not all yet!)
  • linux419-rt 4.19.37_rt20
  • linux50-rt 5.0.14_rt9

Package Updates (Sat Jun 1 07:31:09 CEST 2019)

  • testing core x86_64: 5 new and 5 removed package(s)
  • testing multilib x86_64: 5 new and 5 removed package(s)
  • testing extra x86_64: 20 new and 20 removed package(s)
  • testing community x86_64: 623 new and 614 removed package(s)

Overlay Package Updates

  • testing community x86_64: 6 new and 0 removed package(s)
  • testing core x86_64: 13 new and 13 removed package(s)
  • testing extra x86_64: 98 new and 89 removed package(s)

A list of all package changes made to sync and overlay packages.

  • 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:

7 Likes

Known issues and solutions

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

Small cleanup of Manjaro official repositories

Please note that the following packages got removed from our repositories.

  • chromium-chromevox
  • gimp-gtk3
  • pamac-classic
  • pamac-dev
  • pamac-dev-tray-appindicator

ZFS 0.8 fails to import ZFS pool during boot

As noted by @mbod for testing-update-2019-05-29, it can be permanently fixed
by removing and re-adding the pool's cachefile :

zpool set cachefile=none <name of your pool>
zpool set cachefile=/etc/zfs/zpool.cache <name of your pool>

More details in [Testing Update] 2019-05-29 - Kernels, XFCE, Deepin, Mesa, Nvidia, KDE-Dev (search for 'ZFS' there)


Items from previous update sets

Gnome 3.32: Two extensions removed from our repos.

We have dropped two packages that shipped additional extensions for Gnome: gnome-shell-extensions-topicons-plus-huttli and gnome-shell-extensions-taskbar. We won't maintain Topicons Plus and Taskbar anymore.

Those extensions are not in active development anymore and may not work properly (or not work at all) on Gnome 3.32. Notably, it has been reported that using Topicons Plus on Gnome 3.32 may leads to very high CPU usage.

We strongly recommend you to disable those extensions if they are enabled (Tweaks > Extensions) and remove those packages with your favorite package manager. To prevent potential problems with the next version of Gnome, you may do those steps (or at least the first one) before upgrading your system.

Gnome 3.32: Various problems

There is currently several problems with Gnome 3.32. Here is what we know so far.

1. Possibility of broken extensions
Broken extensions is something to expect when transitioning between major versions of Gnome, especially if you are using extensions that are not shipped by default on Manjaro Gnome. If you have a broken extension taken from somewhere else than Manjaro official repositories, you will have to contact the maintainer on the source you have taken the extension from to get more support. You may also want to report the problem to the developer(s) of the extension (if not the same person/group).

It is possible that extensions become so broken on Gnome 3.32 that it makes Gnome Shell crash completely when trying to log in, thus making Gnome completely unusable. For example, we have a report of such issue with a third-party extension (that doesn't come from Manjaro's official repositories) called Extensions.

To decrease the risk of breakage (especially if running Gnome extensions that does not come from Manjaro official repositories) and make the upgrade smoother, you can disable all Gnome extensions (Tweaks > Extensions) before upgrading your system, then enable them one by one only after being logged in a completely new session on Gnome 3.32.

2. Using world clocks can break Gnome Shell completely
If you have configured world clocks in Gnome, it may make Gnome Shell segfaults and crashes when trying to log in for a graphical session, making Gnome unusable. If it happens, you will need to reset your parameters for world clocks with the following command (do it in TTY): dbus-launch gsettings reset org.gnome.clocks world-clocks.
See this Arch Linux thread and this ticket from upstream.

3. Gnome Shell may crash completely when resuming from sleep if you use Wayland
If you are using Wayland (instead of X.org), Gnome Shell may crash when resuming from sleep. Upstream is aware of this issue. As a workaround, you may use X.org instead of Wayland for now.

4. Miscellaneous
Some programs don't get focused after being launched. Reported to upstream and confirmed for distributions other than Manjaro too.


Yaourt: Rest in peace

Yaourt has been removed from our repositories completely. We won't maintain the yaourt package anymore, which means that you will not receive any updates from us for this package. A very old package named yaourt-gui-manjaro has been removed at the same time too.

If you are still using Yaourt, we strongly encourage you to switch to an alternative like Pamac CLI (package: pamac-cli), Trizen (package: trizen), Yay (package: yay) or Pacaur (package: pacaur); and uninstall Yaourt from your system.

In addition to that, we have dropped support for several packages that depended on yaourt: allservers, pacli and pacli-jwm. Those packages has been removed from the official repositories completely.


vlc-nightly has been dropped

The vlc-nightly package, which was really useful in a time when VLC 3 was not officially out yet, has been dropped on our side and is not in the official repositories anymore. If you still have this package and you want the latest stable version of VLC media player, remove vlc-nightly, then install the vlc package.

Otherwise, you can continue to use vlc-nightly from the AUR (but you'll have to compile it yourself).

Kodi 18.1: extensions may not work properly.

Kodi 18.1 is now available in our repositories. Since this is a major version change, extensions for Kodi (if you use some) may stop working properly. Developers of those extensions will need to make them compatible with Kodi 18.

If Kodi 18.1 doesn't work properly for you and you absolutely need to use your extensions, you may use the old kodi package in /var/cache/pacman/pkg in order to downgrade Kodi to version 17.6. Please note that it is a temporary workaround and that the software provided in the old kodi package may stop working properly in the future too. You should not keep the downgrade forever.

Notifications looking weird in XFCE

Since the package dunst includes now dunstfy in the main package notifications may not displayed properly in XFCE. Please uninstall that package to solve that issue. Normally not needed in that edition.

Plasma will not reboot from the Application Launcher

If you update from within Plasma (e.g. from the konsole), you may need to issue a systemctl reboot to reboot.

I can't open Nemo with elevated privileges (as root)

Workaround found: Use the dbus-x11 package instead of the regular dbus package. This package is available in the official repositories and provides dbus compiled without the --without-x option.

To replace dbus with dbus-x11 package, simply install dbus-x11 with your favorite package manager: dbus will be replaced by dbus-x11.


Pamac: "Failed to commit transaction - Transaction not prepared" at the end

So far, it has only been a false alarm: updates are applied successfully.


AMD-Ucode introduction

Unless you've already done this previously, All users of AMD-APUs/CPUs should install this update like this:

sudo pacman -Syyu
sudo pacman -S amd-ucode
sudo pacman -R intel-ucode
sudo update-grub

Step 3 is optional.


Rebuilding fontconfig cache: failed to write cache

Please ignore this message. Upstream already works on a solution. More about the issue here.


LibreOffice has no window decoration in KDE

New line export SAL_USE_VCLPLUGIN=gtk3_kde5, once merged into existing /etc/profile.d/libreoffice-fresh.sh , fixes a moderately longterm issue. If it doesn't work for you, you may use gtk instead of gtk3_kde5 as UI framework.


Installing glibc (2.28-4) breaks the dependency “glibc=2.27” required by lib32-glibc

Install the update either:

  • from terminal: sudo pacman -Syu or;
  • with Octopi instead of Pamac.

Something using Perl/Python/glibc broke

Rebuilds needed!

  • If it's an AUR package, try to reinstall it from AUR. It most likely needs to be rebuilt.
  • If it's a repo package, please report and check back regularly for updates.

I've lost a Thunderbird addon/feature

Thunderbird 60 disables incompatible addons by default. There's an about:config switch should you want to force-enable the addon, but many addons simply will not work with the newer Quantum-based Thunderbird.

Read more about Thunderbird 60 here: Thunderbird 60


Firefox - WebGL not working anymore

You may try the following solution:

Open about:config and set security.sandbox.content.read_path_whitelist to /sys/.


libutf8proc>=2.1.1-3 update may require manual intervention

This should normally be automatically fixed via manjaro-system update.

The libutf8proc package prior to version 2.1.1-3 had an incorrect soname link. This has been fixed in 2.1.1-3, so the upgrade will need to overwrite the untracked soname link created by ldconfig. If you get an error

libutf8proc: /usr/lib/libutf8proc.so.2 exists in filesystem

when updating, use


pacman -Suy --overwrite usr/lib/libutf8proc.so.2

to perform the upgrade.


Pamac: "Invalid or corrupted package."

If you receive an "Invalid or corrupted package." error message with Pamac and if the details contains an output similar to the following:

Details
Synchronizing package databases...
Starting full system upgrade...

Preparing...
Resolving dependencies...
Checking inter-conflicts...
Downloading...
Downloading manjaro-system-20180716-1-any.pkg.tar.xz...
Checking keyring...
Checking integrity...
Loading packages files...
Checking file conflicts...
Checking available disk space...
Upgrading manjaro-system (20180702-1 -> 20180716-1)...
==> Fix libutf8proc upgrade ...
resolving dependencies...
looking for conflicting packages...

Packages (1) libutf8proc-2.1.1-4

Total Download Size:   0.05 MiB
Total Installed Size:  0.32 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n] 
:: Retrieving packages...
downloading libutf8proc-2.1.1-4-x86_64.pkg.tar.xz...
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
upgrading libutf8proc...
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
Running post-transaction hooks...
Arming ConditionNeedsUpdate...
Warning: lock file missing /var/lib/pacman/db.lck
Starting full system upgrade...
Resolving dependencies...
Checking inter-conflicts...
Error: could not open file /var/lib/pacman/local/libutf8proc-2.1.1-2/files: No such file or directory
Warning: could not fully load metadata for package libutf8proc-2.1.1-2

Failed to prepare transaction:
invalid or corrupted package

Try the following steps: close Pamac window first, then launch it again and start the update procedure again. It should continue from where it left off.


Issues with folder view widget in KDE v5.13

KDE introduced a new setting for icon sizes. Now you're able to define also the size for your panel. If you have a high-DPI display, you may want to increase the value. This will fix the display issue with given widget.

icon-kde-513

Pulseaudio changes

With this update we have a /etc/pulse/default.pa.pacnew. It may be necessary to merge (some lines related to “GSettings” in /etc/pulse/default.pa ) if 'default.pa' has been customised.

File conflict engrampa.tap

thunar-archive-plugin: /usr/lib/xfce4/thunar-archive-plugin/engrampa.tap exists in filesystem (owned by engrampa-thunar-plugin)

thunar-archive-plugin has added native support for the Engrampa archive manager. engrampa-thunar-plugin is no longer needed. Remove engrampa-thunar-plugin to continue with the update.

Octopi seems to have an odd behavior; no longer shows the number/list of available updates in the bottom row as it used too, so it can't display the exact list when clicked, and once the update finishes the update process, the red icon remains active in System Tray till i click Check Updates again.
No other issues noticed so far. Cheers!

The problem is not with me.

Update successfully, after reboot works fine.:+1:
LXQT + AMD free + ext4 +Kernel 5.1
Thanks!

All went well on cinnamon and kernel 5.1

I'll have a look if is something on my end ... Thanks!

Kernels 4.19, 5.1 and now 5.2rc2-experimental* installed and running fine for both my machines.

*desktop only. the notebook won't boot with 5.2rc yet, it's locking up before Xorg is initialised. i'll investigate this further later. 4.19 and 5.1 are fine though.

2 Likes

all good for me: linux419/50+zfs+nvidia+cinnamon

Just updated my ManjaroTesting+FedoraStable VM. Did F first, all ok, then during its reboot i chose M & logged in. Did its update in Konsole via sudo pacman-mirrors -f 7 && sudo pacman -Syyu. Error messages right at the very end of the process but annoyingly i managed to accidentally close Yakuake & lose the output whilst trying to copy it. Decided to install kernel 5.1 before doing the reboot, saw IIRC the same error messages at the end:

Summary
The following packages will be installed:
linux51
linux51-virtualbox-guest-modules

Starting
resolving dependencies...
looking for conflicting packages...
Packages (2) linux51-5.1.6-1  linux51-virtualbox-guest-modules-6.0.8-5
Total Download Size:    77.37 MiB
Total Installed Size:  129.77 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
downloading linux51-5.1.6-1-x86_64.pkg.tar.xz...
downloading linux51-virtualbox-guest-modules-6.0.8-5-x86_64.pkg.tar.xz...
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
installing linux51...
Optional dependencies for linux51
    crda: to set the correct wireless channels of your country [installed]
installing linux51-virtualbox-guest-modules...
===> You may want to load vboxguest, vboxsf and vboxvideo
:: Running post-transaction hooks...
(1/4) Updating linux51 module dependencies...
(2/4) Updating linux51 initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux51.preset: 'default'
-> -k /boot/vmlinuz-5.1-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.1-x86_64.img
==> Starting build: 5.1.6-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
cannot open file au
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.1-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux51.preset: 'fallback'
  -> -k /boot/vmlinuz-5.1-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.1-x86_64-fallback.img -S autodetect
==> Starting build: 5.1.6-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
cannot open file au
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.1-x86_64-fallback.img
==> Image generation successful
(3/4) Updating Grub-Bootmenu
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.1-x86_64.img
Found initrd fallback image: /boot/initramfs-5.1-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.0-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.0-x86_64.img
Found initrd fallback image: /boot/initramfs-5.0-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.156 (2019-03-22) and kernel driver (unknown version).
Command failed.
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.156 (2019-03-22) and kernel driver (unknown version).
Command failed.
Found memtest86+ image: /boot/memtest86+/memtest.bin
done
(4/4) Arming ConditionNeedsUpdate...


Done ...

Apparently oblivious to the maxim that doing the same thing over & over but expecting different outcomes is madness, i chose a manual attempt at updating grub:

Summary
[k@k-VM-ManjaroFedora ~]$ sudo update-grub
[sudo] password for k: 
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.1-x86_64.img
Found initrd fallback image: /boot/initramfs-5.1-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.0-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.0-x86_64.img
Found initrd fallback image: /boot/initramfs-5.0-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.156 (2019-03-22) and kernel driver (unknown version).
Command failed.
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.156 (2019-03-22) and kernel driver (unknown version).
Command failed.
Found memtest86+ image: /boot/memtest86+/memtest.bin
done
[k@k-VM-ManjaroFedora ~]$

I've not attempted to reboot the VM as it seems likely to me it'll end up at a rescue screen. Should i play with trying downgrades of libdevmapper? This error is a new one for me.

You may need to re-check this in Octopi options -> General tab.

Worked fine in Xfce and Cinnamon via terminal.

I didn't get this error this time, but have gotten it occasionally in the past (real hardware, I don't have a VM). Being the novice that I am, I assumed it was because the kernel had been upgraded. I just rebooted and moved on in ignorant bliss with no ill effects.

I too had problems with Octopi. It would not run the update in a terminal. A terminal window opened, my sudo password was asked and when I typed it in the terminal window showed nothing. It just sat there empty. I killed the process, opened a TTY2 session and upgraded from there using pacman. The Octopi notifier went away as it should when I rebooted.

I have the same problem. It opened xterm instead of konsole. I tried to change it back in Octopi but it says that there are some information missing:
Symbol-Pfad Informationen sind unvollständig.
Don't know yet what to do now.

I have found one issue that I do not know if it came with this update or earlier this week:
pacman-mirrors now demand superuser. sudo no longer work, I have to be root to generate the mirror list.

Are you sure? I just did on a fresh install of the latest testing ISO to a brand new SSD yesterday, and did my usual:
sudo pacman-mirrors --geoip

Edit to add: As usual, at install time, I check the box to use same password as the root password.

Can't reproduce on my side: I can launch pacman-mirrors with sudo correctly.

[awesome@i56400 ~]$ date
Sat Jun  1 17:06:06 EDT 2019
[awesome@i56400 ~]$ sudo pacman-mirrors -f 3
[sudo] password for awesome: 
::INFO Downloading mirrors from repo.manjaro.org
::INFO Using custom mirror file
::INFO Querying mirrors - This may take some time
  1.196 United_States  : https://mirrors.ocf.berkeley.edu/manjaro/
  1.186 United_States  : https://mirror.math.princeton.edu/pub/manjaro/
  1.338 United_States  : http://distro.ibiblio.org/manjaro/
::INFO Writing mirror list
::United_States   : https://mirror.math.princeton.edu/pub/manjaro/testing/$repo/$a
::United_States   : https://mirrors.ocf.berkeley.edu/manjaro/testing/$repo/$arch
::United_States   : http://distro.ibiblio.org/manjaro/testing/$repo/$arch
::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist
[awesome@i56400 ~]$ sudo pacman -Syyu
:: Synchronizing package databases...
 core                     151.7 KiB   203K/s 00:01 [######################] 100%
 extra                   1811.0 KiB   302K/s 00:06 [######################] 100%
 community                  5.2 MiB   313K/s 00:17 [######################] 100%
 multilib                 184.0 KiB   526K/s 00:00 [######################] 100%
 DEB_Arch_Extra             4.2 KiB  0.00B/s 00:00 [######################] 100%
 DEB_Arch_Extra.sig       280.0   B  0.00B/s 00:00 [######################] 100%
:: Starting full system upgrade...
 there is nothing to do
[awesome@i56400 ~]$ pacman -Q pacman-mirrors
pacman-mirrors 4.14.2-1
[awesome@i56400 ~]$ 

Let's see if others have a similar issue.

No issues here on Deepin unstable.

::INFO Downloading mirrors from repo.manjaro.org
::INFO User generated mirror list
::------------------------------------------------------------
::INFO Custom mirror file saved: /var/lib/pacman-mirrors/custom-mirrors.json
::INFO Using default mirror file
::INFO Querying mirrors - This may take some time
  1.066 United_States  : https://repo.ialab.dsu.edu/manjaro/
  0.605 United_States  : http://repo.ialab.dsu.edu/manjaro/
  1.120 United_States  : https://mirrors.ocf.berkeley.edu/manjaro/
  0.803 United_States  : https://mirror.math.princeton.edu/pub/manjaro/
  0.407 United_States  : https://mirrors.gigenet.com/manjaro/
  0.485 United_States  : http://mirrors.gigenet.com/manjaro/
::INFO Writing mirror list
::United_States   : https://mirrors.gigenet.com/manjaro/unstable
::United_States   : https://repo.ialab.dsu.edu/manjaro/unstable
::United_States   : https://mirror.math.princeton.edu/pub/manjaro/unstable
::United_States   : https://mirrors.ocf.berkeley.edu/manjaro/unstable
::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist

::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist
::INFO To reset custom mirrorlist 'sudo pacman-mirrors -id'
::INFO To remove custom config run 'sudo pacman-mirrors -c all'
error: you cannot perform this operation unless you are root.

See the last line? Apparently I cannot save changes the mirror list even as sudo. I do not get the error if I switch to su.

EDIT: Booting into my Xfce install. Same issue (also Testing). HOWEVER: Actually looking at the mirror list it seems to all be there. So it's one of the other commands that pacman-mirrors run that generates the error, but the end result looks correct. Weird.

EDIT again: I missed the sudo in the pacman -Syyu bit. Because stupid. Never mind me.

Ta. I slept on it, saw no additional thoughts herein [nor had i any], so grit my teeth & initiated the reboot of that VM, fearing the worst. No rescue screen, but no boot menu either, just straight into Manjaro [which itself is fine as usual]. Therein, i repeated the grub update, & happily this time, it worked correctly/fully, finding my Fedora 2nd-boot [which per my earlier post, had failed before]:

Summary
[k@k-VM-ManjaroFedora ~]$ sudo update-grub
[sudo] password for k: 
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.1-x86_64.img
Found initrd fallback image: /boot/initramfs-5.1-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.0-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.0-x86_64.img
Found initrd fallback image: /boot/initramfs-5.0-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
Found Fedora 30 (Thirty) on /dev/sdb2
Found memtest86+ image: /boot/memtest86+/memtest.bin
done
[k@k-VM-ManjaroFedora ~]$ 

Did another VM reboot, & indeed now have the full boot menu back. Phew.

Given this VM was the dual-boot testbed i established weeks ago prior to then successfully deploying in Tower for real, this VM's update hiccup alarmed me & made me hold back from doing the update in real Tower. Now it seems i can proceed...


Additional info [irrelevant for all Manjaroos unless also using Fedora30, but provided fyi].

Upon reflection, i now strongly suspect that this storm in my teacup was caused by --surprise surprise-- my own usual ham-fisted incompetence. Unlike the magnificent Manjaro kernel update/install process that automatically includes the update-grub routine, in F30 when one installs a new kernel, one must remember afterwards to manually run the update command, before rebooting, otherwise said new kernel/s remain invisible in the boot menu. Furthermore, the choice of specific command is dependent on whether one's F30 installation was UEFI or legacy. In the case of my VM, last night i muddled myself & mistakenly ran the F30 command for UEFI, when in fact i should have done the GRUB2 one. Ie, last night i ran sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg, whereas this morning i corrected my error via sudo grub2-mkconfig -o /boot/grub2/grub.cfg.

Such a silly sausage.

3 Likes