cannot find a GRUB drive for /dev/sda1. Check your device.map

Question

this is my disk configure:

# hlsblk -F
NAME            FSTYPE      FSVER            LABEL       UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
loop0           squashfs    4.0                                                                       0   100% /run/archiso/airootfs
sda                                                                                                            
├─sda1          btrfs                                    0bd3ff02-b7a9-4421-877c-c16d1fdf6a6e                  
└─sda2          crypto_LUKS 2                            f030bc5b-773e-4fea-88d4-36b3e95f7c26                  
  └─x200        LVM2_member LVM2 001                     20xRtS-jPGK-kTIC-YKfA-XDNr-RSPr-CxNcRU                
    ├─x200-swap swap        1                            f6c9ca7d-41a5-4f6b-acc8-fd53e1f4a36e                  
    └─x200-root btrfs                                    f174b77a-c75c-4897-ac31-80aa728004c8                  
sdb             iso9660     Joliet Extension ARCH_202206 2022-06-01-15-35-22-00                                
├─sdb1          iso9660     Joliet Extension ARCH_202206 2022-06-01-15-35-22-00                       0   100% /run/archiso/bootmnt
└─sdb2          vfat

So I've mounted all needed partitions and chroot into it as follows:

# swapon /dev/mapper/x200-swap
# mount /dev/mapper/x200-root /mnt
# mount /dev/sda1 /mnt/boot
# arch-chroot  /mnt

When I try to install GRUB with grub-install I get: /usr/bin/grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map. This full command output will be pasted at the end of this post.

Got same above error when grub-mkconfig.

This is the head of my grub config.

# head /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
# GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=/dev/sda2:cryptlvm root=/dev/disk/by-uuid/f174b77a-c75c-4897-ac31-80aa728004c8"
# GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=/dev/sda2:cryptlvm root=/dev/x200/root"
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=/dev/sda2:cryptlvm root=/dev/mapper/x200-root"
GRUB_CMDLINE_LINUX=""

Here is also my fstab

# /dev/mapper/x200-root
UUID=f174b77a-c75c-4897-ac31-80aa728004c8   /           btrfs       rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/  0 0

# /dev/sda1
UUID=0bd3ff02-b7a9-4421-877c-c16d1fdf6a6e   /boot       btrfs       rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/  0 0

# /dev/mapper/x200-swap
UUID=f6c9ca7d-41a5-4f6b-acc8-fd53e1f4a36e   none        swap        defaults    0 0

Full GRUB commands output at BBS.

Update

Formated sda1 as ext4, updated fstab uuids, still getting error. Oh. Also installed os-prober. Still same.

Answer 1

Your full output for grub commands gives on 2nd line

grub-install: info: cannot open `/boot/grub/device.map': No such file or directory.

As root, run

# grub-mkdevicemap

then re-try.

There are lots of 'locales' errors. Maybe installing 'locales' package will help too...

Edit : EFI

Do you try using EFI / UEFI ? Then, you miss a FAT partition.

Answer 2

Are you trying to install GRUB with grub-install /dev/sda1?

Since GRUB practically requires access to MBR and the unused space between the MBR and the first partition when installing for BIOS-style boot process, try grub-install /dev/sda. If it still displays the same error message, just write your own /boot/grub/device.map file. In your case, its contents could be just

(hd0)    /dev/sda

(Ideally, you would use an appropriate /dev/disk/by-id/... pathname in place of /dev/sda, but that's not mandatory.)

grub-install /dev/sda1 would attempt to embed GRUB's boot block into PBR of partition sda1 instead of the MBR. Since most filesystems won't have a fixed space for bootloader, GRUB's boot block would have to point at /boot/grub/i386-pc/core.img by physical disk location, which used to be a very seriously discouraged installation mode. Modern versions of GRUB might no longer support installing GRUB that way at all.

The problem is, the boot block code needs to be so small it won't understand filesystems, so it reads the GRUB image using raw disk block numbers determined at GRUB installation time. For this to work, the GRUB core image needs to be placed somewhere where its physical location on disk is guaranteed to stay the same. From the OS viewpoint, /boot/grub/i386-pc/core.img is a regular file, so a defragmentation tool or a smart filesystem driver might occasionally move it to a different physical location on-disk: that would cause a total boot failure.

When GRUB is installed to the actual Master Boot Record of a MBR-partitioned disk, the empty space between the MBR and the beginning of the first partition (almost 1 MB) is used for the GRUB core image. Since this place is outside any partitions, no filesystem driver or defragmenting tool is going to touch it. This is enough space to embed the GRUB core image, a filesystem driver and any other GRUB modules needed to access /boot as a real filesystem. After loading these, GRUB will then be able to load additional modules (including normal.mod) and its configuration file as regular files, by pathname.

---

Incidentally, if you wanted to boot the i386-pc version of GRUB from a GPT-partitioned disk, you would need a "biosboot" partition that is sized 1 MB and contains no filesystem: it is used to hold the GRUB core image, as the MBR-style space before the first partition will now be occupied by GPT partition table structures instead.

The empty space between the MBR and the beginning of the first partition is a historical remnant: back when disks still used C/H/S addressing, there was a convention to place the beginning of a partition always to the first sector of a track. Since MBR was the very first block of the disk (C/H/S address 0/0/1), that meant the earliest possible start of first partition would be C/H/S 0/1/1, and the rest of track #0 (= cylinder #0, head #0) would be left unused.

Roughly in the Windows XP era, as C/H/S addressing was no longer meaningful and data alignment on RAID arrays, enterprise storage systems and SSDs was becoming an important performance issue, the start-of-first-partition convention was changed: now the recommended place to start the first partition of the disk was at exactly 1 MiB from the beginning of the disk, or at the LBA block number #2048 (assuming classic 512-byte disk blocks).

Answer 3

TLDR: sda1 partition type was not set by fdisk.

This is what was going on.

After some discussion around it, been MBR boot section one of those, I got curious if fdisk was actually reserving disk initial bytes. So I've typed an fdisk -l /dev/sda. Than I've noticed /dev/sda1 had the type undefined or unknown, so I've pressed t, changed the sda1 to Linux, remount everything and grub-install just worked.

Answer 4

I just solved this issue. I followed these steps.

sudo mkdir -p /mnt/broken
sudo mount /dev/sda7 /mnt/broken

OBS: sda7 is not my root, is my EFI, when I saw it, my bootfile was missing, but luckly I have a EFI ziped in a folder, just unziped it and cp for my mounted sda7 on dev and it worked.

Then I updated my linux and and windows partition showed as well.

Maybe the live CD has the bootfile in someplace too.