grub-install: error: will not proceed with blocklists

Question

Following up on Install Grub2 to PBR, and opening a new question to provide link to boot-info-summary, as per @mook765:

http://paste.ubuntu.com/p/SnT6Tcdmqk/

Here is again the problem:

% grub-install /dev/sdc5
Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists

I.e., grub-install refuses to proceed with blocklists, saying "File system 'ext2' doesn't support embedding". However, mine is not an ext2 file-system but ext4, and it does NOT need fsck:

$ mount | grep /dev/sdc5
/dev/sdc5 on /mnt/osp type ext4 (rw,noatime,nodiratime,data=ordered)
% umount /dev/sdc5
umount: /dev/sdc5: not mounted.
% fsck.ext4 /dev/sdc5
e2fsck 1.44.1 (24-Mar-2018)
osp: clean, 115049/513072 files, 897251/2048287 blocks

and for your convenient, here is the relevant part from the boot-info-summary:

sdc5: __________________________________________________________________________
    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v1.99-2.00) is installed in the boot sector of 
                       sdc5 and looks at sector 34172346 of the same hard 
                       drive for core.img, but core.img can not be found at 
                       this location.
    Operating System:  Ubuntu 18.04.2 LTS
    Boot files:        /boot/grub/grub.cfg /etc/fstab 
                       /boot/extlinux/extlinux.conf 
                       /boot/grub/i386-pc/core.img

AMEND:

Alright, let me explain my configuration a bit.

• I don't use lilo to boot my system. The only reason I put lilo in mbr is that, it has the advantage of being able to boot directly from extended partition, instead of from prime partitions only.
• Yes I have 4 MBRs, i.e., 4 HDs, but all HD are setup the same -- it will be booted from the active partition, show as "*" in fdisk -l output, thanks to the lilo in mbr. In fact any normal MBR will do as all my active partition are prime partitions, not extended partition. But I just kept my option open.
• The active partition, of any HD, is booted by extlinux. From there I chainload whatever I want to boot, from its boot menu.
• The normal Linux partition are booted by extlinux as well, but somehow I wasn't able to make /dev/sdc5 booted by extlinux, so I switched to grub2, and it had been booting fine before.
• The problem started when I try to make a USB partition bootalble, the "install the grub2 as the boot-loader from OS in partition-B to OS on partition-A" thing in my previous question.
• Now neither partition-B nor partition-A are bootable any more.
• For full disclosure, both partition-B and partition-A are restored from a LUbuntu system that I carefully installed and trimmed. This "restored" is the main reason I wasn't able to make it bootable via extlinux, I suspect, but can't prove.
• Legacy grub is a staled partition/OS that I have't touch for years, even 10+ years, however,
• the grub4dos is the one I newly setup on my USB disk. It is bootable, and it allows me to chain boot into anything that I want, with simple syntax that I understand well. I.e., it has nothing to do with how my current system boot, as I may detach it at any moment.

Solution 1

I got this error trying to install Grub2 in a Virtualbox VM that uses an image file as the hard drive. The solution turned out to be using the --force option with grub-install. Even though grub complains about working with blocklists, the VM boots fine now.

sudo grub-install /dev/sda --force
sudo update-grub

Solution 2

grub-install: error: will not proceed with blocklists came up for me when upgrading to 20.04 from 19.10 on a Linode VM, solution was to ignore the error and run

grub-update

and ignore the grub-install error. Seems to boot OK.

Comments

[mook765]

Wow, what a complicated configuration. At least I understand now that you use lilo to chainload grub in this PBR, but grub can't find it's core.img, so that's why you can't boot that OS. I never used lilo or syslinux, so I can't help much with that. Maybe you try Super Grub to boot into that OS and reinstall the grub-pc-package when booted into that OS, as it seems to be impossible to do it with a chroot.

[oldfred]

You have 4 MBR. Keep a Windows boot loader on Windows drive and put a grub2 into every other MBR, to boot first, second & third choices. And Each grub then can boot all your installs if desired. Eliminate grub legacy, and grub4dos (grldr) as that is based on grub legacy. One grub to boot them all. (Sounds like that should be one Ring to join them all, but that must be something else.) :)

[xpt]

thanks @mook765, I'll look into Super Grub next. I've updated my OP with a bit explanation of my setup BTW.

[mook765]

Grub2 has no problems with booting an OS installed in a logical partition, this works out of the box. I think you should do some clean-up and remove outdated, unused Systems, so you have better overview. I had a triple-boot in legacy-mode before and only used Grub2 to manage that, in two of the systems I had grub installed to PBR, but never chainloaded, only used grub from MBR to boot any OS.

[Admin]

It worked because you already had a working grub install that luckily was able tob oot your new config, so this is not a solution for this kind of problem.