grub misconfiguration after update

Hello Forum,

I updated my notebook to Leap yesterday and I can not properly boot to Leap.

I have used an USB pendrive to update openSUSE and during the installation process I imported the previous (working) partitions setup, which follows

FONT=comic sans ms /dev/sdb1 22G 7,4G 14G 36% /
(HDD) /dev/sda5 34G 48M 33G 1% /opt
/dev/sda2 98G 88G 11G 90% /windows
/dev/sda3 323G 301G 6,1G 99% /home[/FONT]

After restart grub complains about missing device, but if I boot from the USB pendrive Instaler and select “Start from Hard drive” everything goes fine.

Any idea about how to detect/solve this issue. Thank you!

Pablo

It’s hard to guess.

Maybe the missing device is that pen drive.

Does the grub message say anything about which device is missing?

Hi nrickert

grub message is:

error: no such device: d776-fa64-b764-4ffe-a0e0-f3ef4beb2d79

Then the “grub rescue” prompt appears.
I tried to find this number in the drives IDs (I’ve used hdparm and blkid) but neither the pendrive nor the HDDs have anything like this.

As you say, I though the problem was that grub had an entry for the pendrive, but I could not figure out how to check this.

Any idea?

Pablo

Did you try “blkid” while the pen drive was plugged in?

The puzzle is that you say “boot from hard drive” works. But it should be booting the same way. So the only difference is that the pendrive is plugged in.

Yes, I ran blkid with the pen drive plugged in. Here it is the output

blkid

/dev/sdc1: SEC_TYPE=“msdos” UUID=“FDA2-4A52” TYPE=“vfat” PARTUUID=“20ca2c8b-01”
/dev/sdc2: UUID=“2015-10-29-23-29-08-00” LABEL=“openSUSE-Leap-42.1-DVD-x86_64026” TYPE=“iso9660” PARTUUID=“20ca2c8b-02”
/dev/sda1: UUID=“526E5C196E5BF3E7” TYPE=“ntfs” PARTUUID=“5a9d219b-01”
/dev/sda2: UUID=“1C367F2A367F0454” TYPE=“ntfs” PARTUUID=“5a9d219b-02”
/dev/sda3: UUID=“a8737e85-9bad-46b4-866b-6d21a9ac0062” TYPE=“ext4” PARTUUID=“5a9d219b-03”
/dev/sda5: UUID=“8cfcf8e8-0b53-44fe-a4ec-10fb6e2b72c3” TYPE=“ext4” PARTUUID=“5a9d219b-05”
/dev/sda6: UUID=“8209fceb-a9c7-45dd-9b30-de19a632952d” TYPE=“swap” PARTUUID=“5a9d219b-06”
/dev/sdb1: UUID=“0325a540-972d-4074-a94f-6089cfb7eeaa” TYPE=“ext4” PTTYPE=“dos” PARTUUID=“f1fac299-01”

Then it is a bit of a mystery as to how “boot from hard drive” works with the pen drive. For me, that usually just reboots the pen drive.

A few months ago, I did run into a similar problem “no such device”. It turned out that something had gone wrong with the grub install, and I was really running grub that was used for the previous system. So the UUID it was looking for was from before the reformat during the install.

To fix it, I went into rescue mode, and then ran “grub2-install”. This was an EFI install, so it did not require other operands. Otherwise I might have needed something like

# grub2-install --force /dev/sda1

. I think I also had to run

# grub2-mkconfig -o /boot/grub2/grub.cfg

If you are actually able to boot into your system with the aid of the pendrive, then you could try reinstalling grub from there. That avoids all of the chroot stuff.

(Added in edit) – don’t install grub2 to “/dev/sda1”. That was an example. For you, that is a Windows partition which you would damage if you tried to install grub there.

Hi,

I reinstalled Leap taking special care to the booloader step and I still have the same problem.

I started Leap using the “Super grub disk” (not the installer pen drive).

