[Stable Update] 2023-12-23 - Kernels, Grub, Mate, Deepin, Cinnamon, ICU, KDE Frameworks

Ok, this is a little weird. The forum tells me I cannot add another post here, and that I must edit my original one. So here goes…

Hello PhilM,

Thank you so much for all this clarification. It is much appreciated!

Can you clue me in some more about this? I would like like to add some of the information from my first comment in this thread onto that GRUB wiki.

I’ll be looking forward to using the package install-grub when it hits stable. So thank you so much for this. I don’t have the skills to bug check, and don’t want to deal with potential instabilities.

My previous post below:

The issue for me here is poor documentation, and the fact that we as users have to manually intervene for an update for what is supposed to be an easy Linux distribution. Not all of us are experts in Linux that know everything inside out. While I can research and eventually figure out what needs to be done, there will be other less experienced users that will switch Linux distributions because Manjaro broke on an update. Most users don’t even know about these update announcements in the forums here and how necessary they are to read before doing major updates.

Was there really no other way to automate the GRUB update so that user intervention would not be necessary?

As grub is now at 2.12, before restarting your system, it is advised to run grub-install to ensure all parts of grub is up-to-date. See our wiki for more details: GRUB/Restore the GRUB Bootloader - Manjaro

This above message is not detailed enough. My initial take on it, was that the terminal command “grub-install” was all that was required. Had I done that I probably would have broken my system. I’d suggest adding: “sudo grub-install” plus the necessary variables after it needed, depending on whether GRUB is using a EFI or BIOS system.

Then there is the terrible documentation in the Manjaro GRUB/Restore the GRUB Bootloader. Again, had I assumed my system was EFI, I would have broken it. Thankfully I knew better to double check everything, though that required a good bit of research. Not everyone is going to know what type of system they have for GRUB and how it was previously installed.

Under the “Identify partitions” section, those two commands did not give me the information I needed to understand what system I had installed. Below is the output from those two commands for my computer.

/dev/sda       dos                    
/dev/sda1      dos    0x7      ntfs   HPFS/NTFS/exFAT
/dev/nvme0n1   dos                    
/dev/nvme0n1p1 dos    0x83     ext4   Linux

$ sudo fdisk -l
[sudo] password for main: 
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM001-1ER1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe8898b2d

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3907028991 3907026944  1.8T  7 HPFS/NTFS/exFAT

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Sabrent Rocket Q                        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9e98d4aa

Device         Boot Start        End    Sectors  Size Id Type
/dev/nvme0n1p1 *     2048 3907024064 3907022017  1.8T 83 Linux

The below quote is from this same link and section about identifying partitions for GRUB.

The clues to look for is mbr vs. gpt and the presence of a small partition - usually the first - formatted with the vfat filesystem followed by a larger partition formatted as ext4.

I don’t see anything in the output of those two commands that matches up with the above quote.

What I did know, from the initial install of Manjaro XFCE, is that I installed it on my NVME SSD drive, that the boot loader went on that same drive, and secure boot is disabled. Again though, my motherboard is new enough at 2015, that I knew it has UEFI/EFI. Then why was I not seeing a small partition formatted with VFAT?

The asterisk under Boot section for /dev/nvme0n1 confirms the system boots from that drive.

What I had to do was get into the GRUB command line area to figure out which boot system I have. For those that only have Manjaro installed, such that GRUB defaults to not showing before booting:

1. Restart Manjaro and press the ESC key a bunch of times as the UEFI or BIOS is finishing up and before Manjaro boots. This will bring up the GRUB screen.

2. Press the C key to enter the command line mode.

3. Type in the command echo $grub_platform
If it shows PC, you have a BIOS install, if it shows EFI you have a EFI install.
Link: GNU GRUB Manual 2.12

4. Type in exit to end the session, and Manjaro will boot automatically.

