Issue writing Grub

English Install/Boot/Login
#1

Hi,
I updated Leap 42.2 to 42.3 tonight and got the following error message when trying to write the boot loader configuration:

**

******ERROR

**Execution of command “”/usr/sbin//grub2-install", “–target=i386-pc”, “–force”, “–skip-fs-probe”, “/dev/sda”]]" failed.
Exit code: 1
Error output: Installing for i386-pc platform.
/usr/sbin/grub2-install: error: the drive hd0 is defined multiple times in the drive map /boot/grub2/device.map.

I tried checking in Yast, but I get the same message when I do.
**
Any ideas?

Michael.

#2

It’s ok, I managed to solve the problem! (hd0) /dev/sda was in the list twice and when I went back into Yast, I was able to eliminate the extra one.

Problem solved.

#3

I encountered the same error yesterday upgrading first from 42.1 to 42.2, and then from 42.2 to 42.3. Please note this is a multi-boot system. Based on a few re-boots since the installation, I detect no issues.

Nevertheless, my device.map now contains the following:

linux-5:~ # cat /boot/grub2/device.map
(hd2)   /dev/sda
(hd3)   /dev/sdb
(hd4)   /dev/sdc
(hd5)   /dev/sdd
(hd0)   /dev/sde
(hd2)   /dev/sda
(hd3)   /dev/sdb
(hd4)   /dev/sdc
(hd5)   /dev/sdd
(hd0)   /dev/sde
(hd1)   /dev/sdf
linux-5:~ #

The prior version did not contain duplicates:

linux-5:~ # cat /boot/grub2/device.map.old
(hd0)   /dev/sde
(hd3)   /dev/sdd
(hd5)   /dev/sdf
(hd4)   /dev/sda
(hd2)   /dev/sdc
(hd1)   /dev/sdb
linux-5:~ #

In Yast bootloader, the disk order settings dialogue shows:

/dev/sde
/dev/sde
/dev/sdf
/dev/sda
/dev/sda
/dev/sdb
/dev/sdb
/dev/sdc
/dev/sdc
/dev/sdd
/dev/sdd

May I safely rename the current device.map and regenerate a new device.map? The command “grub-mkdevicemap” does not appear to be available in 42.3, so I would need another command (I don’t believe that grub2-mkconfig would do this).

#4

grub2 does not need device.map at all. The legacy notation is still supported for compatibility by grub2-install, but it is highly recommended to use actual Linux device name instead (so e.g. /dev/disk/by-uuid/xxxxxx instead of /dev/sdb). Nor does grub2 need to know BIOS device order. So check /etc/default/grub_installdevice - as long as you do not see hd0 etc there, you should be able to safely delete device.map. Nothing in configuration file generated by grub2-mkconfig should depend on entries in device.map.

In any case, using /dev/sdX there is pretty much useless, because they themselves are not guaranteed to be persistent across reboot, which defeats the purpose of device.map - provide stable mapping between Linux device name and BIOS device order.

#5

arvidjaar -

Thanks (and good to hear from you).

The sole contents of grub_installdevice is /dev/sde, which is where Leap 42.3 resides. In .fstab, all of the partitions are identified by UUID - including of course /dev/sde, while the YaST partitioner identifies the drives by /dev/sdX.

Some folks have deleted duplicate entries from device.map and others have just left the file in place, although I not aware of solid reasons for doing either.

#6

PS.

To be certain that it’s clear, the device listed in grub_installdevice, /dev/sde, is hd0.

#7

Duplicating entries sounds like a bug. As the only instance that touches this file should be YaST it calls for bug report. Although before opening bug, one should find out how to reproduce it, preferably without going through full reinstallation.

None of openSUSE systems I ever installed had device.map. So I do not know :slight_smile:

#8

You piqued my curiosity, so I took a quick peek. In 42.2, on one laptop, I have device.map, and on another laptop with 42.3, I see it there.

In both cases the contents are:

(hd0) /dev/sda

So now I am wondering why I do have them, which I never created to the best of my knowledge, and why you do not?

What makes the difference?

#9

Thank you both for your replies.

On checking two other 42.3 installations, they both contain device.map files (one - a dual boot system - with duplicate entries for hd0 and hd1) as well as device.map.old files from 42.1. Perhaps the install process detected the 42.1 device.map file and proceeded to revise/update the map to conform with the 42.3 installation (just speculation on my part).

A 13.2 system (on the same platform as the 42.3 system under discussion) contains the following grub_installdevice:

/dev/disk/by-id/scsi-0ATA_Samsung_SSD_850_S2BENWAG104807W-part2
activate
generic_mbr

The 42.3 system resides on sde5; the 13.2 on sde2. As noted previously, grub_installdevice for the 42.3 system only contains /dev/sde - not the other two lines, “activate” and “generic_mbr” (the same files on the other two 42.3 machines do contain the entries activate and generic_mbr, but not “by-id” – only /dev/sdX).

