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!
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.
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.
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.
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. :’(
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:
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
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.
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?
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.
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.