I have an old laptop with Windows 7 on which I installed CentOS 8 on dual boot.

Upon first reboot, GRUB showed only entries for Linux. Therefore I used Boot-Repair-Disk, but it somehow failed to install GRUB, as now the laptop boots into Windows directly.

Disk partitions are as follows (as seen by Boot-Repair-Disk):

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sda1               2,048     3,074,047     3,072,000  27 Hidden NTFS (Recovery Environment)
/dev/sda2    *      3,074,048   629,905,407   626,831,360   7 NTFS / exFAT / HPFS
/dev/sda3         629,905,408   632,002,559     2,097,152  83 Linux
/dev/sda4         632,002,560   976,773,119   344,770,560   5 Extended
/dev/sda5         632,004,608   975,978,495   343,973,888  8e Linux LVM

and this is their rough size and what they're used for:

/dev/sda1     1.5 Gb     Windows recovery partition
/dev/sda2     300 Gb     Windows 7 partition
/dev/sda3       1 Gb     Linux /boot partition 
/dev/sda4     164 Gb     Extended partition containing /dev/sda5
/dev/sda5     4 Gb /swap, 130 Gb /, 30 Gb /home, all LVM and LUKS-encrypted

It is worth noting that Windows sees /dev/sda4 as a primary (not extended) partition.

This is part of the output of Boot-Repair-Disk:

Is there RAID on this computer? no
File descriptor 8 (/proc/17432/mountinfo) leaked on lvs invocation. Parent PID 19248: /bin/sh
Error: /dev/mapper/cl-00: unrecognised disk label
Error: /dev/mapper/cl-01: unrecognised disk label
Error: /dev/mapper/cl-02: unrecognised disk label
Warning: Unable to open /dev/sr0 read-write (Read-only file system).  /dev/sr0 has been opened read-only.
Error: Invalid partition table - recursive partition on /dev/sr0.
boot-repair is executed in live-session (Boot-Repair-Disk 64bit 1oct2017, zesty, Ubuntu, x86_64)
CPU op-mode(s):      32-bit, 64-bit
file=/cdrom/preseed/lubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash --
ls: cannot access '/home/usr/.config': No such file or directory
Set sda as corresponding disk of mapper/cl-00
Set sda as corresponding disk of mapper/cl-01
Set sda as corresponding disk of mapper/cl-02
mount: /mnt/boot-sav/mapper/cl-00: unknown filesystem type 'crypto_LUKS'.
mount /dev/mapper/cl-00 : Error code 32
mount -r /dev/mapper/cl-00 /mnt/boot-sav/mapper/cl-00
mount: /mnt/boot-sav/mapper/cl-00: unknown filesystem type 'crypto_LUKS'.
mount -r /dev/mapper/cl-00 : Error code 32
mount: /mnt/boot-sav/mapper/cl-01: unknown filesystem type 'crypto_LUKS'.
mount /dev/mapper/cl-01 : Error code 32
mount -r /dev/mapper/cl-01 /mnt/boot-sav/mapper/cl-01
mount: /mnt/boot-sav/mapper/cl-01: unknown filesystem type 'crypto_LUKS'.
mount -r /dev/mapper/cl-01 : Error code 32
mount: /mnt/boot-sav/mapper/cl-02: unknown filesystem type 'crypto_LUKS'.
mount /dev/mapper/cl-02 : Error code 32
mount -r /dev/mapper/cl-02 /mnt/boot-sav/mapper/cl-02
mount: /mnt/boot-sav/mapper/cl-02: unknown filesystem type 'crypto_LUKS'.
mount -r /dev/mapper/cl-02 : Error code 32

=================== os-prober:
/dev/sda1:Windows 7:Windows:chain
/dev/sda2:Windows 7:Windows1:chain

=================== blkid:
/dev/sda1: LABEL="System" UUID="FC30DADA30DA9B4A" TYPE="ntfs" PARTUUID="e7d2fa64-01"
/dev/sda2: LABEL="Main disk" UUID="E6C200E1C200B837" TYPE="ntfs" PARTUUID="e7d2fa64-02"
/dev/sda3: UUID="b43f57d3-c143-47b0-ad99-a5b12a0416be" TYPE="ext4" PARTUUID="e7d2fa64-03"
/dev/sr0: UUID="2017-10-29-00-56-18-00" LABEL="Boot-Repair-Disk 64bit" TYPE="iso9660" PTUUID="6b8b4567" PTTYPE="dos"
/dev/loop0: TYPE="squashfs"
/dev/sda5: UUID="sWZAY3-8hDE-wcdv-rEsu-pTcr-9lPV-QEfxlo" TYPE="LVM2_member" PARTUUID="e7d2fa64-05"
/dev/zram0: UUID="462ef96d-8ed3-405e-92c4-043654187abd" TYPE="swap"
/dev/zram1: UUID="df6b8b51-4029-4d37-86ec-d70532265f9b" TYPE="swap"
/dev/zram2: UUID="9d842b41-46c1-4ed3-aefb-447d99a6321f" TYPE="swap"
/dev/zram3: UUID="65d9a196-c801-4e87-9283-314b665108d6" TYPE="swap"
/dev/zram4: UUID="b2cb39b0-9fe1-4485-b044-7d408527117f" TYPE="swap"
/dev/zram5: UUID="f6b1cecd-603e-40a3-8eb3-2bc1ddaca8c1" TYPE="swap"
/dev/zram6: UUID="2fc865d0-0b3b-4d11-bb8d-c272a21e5c39" TYPE="swap"
/dev/zram7: UUID="5be79bcf-4b46-4d62-81b2-952b79e0ecda" TYPE="swap"
/dev/mapper/cl-00: UUID="6eac3a8f-7854-40c7-ae94-c1d288a60698" TYPE="crypto_LUKS"
/dev/mapper/cl-01: UUID="d0e378ae-9140-4335-94e6-2d73a3cb7bd1" TYPE="crypto_LUKS"
/dev/mapper/cl-02: UUID="00e698ad-ac0b-4e27-9bc7-bdcb524ce4ba" TYPE="crypto_LUKS"  

