GRUB Boot-Time Error and No Graphical GRUB Menu after Stable Update of 2020.07.19

Ever since the [Stable] update of 2020.07.19, I am now seeing two problems with GRUB, i.e.:

1. I get an error message ─ repeated several times ─ at boot, reading...

Compression type 0x3 not supported.

... followed by...

Press any key to continue...

I don't necessarily have to press a key, because there's an obvious timeout on it, and it'll proceed to the next step ─ the GRUB menu ─ after a few seconds anyway.

2. I am no longer getting the graphical GRUB menu, but instead I am getting the fallback text-mode GRUB menu.

Another forum member commented on the update announcement thread about a similar problem ─ see post below ─ albeit that this person has an NVIDIA graphics adapter, whereas I only have an on-board Intel graphics chipset. :arrow_down:

I have followed the advice given by the poster quoted above, but with the exception of the display resolution at boot now being more high-res than the original 640-480 VGA resolution, the problem persists. I am still seeing the same error message, and I am still getting the fallback text-mode GRUB menu.

I have also removed the word auto from the GRUB_GFXMODE in/etc/default/grub (and updated GRUB again), but it doesn't make any difference.

Below is my /etc/default/grub. :arrow_down:

GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR='Manjaro'
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.
GRUB_SAVEDEFAULT=true

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=1920x1080x32

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/usr/share/grub/background.png"
GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

My machine... :arrow_down:

System:    Host: nx-74205 Kernel: 5.4.52-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.1.0 
           parameters: BOOT_IMAGE=/vmlinuz-5.4-x86_64 root=UUID=3f1852bc-be95-4e42-8d46-25bafac4ce79 rw rootflags=subvol=@ 
           quiet 
           Desktop: KDE Plasma 5.19.3 tk: Qt 5.15.0 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: Micro-Star model: H310M PRO-VDH PLUS (MS-7C09) v: 1.0 serial: <filter> 
           UEFI: American Megatrends v: 1.10 date: 11/12/2018 
CPU:       Topology: 6-Core model: Intel Core i5-8400 bits: 64 type: MCP arch: Kaby Lake family: 6 model-id: 9E (158) 
           stepping: A (10) microcode: D6 L2 cache: 9216 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 33613 
           Speed: 833 MHz min/max: 800/4000 MHz Core speeds (MHz): 1: 833 2: 822 3: 988 4: 970 5: 805 6: 934 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled 
           Type: mds mitigation: Clear CPU buffers; SMT disabled 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling 
           Type: srbds mitigation: Microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel UHD Graphics 630 vendor: Micro-Star MSI driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:3e92 
           Display: x11 server: X.Org 1.20.8 driver: intel unloaded: modesetting alternate: fbdev,vesa compositor: kwin_x11 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 20.1.3 direct render: Yes 