Now there is a bit more subtlety to this. As the above command showed PC for my computer. I could not understand why a modern UEFI/EFI motherboard would have GRUB using a BIOS install. Looking into my Asus Z-170a motherboard manual, I found a section in the boot area called CSM (Compatibility Support Module). And the choice language and description is as vague and hard to understand as old motherboard BIOS settings always have been. I left it to what it was defaulted to when I first got the system, but disabled secure boot.

Turns out this setting controls whether the boot system uses EFI or BIOS. Mine is set to “enabled”, and a sub-setting of “Boot Devices Control [UEFI and Legacy OPROM]”. There are two other options for “[Legacy OPROM only]” and “[UEFI only]”. Either GRUB, or Manjaro Linux chose to use the BIOS method automatically out of those two choices the UEFI offered during the operating system install.

As a real life example, I’m going to list the exact terminal commands I used after the update installed, but before restarting the system. Please be advised that you should NOT use these! They are specific to my system, and GRUB using the PC boot setting. If you know for sure GRUB is using the PC setting for booting, then just alter the drive name after /dev/ to what yours is. As the instructions say, the device is the disk (not a partition).

sudo grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/nvme0n1

Then run:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Then restart Manjaro Linux and you are done.

I had no issues after doing all this. Though it took me several hours of research and double checking to make sure I understood everything, and had all the information needed.

If GRUB uses EFI to boot from, you likely have it easier, as no devices need to be specified. Though this is not from experience on my end, just observation of the commands in the GRUB/Restore the GRUB Bootloader documentation. It appears that you can just put sudo in front of the grub-install and the grub-mkconfig they have listed in the “EFI System” section, and it should work.


@quiet-pengiun, as you seem to have booted in EFI mode:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
sudo grub-mkconfig -o /boot/grub/grub.cfg

Perfect! Upgrade, grub-reinstall and reboot successful without any problems.

1 Like

Hello, I did the same thing, I also had to change the boot order in the EFI-Bios. I didn’t have an error message, it didn’t start Manjaro or Windows.
And now it shows the correct grub-version when booting. :+1: :blush:

EDIT: Fixed with manajro-cinnamon-settings 20231225-1.

Fixed with 5.0.3-2.


Is this normal with Audacious?
Audacious doesn’t work with PipeWire output: “Error opening output stream”…

3 posts were merged into an existing topic: Problem with quiterss: libicui18n.so.73 not found

Thanks for this. Now I don’t want to update. :grimacing:

A few months ago I suffered through a GRUB nightmare with Manjaro and could never recover. I encrypted my NVME drive and it had to be unlocked before boot. Given that scenario, the instructions on rebuilding GRUB were, in my view, entirely inadequate. I ended up rebuilding the machine. Yes I know I should have had a recent backup at hand. :slight_smile:

Would love to know the correct procedure for my setup before I do this upgrade. I love Manjaro, but man this kind of thing can quickly kill so much joy.


The immortals are mere good with mortals… :smile:

Maybe we edit some commands into the announcemnt to run after update, before the reboot? Such that everyone should be on the safe side, with mbr/gpt/luks/btrfs/legacy-boot/efi… ?
Put how to put them together? From my mind I’d run sudo grub-install followed by sudo update-grub?
Please assist…
Would it be of help to run them before the update?

Go to: File/Settings and click on the Audio Tab.

Change Output plugin to ALSA Output.


Thank you REley!!!

1 Like

I’m also facing issues on update. Something seems broken on initfrs. I’m completely clueless.

in my opinion, there is no way this should have been labeled as a “stable” update

i agree with purplemunchies - the grub check should have been handled much better than it was, at least with a script to check the config before rebooting or something

i use EFI and followed the instructions in the announcement, running the following…

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
sudo grub-mkconfig -o /boot/grub/grub.cfg

and the system wouldn’t boot until i messed with the boot order in setup