1 disks with OS, 2 OS : 0 Linux, 0 MacOS, 2 Windows, 0 unknown type OS.

Is it really necessary to decrypt the LUKS LVM partitions before trying to reinstall GRUB?

EDIT: To answer the questions in the comments:

Output of fdisk -l /dev/sda:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Seagate ST950056
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: 0xe7d2fa64

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048   3074047   3072000   1.5G 27 Hidden NTFS WinRE
/dev/sda2  *      3074048 629905407 626831360 298.9G  7 HPFS/NTFS/exFAT
/dev/sda3       629905408 632002559   2097152     1G 83 Linux
/dev/sda4       632002560 976773119 344770560 164.4G  5 Extended
/dev/sda5       632004608 975978495 343973888   164G 8e Linux LVM
  • It uses the default GRUB from CentOS 8 i.e. GRUB2

  • LVM partitions were created directly from the CentOS installer

  • Laptop (almost 10 years old) uses BIOS, not UEFI

  • Installer never asked where to put GRUB, it did so automatically

  • Could you post a fdisk -l /dev/sda of the disk? Maybe boot to a live ubuntu disk. – Isaac Jan 26 '20 at 16:48
  • Since you have Windows back, are you willing to try and re-install CentOS? Or you need to recover the partitions on that disk? – Isaac Jan 26 '20 at 16:52
  • I can wipe out the current installation of CentOS 8 as it's a fresh one, no data on it. In fact I was thinking exactly to do that and reinstall without LVM and LUKS partitions. But that would be the easy way; I'd prefer to know what is wrong with the current situation. :) – dr_ Jan 26 '20 at 16:55
  • Well, I do not know yet. For starters, Boot-Repair-Disk reported an error on the partition table Error: Invalid partition table That is the reason to ask for a fdisk -l /dev/sda, if possible. A second reason is that Windows is reporting /dev/sda4 as primary (which it shouldn't if it is an MBR partition, you may have assigned sda4 to LVM and then partition the LVM partition further). – Isaac Jan 26 '20 at 17:03
  • The really easy way is to install grub directly, something similar to grub-install /dev/sda which most probably won't work in your case. – Isaac Jan 26 '20 at 17:07

I can not explain why Boot-Repair-Disk reports an error with the partition table, nor why Windows thinks that /dev/sda4 is a primary partition. The output of fdisk reports no errors with the MBR partition table, and is also able to read the extended partition table in /dev/sda5.

So, all we have to do is:

  • recover access to the grub2 that was installed first (or install a new one)
  • set the chainload commands needed to boot windows from grub.

Re-install grub2

Grub2 was installed to the sectors after the MBR (and before the 2048 sector). That grub2 in the disk has the address of the /boot/grub directory hard coded. Sadly, the contents of /boot/grub are both inside LVM and encoded with LUKS. Grub needs to:

  • read inside LVM disks. That is done with the lvm.mod module.
  • decrypt LUKS disks. That is done with the luks.mod module.

Both modules reside also inside /boot/grub. That creates a catch-22 situation where the keys to the car are inside the car.

The solution is to write some modules to fixed disk sectors and load them on boot. Then ask for the LUKS password, decrypt the /boot/grub directory, load more modules, and finally load /boot/grub/grub.cfg to know which other modules need to be loaded and to present an OS selection list to the user.

However, the modules that need to be written to disk are inside /usr/lib/grub/i386-pc/lvm.mod (for example). Yes, grub may be used in several architectures. Which is also encrypted on the system you installed.

So, the only solution is to:

  1. boot to some live ISO (that has all the current grub files in /usr/lib)
  2. Mount all (decrypted and system) disks in the correct place.
  3. Use chroot to switch to the 'real' system on disk.
  4. Use grub-install to re-place grub to the disk.

This is the guide to rescue CentOS that you should follow. It is simplified, except, sadly, the part of decrypting LVM-LUKS encrypted partitions which adds another twist.

After that has been done and you system boots to CentOS via grub, you need to include (if windows was not auto-detected whith grub-install) to add a couple of entries to the grub.cfg file. Use the entries from this page


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.