While the device.map file may not play a critical or necessary role for 42.3, the warning I received during install “grub2-install: error”] nonetheless strongly implied that I might not have a bootloader at the end of the process. Alarming to say the least.

#10

I take it back. Actually they do have device.map. Judging by modification date, they were created by installer indeed. Even 13.2 has it.

And they contain /dev/sdX entries making them rather useless.

Also having them serves zero purpose as /etc/default/grub_installdevice (which contains actual device where grub is installed) contains /dev/disk/by-uuid anyway.

#11

Okay, thanks. I thought maybe there might be something different about our installs that caused it for me and not for you.

Not that it was a big deal, but it made me curious (note my avatar :smiley: ).

#12

I have encountered the same error upgrading from 42.2 to 42.3 – except that I cannot boot at all. There appears to be no grub installed. Boot from hard drive gives: BOOTMGR is missing. I can get to the rescue prompt, but I do not know how to get to yast to proceed as in the earlier posts in this thread. Anyone help? Thanks

#13

daousley -

It’s been some time since I dealt with this issue, so one of the more senior folks on the forum may have some suggestions.

Nevertheless, I recall that this occurred in my case because the bootloader was pointing to the wrong place. When you do the install, there are very specific questions early on about where to write the bootcode. From my notes, the dialog looks something like this:

bootloader options – changed second option from default “do not install” to “install” bootcode into “/” partition.
        (do not change MBR location from /dev/sde to /dev/sde5, otherwise error)
    Booting
        . . .
        Status location: /dev/sde5 (“/”), /dev/sde (MBR) [was just “/dev/sde (MBR)”]
        Change Location: 
            Install bootcode into MBR [do not install]
            Install bootcode into “/” partition [do not install]
                was: Do not install bootcode into “/” partition [install]

If this is your issue (and please wait for someone on the forum to agree), then it might be easier to re-do the install, paying particular attention to the bootcode dialog.
But again, please wait for others to comment on this.

#14

Boot from an install medium, hit Ctrl-Alt-F2 as soon as the first screen appears, you’ll see a root prompt
Next mount your rootfs, replace sdX# by the /dev/sd* entry


mount /dev/sdX# /mnt
mount --bind /dev /mnt/dev
mount --bind /prov /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
yast
#15

I suspect the continuing presence of device.map in TW and Leap in any case is a consequence of openSUSE continuing to include Grub Legacy in the repos, and kernel installation and removal processes continuing to support updating Grub Legacy’s menu.lst for those who continue to depend on Grub Legacy and have no need for Grub2 to fix what for them ain’t broke. We are blessed to continue to have the choice, even though it takes extra work to keep the old way working with a fresh installation instead of zypper online upgrade. In any event, presence of device.map should not be producing error messages or outright bootloader failures. Surely such are results of Perl/YaST2/Installer rewrites that need fixing.

#16 

mount /dev/sdX# /mnt
mount --bind /dev /mnt/dev
mount --bind /prov /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
yast

Thanks. THis worked to get me into yast, where I could delete the duplicate entries (/dev/sdd, etc) Then I could successfully install grub from there (also from the upgrade option in the installation dvd). But when I attempt to boot from the hard drive, I get

BOOTMGR is missing

and boot stops. What now? Thanks.

#17

Post the following:

fdisk -l

and

parted -l
#18

This might be an instance where output from bootinfoscript would be most useful.

#19

fdisk -l and parted -l are below, as requested.

Since my last post:

The boot hangup with BOOTMGR is missing has been resolved – by changing the BIOS settings to Boot with Failsafe settings.

Since I was having other issues with 42.3 (video driver, apparently – there is another thread on that), I installed 42.2 to a spare partition. One result is that I got back the GRUB2 menu which I had before I upgraded 42.2 to 42.3 From this I can book to 13.2, which is what I am now running. When from this menu I try to boot 42.2, it tells me it cannot find /boot/vmlinuz-4.4.74-18.20-default – presumably because it is looking for 42.2 where 42.3 now resides. The GRUB2 menu does not list 42.3 I am not sure how to tell GRUB2 to look in the right place.

A word of explanation on the disks: this is an older machine, BIOS not UEFI. Originally had hardware RAID (mirrored). That is no longer the case (I did not rebuild it after a drive failure). OS versions are on two SSD drives, /home on the hard disk. Currently, in addition to Windows (originally a dual boot system), OpenSuse 12.3, 13.2, 42.2 and 42.3 (which I have yet to successfully boot) are installed. 42.3 was installed as an upgrade to 42.2, which is what precipitated the issues when GRUB2 failed to install, and thus my queries on this thread. The original issue with GRUB2 was duplicate hd0 entries, which I resolved by manually removing the duplicate entries.

