The issue takes place with all few last kernels up to 18 (not tried 19 yet)
If I understand correctly, now you can run update-grub successfully and have a proper grub multiboot menu. The (quoted) sequence you mention is the proper one AFAIK.
To be honest I’ve always updated grub upon a reboot after a system upgrade regardless if grub updated properly or not during the upgrade itself simply due to the reboot being necessary for the updates to be applied to the kernel and modules anyway . So it’s really kind of a no issue . I am a gamer and I’ve been dual booting with Windoze 10 and Manjaro for two years without a hitch doing it that way . You may have a lesser incidence of your issue with another kernel but the reboot is still gonna be necessary after a kernel update anyway .
At my case on the NAS with the problem the output is:
~ >>> efibootmgr -v EFI variables are not supported on this system. ~ >>> sudo parted -l [sudo] password for user: Model: ATA SPCC Solid State (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary boot 2 538MB 120GB 119GB primary ext4 Model: ATA WDC WD20EZRZ-00Z (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2000GB 2000GB zfs-26013cea79add312 9 2000GB 2000GB 8389kB Model: ATA WDC WD20EZRZ-00Z (scsi) Disk /dev/sdc: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2000GB 2000GB zfs-d63dca6b21a0ea0a 9 2000GB 2000GB 8389kB ~ >>> sudo blkid /dev/sda1: PARTUUID="f19d5f5e-01" /dev/sda2: UUID="000f5465-0e55-4a44-9836-86d3a5b78b76" TYPE="ext4" PARTUUID="f19d5f5e-02" /dev/sdc1: LABEL="data" UUID="14318109765728649202" UUID_SUB="7571353807103248258" TYPE="zfs_member" PARTLABEL="zfs-d63dca6b21a0ea0a" PARTUUID="b0f661ec-efc3-4443-aa50-a83d3152a2f5" /dev/sdc9: PARTUUID="c873c916-4c31-b445-9637-1b57b5eb84d4" /dev/sdb1: LABEL="data" UUID="14318109765728649202" UUID_SUB="14439258925625876186" TYPE="zfs_member" PARTLABEL="zfs-26013cea79add312" PARTUUID="ab86aef6-2b6b-cc4e-a89e-ae904b1e681a" /dev/sdb9: PARTUUID="619df13f-822b-c54d-aaa4-ee3d062dd004" ~ >>> findmnt -s TARGET SOURCE FSTYPE OPTIONS / UUID=000f5465-0e55-4a44-9836-86d3a5b78b76 ext4 rw,noatime,data=ordered none /swapfile swap defaults ~ >>> ls /boot/efi/EFI/ ls: cannot access '/boot/efi/EFI/': No such file or directory ~ >>>
What does this have to do with this topic?
Please, start another topic for your issue.
There is a ref to Incompatible libdevmapper on update-grub with similar issue. And I’m that topic starter. Do you really checked the ref?
The issue disappears on reboot for the reasons I’ve already stated in my earlier post . It’s simply necessary housekeeping in a dual boot setup . It’s going to be the same regardless of distro , I have to do the same thing with Linux Mint after a kernel update or whatever other distro I have as linux du jour . It is really not an issue .
I could not imagine, I apologize!
Why did you post that boot-related output?
Yours is on msdos and you have Linux Mint and Manjaro.
After a kernel change in Linux Mint, yes, you need to go to Manjaro (the ‘controlling’ grub) to do an ‘update-grub’ to incorporate the new kernel there. The OP’s case is different.
You have mixed gpt and msdos and you’re booting up Manjaro in bios-legacy.
While it is not so much an issue on linux OS’s grub (with newer kernels), it will be a problem with windows not having the same boot mode as the linux OS. You will still face some issues occasionally and may need some ‘tweaks’ to go round it.
But thanks both for your input and thoughts .
Well, we’ll wait for the OP to provide the infomation, if he/she wish.
Entirely up to him/her. 
 - Meant that sincerely. Some have thought my politeness as condescending, sarcastic or worse.
I only do that to my best pals or my worst enemies. And some cannot differentiate between the two. Ho! Ho! Relax, don’t take everything so seriously. Life is short, have a bit of fun.
 - I think OP does not have the booting $esp in the internal drive.
But we can still fix it, if he replies, and if he want to.
It’s a single-boot headless self-made NAS without windows or other furniture
So, must I just ignore the issue?
I guess, since your issue is solved with a module loading, it will be fixed for the other kernels with the next updates. Jonathon may know better.
Sorry but you misunderstood . I have the exact same situation as the OP, after a kernel update in Manjaro grub doesn’t update during the upgrade process , it has nothing to do with Linux Mint . I was simply stating that I had to do the same thing when dual booting Windows with Linux Mint . After a kernel update in Manjaro the grub fails to update and I lose my Windows entry in grub . It requires a reboot and updating grub manually in the terminal to correct . This is SOP as far as I’m concerned .
That should not happen. Kernel updates in any linux OS will generate a grub.cfg that will incorporate the new kernel automatically for us.
Unless… you have (or had in the past (will remain after uninstalled)) installed grub-customizer.
If you did not, just reinstall grub and see if that happens again.
It’s not good to mix uefi OS’s with bios-legacy OS’s or msdos disks with gpt disks (with OS’s in them). It (grub) may work with just linux OS’s in them, sometimes and sometimes not.
If it is working now for you, and reinstalling (need to wipe disk to fix it) is understandably best avoided, best to boot up the OS’s using their own grub rather than the other OS grub.
Never used a Grub customizer and the situation is inconsistent for me and applies to multiple distro’s and computers . Since you have to reboot for the upgrade to be applied to a kernel and modules anyway & a simple sudo update-grub fixes it , it’s really a non issue IMO .
Okay, understand. Just surprised you need to do that.
Cheers, take care.
Sorry I’m late (I hope not too much), I had a rough week then hollidays then my-life-is-too-complicated-to-explain-here-and-does-not-interest-anyone ^^
But I’m very glad to see the issue leads to a lot of interesting talks
For the commands :
$ efibootmgr -v EFI variables are not supported on this system. $ sudo parted -l Model: ATA SAMSUNG HD103UJ (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 106MB 105MB primary ntfs boot 2 106MB 78.6GB 78.5GB primary ntfs 3 78.6GB 1000GB 922GB primary ntfs Model: ATA WDC WD10EARS-00Y (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1000GB 1000GB primary ext4 Model: ATA SAMSUNG HD103UJ (scsi) Disk /dev/sdc: 1000GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 8390MB 8389MB primary linux-swap(v1) 2 8390MB 60.8GB 52.4GB primary ext4 3 60.8GB 1000GB 939GB primary ext4 Model: WD Elements 10B8 (scsi) Disk /dev/sdd: 3001GB Sector size (logical/physical): 4096B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 3001GB 3001GB primary ntfs Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only. Error: /dev/sr0: unrecognised disk label Model: ASUS DRW-20B1LT (scsi) Disk /dev/sr0: 8072MB Sector size (logical/physical): 2048B/2048B Partition Table: unknown Disk Flags: $ sudo blkid /dev/sda1: LABEL="RM-CM-)servM-CM-) au systM-CM-(me" UUID="A43272113271E926" TYPE="ntfs" PARTUUID="0001be35-01" /dev/sda2: LABEL="Win7" UUID="C6149CCF149CC439" TYPE="ntfs" PARTUUID="0001be35-02" /dev/sda3: LABEL="Jeux" UUID="50144E6D144E565E" TYPE="ntfs" PARTUUID="0001be35-03" /dev/sdc1: UUID="8c33ce28-7191-4040-bbd4-ad349b99dbd6" TYPE="swap" PARTUUID="12c625c6-01" /dev/sdc2: LABEL="ManjaroLinux" UUID="dfd31e24-625f-4585-9380-ddaa71824845" TYPE="ext4" PARTUUID="12c625c6-02" /dev/sdc3: LABEL="Home" UUID="b4bdc515-5b3e-4b02-8e8e-b54d9d30201c" TYPE="ext4" PARTUUID="12c625c6-03" /dev/sdb1: LABEL="Data" UUID="c152acad-2fa2-4670-be57-c217796ea615" TYPE="ext4" PARTUUID="158b158a-01" /dev/sr0: UUID="47cf9fb6000002cf" LABEL="CNC3KW" TYPE="udf" /dev/sdd1: LABEL="Elements" UUID="54D8D96AD8D94ABE" TYPE="ntfs" $ findmnt -s TARGET SOURCE FSTYPE OPTIONS swap UUID=8c33ce28-7191-4040-bbd4-ad349b99dbd6 swap defaults,noatime / UUID=dfd31e24-625f-4585-9380-ddaa71824845 ext4 defaults,noatime /home UUID=b4bdc515-5b3e-4b02-8e8e-b54d9d30201c ext4 defaults,noatime $ ls /boot/efi/EFI/ ls: cannot access '/boot/efi/EFI/': No such file or directory
And I didn’t try an other kernel than the 4.14.x and I didn’t customize my Grub either btw.
Thanks for the help guys
PS : I still have the issue with the 4.14.70-1
Any ideas ?
What issue? After updating kernel, you have to reboot and then update grub?
This is a bug of MSM/mhwd, or an update hook. IIRC it is an old known issue. You may check at Manjaro Gitlab.
Or is there any other issue?
Oh ok sorry, I didn’t know the issue was known and reported as bug of MSM/mhwd …
No other issue