it was always set to UEFI OS on the SSD, but this now fails, so i changed it to the only other option “manjaro” and that works, but i came across this fix largely by dumb luck

this should not have happened


I did the update with MBR (UEFI/Secure Boot disabled) on both of my systems and no problems, im not even manually updated my grub bootloader as @philm suggest in know issue, because i updated 40min after Philm uploaded the stable update and at this time the know issue was empty.

But i still have no idea if i still should force this reinstall now…

At the endof the day its not a requirement to manually update…
its only advised.
I do the easy Linux way and just created a simply timeshift backup on a external hdd and have a Manjaro USB Stick ready if anything goes wrong… its not this hard to be prepare.

On the vote for this update, I chose:

The issue could be much more severe but I was lucky this time so the issue ended up basically a mental shock and some extra effort on investigation. What do I mean?

For the past some updates, I normally just re-book at the prompt after installing the update. But this time something told me to check about the known issues post on this update. Thanks for the note on grub update! So if I re-booted as usual, I might have ended up with trouble.

But the instruction plus the so-called details on grub update were not too clear. Do I have BIOS/GPT (or chatGPT?) or do I have EFI? Sure, I knew that long ago when I installed Manjaro, but now I totally forgot, and I don’t even remember on how to find out. After some searching and reading, I found out with:

$ sudo fdisk -l
Device         Start       End   Sectors   Size Type
/dev/sda1         34   2050047   2050014  1001M EFI System
/dev/sda2  104450048 124930047  20480000   9.8G Linux swap
/dev/sda3    2050048 104450047 102400000  48.8G Linux filesystem
/dev/sda4  124930048 490234718 365304671 174.2G Linux filesystem

After seeing “EFI System” above, I made a bet (yes!) to go with EFI approach. But the problem is hardly solved. The detailed info page says:

EFI System
Info You need to be in chroot for this procedure.

Reinstall grub

root # grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck COPY TO CLIPBOARD

Update the grub configuration

root # grub-mkconfig -o /boot/grub/grub.cfg COPY TO CLIPBOARD

First question was: how to be in chroot? After some checking, it turns out I could just use sudo. But then there are two things listed above. Should I do one or the other, or should I do both? Again some further searching and reading.

So I did both. Then rebooted. There is no problem so far. But you see this is not a smooth update.


Copying a file in Thunar (in Xfce) to a cifs-mounted Windows location fails.

Dating the problem: 1. As of the “2023-12-13” update, the problem did not exist. 2. After the “2023-12-15” update, the problem does exist. 3. The “2023-12-23” update does not fix the problem.

I posted to support: Copying in Thunar to cifs-mounted Windows locations fails (after update)

Sorry if this reply duplicates anything or is not in proper format. First time replying to a Stable Update post.

There have been a number of updates recently so I do not know precisely when my my menubar disappeared from the application launcher button (Manjaro start button) and I can’t identify the place/app/setting to turn it back on.

6.1.69-1-MANJARO (64-bit) Kernel / KDE Plasma 5.27.10

Hi @Nicomo
Try right-clicking and selecting ‘Show Alternatives’; Choose another menu layout, and confirm it. Using this same procedure to again select your original menu layout may (or may not) fix that. It’s worth trying, anyway. Cheers.

Thank you very much for your quick response, the alternatives are interesting but they also seem to have an issue in list view - in that there is no highlighting menubar to show which application(menu_item) your mouse is hovering over.

The whole grub thing is actually strongly recommended to avoid future problems and not really necessary right now. If you are up to date, your grub should be at 2.12rc and the update bumps it to 2.12 final. There seem not to be any breaking changes…because i honestly forgot to update the first stage and rebooted just fine.
And BTW, if you update the grub efi part using chroot/usb live session, make sure to use the 2023-12-23 iso from yesterday, because it is the first to use that version.

Also, to check the grub first stage version, on the grub menu, hit c for command prompt - the version appears at the top. Then hit esc to go back.