So at this point, I would like to be able to boot 42.3 (so I can continue to troubleshoot) and 42.2 (so I can use it) from GRUB2. Help appreciated.


# fdisk -l

Disk /dev/sda: 28 GiB, 30016659456 bytes, 58626288 sectors
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: 0x10ce7af1

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1           2048   206847   204800  100M  7 HPFS/NTFS/exFAT
/dev/sda2         206848   387071   180224   88M  7 HPFS/NTFS/exFAT
/dev/sda3         387072   694271   307200  150M 83 Linux
/dev/sda4  *      694272 58626047 57931776 27.6G  f W95 Ext'd (LBA)
/dev/sda5         696320  4915199  4218880    2G 82 Linux swap / Solaris
/dev/sda6        4917248 46335999 41418752 19.8G 83 Linux
/dev/sda7       46338048 58626047 12288000  5.9G 83 Linux

Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000c6865

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1        2048 1918144511 1918142464 914.7G  f W95 Ext'd (LBA)

Disk /dev/sdc: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000bba26

Device     Boot    Start       End   Sectors   Size Id Type
/dev/sdc1  *        2048 234440703 234438656 111.8G  f W95 Ext'd (LBA)
/dev/sdc5           4096  62910463  62906368    30G 83 Linux
/dev/sdc6       62912512  83892223  20979712    10G 83 Linux
/dev/sdc7       83894272 234440703 150546432  71.8G 83 Linux

Disk /dev/sdd: 1.4 TiB, 1500301910016 bytes, 2930277168 sectors
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: 0x10ce7ae9

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdd1  *          2048 1007823757 1007821710 480.6G  7 HPFS/NTFS/exFAT
/dev/sdd2       1007824896 2930145279 1922320384 916.6G  f W95 Ext'd (LBA)
/dev/sdd5       1007826944 1007966207     139264    68M 83 Linux
/dev/sdd6       1007968256 1012174847    4206592     2G 82 Linux swap / Solaris
/dev/sdd7       1012176896 1054121983   41945088    20G 83 Linux
/dev/sdd8       1054124032 2930126847 1876002816 894.6G 83 Linux

Disk /dev/loop0: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop1: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/docker-8:6-156866-pool: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 65536 bytes

# parted -l

Model: ATA KINGSTON SSDNOW (scsi)
Disk /dev/sda: 30.0GB
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            type=07
 2      106MB   198MB   92.3MB  primary   ntfs            type=07
 3      198MB   355MB   157MB   primary   ext4            type=83
 4      355MB   30.0GB  29.7GB  extended                  boot, lba, type=0f
 5      357MB   2517MB  2160MB  logical   linux-swap(v1)  type=82
 6      2518MB  23.7GB  21.2GB  logical   ext4            type=83
 7      23.7GB  30.0GB  6291MB  logical   ext4            type=83


Model: ATA ST2000DM001-1ER1 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type      File system  Flags
 1      1049kB  982GB  982GB  extended               lba, type=0f


Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sdc: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  120GB   120GB   extended               boot, lba, type=0f
 5      2097kB  32.2GB  32.2GB  logical   ext4         type=83
 6      32.2GB  43.0GB  10.7GB  logical   ext4         type=83
 7      43.0GB  120GB   77.1GB  logical   ext4         type=83


Model: ATA ST31500341AS (scsi)
Disk /dev/sdd: 1500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  516GB   516GB   primary   ntfs            boot, type=07
 2      516GB   1500GB  984GB   extended                  lba, type=0f
 5      516GB   516GB   71.3MB  logical   ext4            type=83
 6      516GB   518GB   2154MB  logical   linux-swap(v1)  type=82
 7      518GB   540GB   21.5GB  logical   ext4            type=83
 8      540GB   1500GB  961GB   logical   ext4            type=83


Model: Linux device-mapper (thin-pool) (dm)
Disk /dev/mapper/docker-8:6-156866-pool: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End    Size   File system  Flags
 1      0.00B  107GB  107GB  ext4
#20

The best way to get us the additional information we need, since we don’t yet know which partitions are used by which operating systems, is to provide us the information from bootinfoscript somewhere where we have access to it in raw form. One way is to use susepaste from login shell.

Before you do that, I suggest to try booting 42.3 using the Grub entry that is complaining it can’t find 4.4.74. To do so, select it, then hit e to edit, and in edit mode backspace away all the version information from the kernel and initrd lines, so that all that is shown WRT those two file names is /boot/vmlinuz and /boot/initrd. It should then boot the most recently installed 42.3 kernel. If successful, you should be able to fix booting using 42.3’s yast2 bootloader. If you can’t fix booting properly this way, go ahead and do bootinfoscript so we can see what’s installed where.