Audio:     Device-1: Intel 200 Series PCH HD Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           chip ID: 8086:a2f0 
           Sound Server: ALSA v: k5.4.52-1-MANJARO 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Micro-Star MSI driver: r8168 
           v: 8.048.03-NAPI port: e000 bus ID: 01:00.0 chip ID: 10ec:8168 
           IF: enp1s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 1.59 TiB used: 77.21 GiB (4.7%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 QVO 1TB size: 931.51 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: GPT 
           ID-2: /dev/sdb vendor: MDT (rebuilt WD/Seagate) model: MD7500AAVS-00D7B0 size: 698.64 GiB block size: 
           physical: 512 B logical: 512 B speed: 3.0 Gb/s serial: <filter> rev: 1A01 scheme: GPT 
Partition: ID-1: / raw size: 1024.0 MiB size: 1024.0 MiB (100.00%) used: 26.4 MiB (2.6%) fs: btrfs dev: /dev/sda3 
           ID-2: /boot raw size: 512.0 MiB size: 487.9 MiB (95.30%) used: 60.0 MiB (12.3%) fs: ext4 dev: /dev/sda2 
           ID-3: /home raw size: 450.00 GiB size: 450.00 GiB (100.00%) used: 2.46 GiB (0.5%) fs: btrfs dev: /dev/sda9 
           ID-4: /opt raw size: 2.00 GiB size: 2.00 GiB (100.00%) used: 98.4 MiB (4.8%) fs: btrfs dev: /dev/sda6 
           ID-5: /usr raw size: 22.00 GiB size: 22.00 GiB (100.00%) used: 6.29 GiB (28.6%) fs: btrfs dev: /dev/sda4 
           ID-6: /var raw size: 20.00 GiB size: 20.00 GiB (100.00%) used: 3.29 GiB (16.5%) fs: btrfs dev: /dev/sda11 
Sensors:   System Temperatures: cpu: 34.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 351 Uptime: 45m Memory: 15.51 GiB used: 1.95 GiB (12.6%) Init: systemd v: 245 Compilers: gcc: 10.1.0 
           clang: 10.0.0 Shell: bash v: 5.0.18 running in: konsole inxi: 3.0.37

By the way, even though GRUB supports the MS-DOS partition table format, this is a UEFI-only system with a GPT partition table format.

The system is installed on a 1 TB SSD, and there are no other operating systems installed on this machine. I am also not getting any errors when running update-grub.

I am wondering however, could the error about the unsupported compression have anything to do with the initramfs or the kernel image? :thinking:

Here is a similar case and a suggestion for a solution:

Have you tried to re-install grub?

This looks to be very short, some entries lost here?

Why not setting to

GRUB_GFXMODE=auto
1 Like

Yes, but that doesn't apply. I do use btrfs for most of my partitions, but my /boot filesystem is ext4. :arrow_down:

[nx-74205:/dev/pts/3][/home/aragorn]
[19:27:36][aragorn] >  df -T | grep sda
/dev/sda3      btrfs     1.0G   27M  767M   4% /
/dev/sda4      btrfs      22G  6.3G   15G  30% /usr
/dev/sda9      btrfs     450G  2.5G  446G   1% /home
/dev/sda6      btrfs     2.0G   99M  1.7G   6% /opt
/dev/sda5      btrfs     512M  3.4M  499M   1% /usr/local
/dev/sda11     btrfs      20G  3.4G   17G  18% /var
/dev/sda8      btrfs     400G   65G  335G  17% /srv
/dev/sda2      ext4      488M   61M  393M  14% /boot
/dev/sda1      vfat      511M  280K  511M   1% /boot/efi

No, I haven't done that yet, but isn't that supposed to happen automatically during an update when GRUB is one of the updated packages?

I have removed the resume= line, because systemd kept on mounting my swap partition, even though I had disabled that in /etc/fstab.

Because that is broken, as reported by that user who posted on the update announcement thread ─ see the link I included higher up.

It was originally set to auto, but that gave me the same fallback text-mode menu, only with a lower resolution than it has now.

https://askubuntu.com/questions/1056396/compression-type-0x3-not-supported

https://wiki.archlinux.org/index.php/Btrfs#Compression

1 Like

Yep yep, except ─ see higher up ─ that my /boot is on a separate ext4 partition, and my use of zstd on my btrfs partitions isn't anything recent. I've already done that months ago, and I never had any problems with it before.

I can only surmise that the GRUB package in this latest 2020.07.19 update must be broken. :frowning:

Since the message is before image start (via grub), No.

No.
But... even if intended, your $esp might not be mounted (as in inxi report). Isn't it in fstab? It should be, or create a mount unit. :stuck_out_tongue:

1 Like

It is mounted, as you can see in what I pasted earlier... :arrow_down:

Note: inxi doesn't report all of the filesystems in use. It only reports the most pertinent ones.

I had already come to realize this as well. And the strange thing is that GRUB doesn't even have to touch the root filesystem, or any of the others. But the compression-related error message shows up many times ─ on separate lines ─ which leads me to suspect that it is indeed complaining about all of my btrfs partitions.

And that's why GRUB must be broken. It doesn't have to look at any other partitions except for /boot ─ which, ironically, isn't even a btrfs filesystem ─ and up until this update, it never did.

Furthermore, the fallback text-mode menu is also new as of this update. I used to have a nice graphical menu with a Manjaro wallpaper.

:man_shrugging:

1 Like

Yep. We know. My point was to verify it's in fstab or as mount unit, for systemd to discover when needed.

As you suspect, either new or old grub might be the issue.

Reinstall grub to $esp (give a new name label).
If the new grub@$esp fails, maybe downgrade grub, if it was included in last update.

What does your /etc/fstab look like? Just asking. Since you can control how btrfs compression as fstab is being used as it being mounted.

Just a bare bone example for fstab root:

UUID=blablabla  /  btrfs  defaults,compress=lzo   0   1
1 Like

Guys... I appreciate it ─ really, I do ─ but there is nothing wrong with my btrfs setup, and I've already mentioned this several times now.

  • Yes, I do have multiple partitions because I install and maintain my system as a multiuser UNIX workstation, not as some kind of twisted version of Microsoft Windows.

These are my partitions... :arrow_down:

[nx-74205:/dev/pts/3][/home/aragorn]
[04:08:51][aragorn] >  df -T | grep sda | sort
/dev/sda11     btrfs      20G  3.4G   17G  18% /var
/dev/sda1      vfat      511M  280K  511M   1% /boot/efi
/dev/sda2      ext4      488M   61M  393M  14% /boot
/dev/sda3      btrfs     1.0G   27M  767M   4% /
/dev/sda4      btrfs      22G  6.3G   15G  30% /usr
/dev/sda5      btrfs     512M  3.4M  499M   1% /usr/local
/dev/sda6      btrfs     2.0G   99M  1.7G   6% /opt
/dev/sda8      btrfs     400G   65G  335G  17% /srv
/dev/sda9      btrfs     450G  2.5G  446G   1% /home

/dev/sda is an SATA3-connected 2.5" 1 GB Samsung SSD. I also have an older 750 GB HDD in this machine ─ still SATA2, because it came out of an earlier computer I had ─ which contains an additional swap partition and a large btrfs partition that I exclusively use for storing backups. This partition is automatically mounted when I run timeshift, but is otherwise left unmounted.

Neither the 10 GiB swap partition on the SSD nor the 20 GiB one on the HDD are currently active, but they are there just in case I'd ever need them ─ this machine originally came with 8 GiB of RAM installed, and back then I still needed a swap partition, but I have upgraded the RAM capacity to 16 GiB in October 2019 and now I no longer need any swap.

I could post my /etc/fstab ─ and I will, below the next paragraph ─ but it will probably freak out a number of you because I normally have several of my partitions mounted read-only.

I do however remount all of the pertinent partitions in read/write mode before running an update, and before installing software from the repo or from the AUR. I am very conscientious about that. I've been an exclusive GNU/Linux user for over 20 years already, and I also had prior experience with proprietary UNIX.

[nx-74205:/dev/pts/3][/home/aragorn]
[04:09:15][aragorn] >  cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
#
# <file system>                                 <mount point>  <type>   <options>                                                                                               <dump>  <pass>
#
UUID=CEF6-EF5C                                  /boot/efi       vfat    ro,defaults,noatime,nodiratime,sync,nodev                                                               0       0
UUID=924f11d8-4bec-49a6-852e-033ce5e3d6a3       /boot           ext4    ro,defaults,noatime,nodiratime,sync,nodev                                                               0       0
UUID=3f1852bc-be95-4e42-8d46-25bafac4ce79       /               btrfs   ssd,subvol=@,defaults,noatime,nodiratime,space_cache,sync,compress=zstd,nodev                           0       0
UUID=8de45432-efe5-4d76-beb9-fcb3247a063e       /usr            btrfs   ssd,ro,defaults,noatime,nodiratime,space_cache,sync,compress=zstd,nodev                                 0       0
UUID=8462b14d-4a97-4383-a55d-61fcd136aeb9       /usr/local      btrfs   ssd,defaults,noatime,nodiratime,space_cache,compress=zstd,nodev                                         0       0
UUID=6e756bf9-2d7c-401a-a0f3-bb4ea3b824a9       /opt            btrfs   ssd,ro,defaults,noatime,nodiratime,space_cache,sync,compress=zstd,nodev                                 0       0
UUID=e3fe76c9-8dea-4a27-8f47-839bb464f022       /srv            btrfs   ssd,defaults,noatime,nodiratime,space_cache,compress=zstd,nodev                                         0       0
UUID=db2385c9-2715-408e-96b4-52086a0292fe       /home           btrfs   ssd,defaults,noatime,nodiratime,space_cache,compress=zstd,nodev                                         0       0
# UUID=6fbd221f-5d46-40f0-9fbf-4479d73874b4     swap            swap    ssd,defaults,discard=pages                                                                              0       0
UUID=bdf6a9f6-a2a7-47a0-ba6f-7bbf71a01a95       /var            btrfs   ssd,defaults,noatime,nodiratime,space_cache,compress=zstd,nodev                                         0       0

# Below is the old /var partition, which proved too small.
# UUID=6d475769-c92c-4935-b2af-a53d29dcd898     /var            btrfs   ssd,defaults,noatime,space_cache,compress=lzo                                                           0       0

# Below is the root subvolume of a btrfs filesystem on the MDT HDD, which is used exclusively for backups.
LABEL=mdt-btrfs                                 /srv/backups    btrfs   noauto,nofail,defaults,space_cache,autodefrag,compress=zstd,nodev,noexec                                0       0

As you can see, I have a separate /boot partition, and it is formatted as ext4. And that's all GRUB should concern itself with. GRUB doesn't need to read my btrfs partitions, and yet it attempts to do so nevertheless. It has never done this before.

  • I have reinstalled GRUB, and it makes no difference, neither with regard to the error messages regarding unsupported compression, nor with regard to the GFX menu.

  • I cannot downgrade to an earlier version because I no longer have the package for the old GRUB. I have emptied my package cache so as to leave more room on my /var partition.

At this point, I think the only thing I can still do is send a private message to @philm and point him at this thread. There is obviously a problem with this latest GRUB update. I don't know what, because I'm not a coder.

:man_shrugging:

1 Like

If you have mounted /boot and /boot/efi as read only how the updating process could write something here?

If grub is really the problem you could try grub-vanilla.

1 Like

As I have stated, I remount them as read/write before applying updates, and likewise for /opt and /usr.

I was thinking about that, but I'm not sure on how it differs from Manjaro's GRUB. :thinking:

I use it as it was recommended by @gohlip some months ago. I would make a timeshift snapshot and try it. In testing grub-vanilla is freshyly updated by @jonathon.

1 Like

Well, it's an option I'm keeping open, but I've contacted @philm now, and I'll see what he thinks of it first before replacing Manjaro's GRUB with grub-vanilla. :thinking:

2 Likes

For this to work, grub needs rw access to /boot/grub/grubenv at boot time

$ grep saved /boot/grub/grubenv 
saved_entry=gnulinux-linux-advanced-75579b14-xxxxxxxxxxxxxxx

I wonder why this wasn't present before you notice it...
If grub could write in grubenv at boot before, it should be capable to after...

You might want to test with

GRUB_DEFAULT=0 # 0 for 1st menu entry, 1 for 2nd etc.

Also, it is safe to use grub-vanilla. Manjaro grub is heavily modified. Have you searched for similar issues at Arch forum or DDG?

Have in mind that grub.cfg includes several search commands to find partitions, even if UUIDs are already known and given at update-grub time.
It could be that it tries to read btrfs partitions and fails and it does what it does, but all are assumptions.

Could you check/post this to see timestamp

ls -l  /boot/grub/grubenv 

Yes, but GRUB is capable of mounting filesystems. That's how it works ─ as opposed to LILO, which used hard-coded block offsets to load the kernel image and initramfs.

So GRUB is effectively mounting the /boot partition at boot time, and that is a read/write mount. It is only afterwards ─ when the kernel has been loaded and the system initiates userspace ─ that /boot gets mounted by the kernel in ─ in my case ─ read-only mode.

[nx-74205:/dev/pts/3][/home/aragorn]
[20:36:41][aragorn] > grep saved /boot/grub/grubenv
saved_entry=gnulinux-simple-3f1852bc-be95-4e42-8d46-25bafac4ce79

But it isn't really necessary to have write access to /boot. I only have one kernel installed ─ I use the 5.4 LTS kernel ─ and all of my filesystems are always mounted as writable during a system update.

No, I haven't, but there was a reported issue with GRUB from another user on the [Stable Update] announcement thread ─ I believe I've linked to it in my original post.

[nx-74205:/dev/pts/3][/home/aragorn]
[20:37:02][aragorn] >  ls -l /boot/grub/grubenv  
-rw-r--r-- 1 root root 1024 Aug  2  2019 /boot/grub/grubenv
1 Like

I am not an expert on how grub functions at runtime and what you say makes sense.
Though, in standard Linux sense, grubenv seems unchanged for a year? But this env is called a special thing from its dev, so maybe it's correct.
As for testing for troubleshooting, it's your system :man_shrugging:.

You have a very elegant super controlled system, I dream to make mine similar.
For taking over control in such cases, I thought you would try some testing :wink:.
Or do it for the rest of us :smile:

1 Like

Thank you. :slight_smile:

Well, that's the problem. This is my only workstation right now ─ my daily driver ─ and I don't want to mess it all up. That's also why I'm remaining on [Stable]. :slight_smile:

1 Like

Well, I've finally solved it, with lots of trial and error. I did have to reinstall GRUB into the ESP, as you suggested, but that is only half of the story.

The other half is that GRUB 2.04 does support zstd, but in order for that to work, the module has to be loaded, and that was not the case. Furthermore ─ and this is important too ─ on a UEFI system, you have to disable the Reed-Solomon error correcting codes.

So I had to do all that, and now everything works. No more errors, and a nice 1920*1080 resolution with the Manjaro theme ─ which is an even higher resolution than it used to have, suggesting that the auto-detection is indeed broken, as that other user also noted and reported on the announcement thread.

Given all of the above, I'm going to be selfish and claim the solution as my own. Still, I want to thank all of you for having responded. Unfortunately, @philm himself has so far ignored my PM to him, and he is the one maintaining Manjaro's GRUB. But in the end, I was able to fix it without his help. :stuck_out_tongue:

3 Likes

Forum kindly sponsored by