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

Hello
so according to the announcement,i install this update(Pamac GUI for my part),and then in a terminal grub-install and then restart?

and what about sudo update grub ?

1 Like

On my other test bench, Iā€™ve updated without using grub install.
Everything seems to work though, since it already detected and rebuild booting images.

1 Like

The package rog-control-center from the stable extra repo contains conflicting/duplicate files from asusctl (dependency for rog-control-center).
Conflicting:

/usr/bin/rog-control-center exists in both asusctl and rog-control-center
/usr/share/applications/rog-control-center.desktop exists in both asusctl and rog-control-center
/usr/share/icons/hicolor/512x512/apps/rog-control-center.png exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/fa506i_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/fa507_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/fx505d_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g512_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g513i-per-key_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g513i_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g533q-per-key_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g533q_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g634j-per-key_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g733pz-per-key_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/g814ji-per-key_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/ga401q_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/gl503_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/gx502_US.ron exists in both asusctl and rog-control-center
/usr/share/rog-gui/layouts/gx531-per-key_US.ron exists in both asusctl and rog-control-center

Current workaround: Build rog-control-center and asusctl from AUR and ignore suggested update/change to the packaged versions from stable extra repo for now. Currently both repos contain the same version afaik.

Still, thanks for the update and cheers!

I have a similar question - Sorry the instructions under https://wiki.manjaro.org/index.php/GRUB/Restore_the_GRUB_Bootloader/en#Reinstall_GRUB are not very clear.

My hard-drive is partitioned as shown in the screenshot. What commands should I use to reinstall grub after completing the system upgrade and before restarting the laptop?

1 Like

@iCEVooDoo i used the full command. Today was my update day, updated the bios so i had to (again turn off secure boot) and reinstall grub and the efi variables anyway.

@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
3 Likes

In manjaro setting manager > kernel

The 6.6 kernel doesnā€™t show LTS and Recommended tags anymore

3 Likes

I have done now the upgrade and used the second option from my post and seems everything ok now.

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

sudo grub-mkconfig -o /boot/grub/grub.cfg 
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.

Done some checks using this 2 commands also and all ok.

pamac info grub
sudo bootctl status

After the update Iā€™ve used the two commands recommended by Wollie above.
Then restarted and GRUB failed to boot with ā€œgrub is shim lock enabledā€ error. I had to change the boot order in the BIOS to get it boot again.

2 Likes

12/26/2023
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.

$  lsblk -o PATH,PTTYPE,PARTTYPE,FSTYPE,PARTTYPENAME 
PATH           PTTYPE PARTTYPE FSTYPE PARTTYPENAME
/dev/sda       dos                    
/dev/sda1      dos    0x7      ntfs   HPFS/NTFS/exFAT
/dev/sr0                              
/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.

13 Likes

@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.

2 Likes

Hello,
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.

4 Likes

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.

2 Likes

Thank you REley!!!

1 Like