Below you can see the output from the commands you told me. It is a strange to see the “i386-pc” message. I suspect that it is a problem previous to my installation, maybe something inherited by the ISO Leap installer? (I do not want to be rude, It is just a guess )

grub2-install --force /dev/sdb1

Installing for i386-pc platform.
grub2-install: aviso: El sistema de ficheros «ext2» no permite el embebido.
grub2-install: aviso: El embebido no es posible. GRUB podrá ser instalado con esta configuración únicamente usando listas de bloques. No obstante, las listas de bloques son INSEGURAS y su uso está desaconsejado…
Instalación terminada. No se notificó ningún error.

grub2-mkconfig -o /boot/grub2/grub.cfg

Generating grub configuration file …
Encontrado tema: /boot/grub2/themes/openSUSE/theme.txt
Encontrada imagen de linux: /boot/vmlinuz-4.1.12-1-default
Encontrada imagen de memoria inicial: /boot/initrd-4.1.12-1-default
Encontrado Windows 7 (loader) en /dev/sda1
Encontrado Mac OS X en /dev/sdc3
hecho

I am stuck with this issue. I do not known what to do. :’(

Pablo

I found a nice script to search grub files into the system in this link http://lists.opensuse.org/opensuse/2015-10/msg00673.html

Here you can see the output.

http://susepaste.org/81466715

Thank you for your help and patience.

Pablo

Okay. Since you are able to boot with Super grub disk, there’s no need to try reinstalling Leap.

The grub2-install seems to have failed, but I’m not sure why. Usually the “–force” tells it to go ahead anyway.

There should be a file “/boot/grub2/device.map”. Can you provide the content of that (it will probably be 2-3 lines of text). I’m not sure if a problem there would cause the issue you are seeing, but I suppose we should check.

It is a strange to see the “i386-pc” message.

That’s actually quite normal. Grub2 is built to use 32-bit, even in a 64-bit install.

Maybe another question. Have you considered installing grub in the MBR (of your SSD)? Perhaps that would work. What’s the output from:

# fdisk -l

Mi HDD is an hybrid disk with an SSD (24Gb) disk. I can try installing grub in the SSD MBR if you can tell me how.

Here are the output of the commands you told me

cat /boot/grub2/device.map

(hd0) /dev/sdb

fdisk -l

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 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: 0x5a9d219b

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 205006847 204800000 97.7G 7 HPFS/NTFS/exFAT
/dev/sda3 * 205006848 892893183 687886336 328G 83 Linux
/dev/sda4 892893184 976773119 83879936 40G f W95 Ext’d (LBA)
/dev/sda5 892895232 964173823 71278592 34G 83 Linux
/dev/sda6 964175872 976752639 12576768 6G 82 Linux swap / Solaris

Disk /dev/sdb: 22.4 GiB, 24015495168 bytes, 46905264 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: 0xf1fac299

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 46903295 46901248 22.4G 83 Linux

GPT PMBR size mismatch (26875 != 3913663) will be corrected by w(rite).

Disk /dev/sdc: 1.9 GiB, 2003795968 bytes, 3913664 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: gpt
Disk identifier: 1ADC89F7-B6C5-4DB1-8389-FCC696E92D1A

Device Start End Sectors Size Type
/dev/sdc1 64 271 208 104K Microsoft basic data
/dev/sdc2 272 6031 5760 2.8M EFI System
/dev/sdc3 6032 26827 20796 10.2M Microsoft basic data

The device.map content looks okay.

Try installing in the MBR with:

# grub2-install /dev/sdb

I wanted to look at the “fdisk” output to see if using the MBR might cause problems. It does not look as if it would.

I am assuming that your BIOS is configured to boot from the SSD.

Requoting this with in a code block for better readability.


# fdisk -l

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 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: 0x5a9d219b

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1            2048    206847    204800  100M  7 HPFS/NTFS/exFAT
/dev/sda2          206848 205006847 204800000 97.7G  7 HPFS/NTFS/exFAT
/dev/sda3  *    205006848 892893183 687886336  328G 83 Linux
/dev/sda4       892893184 976773119  83879936   40G  f W95 Ext'd (LBA)
/dev/sda5       892895232 964173823  71278592   34G 83 Linux
/dev/sda6       964175872 976752639  12576768    6G 82 Linux swap / Solaris

Disk /dev/sdb: 22.4 GiB, 24015495168 bytes, 46905264 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: 0xf1fac299

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *     2048 46903295 46901248 22.4G 83 Linux

GPT PMBR size mismatch (26875 != 3913663) will be corrected by w(rite).

Disk /dev/sdc: 1.9 GiB, 2003795968 bytes, 3913664 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: gpt
Disk identifier: 1ADC89F7-B6C5-4DB1-8389-FCC696E92D1A

Device     Start   End Sectors  Size Type
/dev/sdc1     64   271     208  104K Microsoft basic data
/dev/sdc2    272  6031    5760  2.8M EFI System
/dev/sdc3   6032 26827   20796 10.2M Microsoft basic data

[/QUOTE]

This sentence gave me the hint to understand what I was doing wrong (very wrong)

I am assuming that your BIOS is configured to boot from the SSD.

For some reason I thought that I can boot from the SSD so I configured the system accordingly. Although, as I told you, this is an hybrid disc and the BIOS sees one disc. After your comment I checked the BIOS and it only sees sda. All messages we were seeing were from the previous installation!!! (openSUSE 13.1)

I installed grub to sda and now I can boot properly.

Just say thank you very much for your help!!!

Pablo

According to BIS, you have GRUB2 boot block in sda MBR but it cannot parse core.img from this installation. How is your BIOS configured? What is your boot disk according to BIOS settings?

GRUB2 from sdb looks OK. Can you play with BIOS settings and try to reorder hard disks?

Also can you make available the first megabyte of /dev/sda?

dd if=/dev/sda of=/tmp/sda bs=1M count=1
gzip -9 /tmp/sda

and place somewhere /tmp/sda.gz? Thank you!

It sounds like when you boot your system GRUB from the sda is loaded, but we do not really see what it does. It is quite possible that it expects device with this unknown UUID.

Pity. I hoped to be able to enhance BIS to recognize your case. Too late.

Well, next time someone will have a problem we still won’t have a tool to analyze it …

I have a similar issue on both my laptop and desktop which we can work on & use your script. I t will take me a bit to collect the info and post though – have to go to work; my desktop disk set up is similar to the OP, i.e., both DOS & GPT drives.

When I have a chance, I will run your script & get back.

I spent an entire evening on this problem having encountered it on 2 similarly setup machines. I have found a simple solution that works for both and perhaps an explanation that will help others. Critically both these machines have more than one hard disk and the simple solution is to swap the sata data leads (thus swapping their place in the BIOS boot order).

Background: Each machine had WinXP installed on sda and Opensuse 13.1 32bit installed on sdb. Prior to the 42.1 Leap upgrade, Grub dual boot worked fine. After upgrade both failed on reboot and fell back to grub rescue> prompt reporting a missing device.

Both machines worked fine when rebooted using the install CD (by aborting out of the install routine at the first chance and following the menus to install from an existing partition) indicating that the upgrade itself went fine.

During the upgrade however, the install process recognises that Opensuse was on sdb2 >> which (critically here I believe) it reformatted << (thereby changing the partition ID?. The install also changed the boot order of the disks from sda 1st to sdb 1st and installed Grub on the root partition of sdb (if I recall correctly).

Come the reboot after install completes, I believe the BIOS still looks to sda to boot where it finds the old copy of grub (since this drive was untouched by the install) which specifies the old UUID of sdb2 (since reformatted and therefore now gone - hence “device missing”.

Swapping the drive connections physically (or presumably the boot order in BIOS) restored normal dual boot function and the correct Grub menu system.

Hope this helps.