11.3 - can't find grub without disc/boot from hard disc

I have just installed 11.3 x64. The installation went fine and worked for the first few hours. I ran the online update tool, and now it cannot find grub unless the installation disc is inserted and I select the “boot from hard disc” option. Hopefully someone knows how to correct this problem. Thanks in advance.

I have read about the problem of the root partition being back, but not sure that’s it.

sda1 - swap
sda2 - /
sda3 - /home

There used to be a repair tool in the installation disks. I could not find that in this media. Is that still available?

a question ?
where did you install grub ???
it is suposed to be in the FIRST linux partition
On a suse only install that would be sda1

now it “can” be put on “/” but that is sda2
so sda2 MUST be an ext3 format ed partition ( lvm and ext4 will nor work with grub )

if you did put /boot on the / partition then there will be a boot configure file

on that file will be a listing of just where things are

can you post that along with the output of this command

su -
fdisk -l

There is a script file by please_try_again that can locate your grub boot loader. Message #59 has the most recent version to use:

Looking for Grub and Windows bootloader in all partitions.

Download, make executable and run the script file program. Copy and past the results of findgrub for us to see here in the forum:

Thank You,

I just accepted the installation defaults. Thanks for the help.

Here is the menu.lst

# Modified by YaST2. Last modification on Sat Jan  1 11:34:56 EST 2011
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0
timeout 8
gfxmenu (hd1,1)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 11.3 -
    root (hd1,1)
    kernel /boot/vmlinuz- root=/dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part2 resume=/dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part1 splash=silent quiet showopts vga=0x348
    initrd /boot/initrd-

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 -
    root (hd1,1)
    kernel /boot/vmlinuz- root=/dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part2 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x348
    initrd /boot/initrd-

###Don't change this comment - YaST2 identifier: Original name: windows###
title Windows
    rootnoverify (hd0,0)
    chainloader +1

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Floppy
    rootnoverify (fd0)
    chainloader +1

Here is the fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000378f2

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         262     2104483+  82  Linux swap / Solaris
/dev/sda2             263        4179    31463302+  83  Linux
/dev/sda3            4180       10707    52436160   83  Linux
/dev/sda4           10708       19457    70284375    f  W95 Ext'd (LBA)
/dev/sda5           10708       15276    36700461   83  Linux
/dev/sda6           15277       19457    33583851    c  W95 FAT32 (LBA)

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d9e73

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        2550    20482843+  83  Linux
/dev/sdb2            2551        9729    57665317+  83  Linux

Disk /dev/sdc: 15.4 GB, 15377080320 bytes
255 heads, 63 sectors/track, 1869 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00037716

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1        1868    15004678+   c  W95 FAT32 (LBA)

Disk /dev/sdd: 2029 MB, 2029518848 bytes
129 heads, 32 sectors/track, 960 cylinders
Units = cylinders of 4128 * 512 = 2113536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc3072e18

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *           1         961     1981936    6  FAT16

Once this is resolved I was going to post another question. I add it here in case it affects this issue. This installation moved the drive that was previously sda to sdd. It has windows XP on it. I don’t use it much, and haven’t tried to open it until this update was clean. But seeing as windows expects to be on the first drive, I don’t expect it to work. Is there a way to manually identify a drive to a specific device? (sda & sdb are sata, sdc & sdd are ide devices) Note the windows boot section in grub, hd0,0. But that is now sdd. If grub is still in that old location that may be the issue.

Thank you. Here is the output from findgrub 2.1

Find Grub Version 2.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                    ...
 - skiping partition   /dev/sda1   (swap)         
 - reading bootsector  /dev/sda2   (LINUX)         ...
 - reading bootsector  /dev/sda3   (LINUX)         ...
 - reading bootsector  /dev/sda4   (Extended)      ...
 - reading bootsector  /dev/sda5   (LINUX)         ...
 - searching partition /dev/sda6   (FAT32)         ...
 - reading MBR on disk /dev/sdb                    ...
 - reading bootsector  /dev/sdb1   (LINUX)         ...
 - reading bootsector  /dev/sdb2   (LINUX)         ...
 - reading MBR on disk /dev/sdc                    ... --> Grub found in MBR
 - searching partition /dev/sdc1   (FAT32)         ... --> Windows NT/2K/XP Loader found in /dev/sdc1

You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sdc1
    rootnoverify (hd0,0)
    chainloader +1


 - reading MBR on disk /dev/sdd                    ...
 - searching partition /dev/sdd1   (FAT16)         ...

So the next question is related. Now what, were should I start?

Something does not seem right. We need to know what is in your device.map file as well AND what is the boot order in your BIOS setup? If, as is normal, you boot from hard disk sda first, then your grub menu.lst file is wrong. It looks like you have loaded openSUSE onto sda2, your menu.lst file is loading openSUSE from root(hd1,1) which could not be valid. Your device.map file MUST match the present boot order in your BIOS. Further, when you boot from an openSUSE installation, disk, it can not guess the correct boot order if it is not sda and so YOU must manually set the device.map file boot order to match how you are booting the disk in your BIOS.

cat /boot/grub/device.map

If you set the sda hard drive to be the first boot disk then all root(hd1,1) must change to root(hd0,1). For what you have to work now, you would need to swap the cables between sda and sdb in the hardware and make the new sda the boot disk and the grub boot loader would need to be loaded on it, which is doubtful. Only the grub boot loader has this particular issue as it is using logical drive designations which must be true at boot time. Don’t play with the hard disk boot order before or after installing openSUSE unless you know what this will do to your installation.

Thank You,

  • reading MBR on disk /dev/sda …
  • skiping partition /dev/sda1 (swap)
  • reading bootsector /dev/sda2 (LINUX) …
  • reading bootsector /dev/sda3 (LINUX) …
  • reading bootsector /dev/sda4 (Extended) …
  • reading bootsector /dev/sda5 (LINUX) …
  • searching partition /dev/sda6 (FAT32) …
  • reading MBR on disk /dev/sdb …
  • reading bootsector /dev/sdb1 (LINUX) …
  • reading bootsector /dev/sdb2 (LINUX) …
  • reading MBR on disk /dev/sdc … → Grub found in MBR
  • searching partition /dev/sdc1 (FAT32) … → Windows NT/2K/XP Loader found in /dev/sdc1
You can add the following entry to /boot/grub/menu.lst :

###Don’t change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sdc1
rootnoverify (hd0,0)
chainloader +1

  • reading MBR on disk /dev/sdd …
  • searching partition /dev/sdd1 (FAT16) …
    So, you must set the sdc drive as the boot drive in your BIOS, have it first in your device.map file and you are loading openSUSE from sdb? I must say, you might want to rethink this setup.

Thank You,

At this point I am not really sure quite what to do. As I mentioned, this is what was set up via the YaST installation tool. I didn’t select any specific device order other than identifying and setting the mount points for the existing partitions (/home, /local, /windows C & D). I did set the root partition to ext4 as the newer option, not knowing it might cause an issue. I am no expert, but one thing I hope I have learned over the years of mistakes is once I get to the place I can’t fix it or find the answer myself, to ask questions and wait before messing something big. I am open to any suggestions as to how to get the system to work correctly. Here is the grub device.map

It is still odd to me how:
1 - it was working directly after the install until . . . ? and
2 - that it will find it when booting via the disk, but not without.

Willing to try what ever is needed.

 cat /boot/grub/device.map
(fd0)	/dev/fd0
(hd0)	/dev/disk/by-id/ata-IBM-DJNA-351520_G80GLW4M080
(hd2)	/dev/disk/by-id/ata-ST380815AS_6RW0L125
(hd1)	/dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN

I can’t tell which disk is which since the names are based on the at-id and not /dev/sdX, unless you know which is sda, sdb, sdc and sdd. There is another script that can help and it can be downloaded ready to go by a user called please_try_again. Don’t lose hope just yet.


Thank You,

You might actually download, make executable and run the following script as well:
Displaying partitions infos from hal daemon

Run it with : halinfo -uV and post the output.

It will show us everything we need to know about your partitions.

  • Sorry for the duplicate advice. James was faster.

Thank you both. Below is the halinfo output. Anything else you need, let me know. I appreciate the help.

sh halinfo.run -uV
| dev  mount   fs       label          uuid                                     diskID                                                      start          size |
| sda1         swap                    4f128a35-874f-44b2-8191-539d5e4eeae6     ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part1               63       2055 MB |
| sda2    *    ext4                    37b60f6a-2012-4fbd-848a-d8edf4671faa     ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part2          4209030      30725 MB |
| sda3    *    ext3                    30e91ddb-3182-44dd-bded-53a883ebeaf1     ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part3         67135635      51207 MB |
| sda4         DOS Ext                                                          ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part4        172007955      68637 MB |
| sda5    *    ext3                    de99d9ce-98a3-46f8-a4e6-c2d8102b2433     ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part5        172008018      35840 MB |
| sda6    *    vfat     a^58U          47C0-D00A                                ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN-part6        245409003      32796 MB |
| sdb1    *    ext4                    a0e47e9d-eaef-414b-95df-30ff15f80939     ata-ST380815AS_6RW0L125-part1                                  63      20002 MB |
| sdb2    *    ext4                    92a20ef1-30e3-4255-8a57-38a696f098e5     ata-ST380815AS_6RW0L125-part2                            40965750      56313 MB |
| sdc1    *    vfat                    98DD-FA6D                                ata-IBM-DJNA-351520_G80GLW4M080-part1                          63      14653 MB |
| sdd1         vfat                    0000-1E4C                                usb-USB_2.0_USB_Flash_Drive_544AYGY725MWZQ1B-0:0-part1             32       1935 MB |

As a note, the strange thing is that this installation (11.3) moved the sata drives to the front of the line. That seems to be part of the problem. The at-IBM (sdc) was the primary before (with 11.2 it was sda). It still reads in grub as the hd0 although it is now sdc and from what I read in grub, it should be hd2 (correct?). Now the two sata drives, ata-Hitachi (sda) & ata-ST (sdb) are first. Just a couple of things I noticed, if it helps.

thanks again.

Another quick note. The way the system was working in 11.2 was:

sda - ata-IBM-DJNA-351520_G80GLW4M080
sda1 /windows/C

sdb - ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN
sdb1 swap
sdb2 /
sdb3 /home
sdb4 - extended
sdb5 /local
sdb6 /windows/D

sdc - ata-ST380815AS_6RW0L125
sdc1 /downloads
sdc2 /backup

If there is anyway to get it back to this format, would that fix the issues?

(fd0)    /dev/fd0
(hd0)    /dev/disk/by-id/ata-IBM-DJNA-351520_G80GLW4M080      <--- sdc
(hd2)    /dev/disk/by-id/ata-ST380815AS_6RW0L125  <--- sdb
(hd1)    /dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN <--- sda

So, you have the IBM (sdc) drive designated as the boot drive even as you have openSUSE installed on the Hitachi designated as sda. As far as I know, the grub menu.lst file needs to be on the same drive as the grub boot loader. The menu.lst file can load Linux or Windows from anywhere, but reading of the menu is limited to the same disk. Here is an article about installing the grub boot loader:

Re-Install Grub Quickly with Parted Magic

I really think you might want to start over and perhaps put sda back in the lead in your BIOS setup. To recover your setup, one would need to modify the device map and menu.lst file to reflect the new setup, or just reinstall openSUSE after placing your drives back into a sane (abc) setup and putting grub and openSUSE menu on the same hard drive.

I would expect my device.map file to read:

(hd0)    /dev/disk/by-id/ata-Hitachi_HDS721616PLA380_PVF904Z23A71RN <--- sda
(hd1)    /dev/disk/by-id/ata-ST380815AS_6RW0L125  <--- sdb
(hd2)    /dev/disk/by-id/ata-IBM-DJNA-351520_G80GLW4M080      <--- sdc
(fd0)    /dev/fd0

As you can see, the HDx names change based on the device.map file which is supposed to have the boot order of the drives as setup in your BIOS. If sda does not boot before sdb, then you must manually set it up, but HD0 should be before HD1 which should be before HD2 and so on.

Thank You,

I think you have the drive G80GLW4M080 set as first in boot order
But go to Yast > Bootloader and check that it’s first here:
Make sure the above HD is first here

Your actual SUSE install disk should be second in that list

The situation you describe is not uncommon while mixing SATA and IDE drives. I have reported this behaviour a couple times in several posts. In modern Linux, special device files are handled by the udev daemon, which names and numbers them in the order they are found. As a consequence, sda, sdb etc could perfectly vary from boot to boot. I encountered similar issues systematically with openSUSE 11.3 where device names were switched between the installation and the next reboot on some sytems - probably depending on the BIOS too - with mixed SATA and IDE drives. The fact that it didn’t happen to you on 11.2 is not surprising at all.

cf. from ArchiLinux wiki:

udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.

More info: https://wiki.archlinux.org/index.php/Udev

As far as I know, there is nothing you can do about that. Of course you can reinstall Grub and edit a device.map file, so that sda will refer to hd0 from the Grub point of view, but it will only have influence on the Grub installation (only be true at this moment). The only efficient and clean solution to this kind of problem (and this is always what I end up to do on such systems) is to use only SATA drives. When you have SATA1, SATA2, SATA3 and SATA4, chances are good that the disks will always appear as sda, sdb, sdc and sdd. Having disk changing names is not really a problem as long as you don’t use device names anywhere (like in /etc/fstab or in your Grub menu). But this can be extremely confusing and annoying.

James and John, thanks. The Disk order settings in grub are set in the order from the 11.2 install. IBM-hd0, Hitachi-hd1, ST-hd2. That agrees with the grub menu.lst posted earlier in this string. Based on this I would have assumed them to be set up as needed; IBM-hd0 & sda, Hitachi-hd1 & sdb, ST-hd2 & sdc. However it is not based on fdisk -l (also posted earlier); Hitach-sda, ST-sdb, and IBM-sdc. Is there anything I missed that you asked for?

Based on the information from Please_Try_Again, below it looks like it is a new 11.3 udev issue. It really bites that this decision was made based on new technology forgetting that there are a lot of us out here that don’t upgrade hardware just because it is available on the market.

So udev is inconsistent, Is that what I read? How can that be? How can grub work if the drives can change at the whim of udev?

So my question is, how is it finding grub via the installation disc / boot from hard disc? There must be something different in how they load. Can the disc version be duplicated? The disc seems to be “taming” udev, reading grub and setting the system as specified, whereas the raw grub load lets udev screw things up.

Any thoughts?

If I missed a point you made, I apologize, please point me back to it. Thanks

The BIOS order of the drives don’t change (unless you change it yourself). So hd0, hd1, hd2 (as well as 0x80, 0x81, 0x82) remain. What may vary are the names sda, sdb, sdc, etc. So one time sda will match hd0, another time it will match hd1 or something else. That doesn’t matter, as Grub uses BIOS drives. However device names can appear in Grub entries and that won’t work if device names change. That’s why you should never use device names anywhere, neither in /boot/grub/menu.lst nor in /etc/fstab. openSUSE by default don’t use device names but disk/by-id in /etc/fstab, that refers to the model and serial number of the disk, which don’t change, and/or diks/by-uuid in /boot/grub/menu.lst, that refers to the unique identifier of the partitions, which doesn’t change either unless you reformat the partition.
The fact that device names become “inconsistent” is rarely a problem. But it can be in some cases - while trying to mount foreign filesystems (Unix slices for example) by uuid, as such partitions don’t have one (see the picture in that post Displaying partitions infos from hal daemon), also they still can be mounted by disk IDs.
In short, it’s not a real problem, but because it is confusing for the user, it might be seen as a problem after all. I don’t like this behaviour either - that’s why I ended up with a bunch of IDE disks in my drawers.

Thank you for the details. So as you mentioned grub and the bios (which I have not altered) are looking for the drive id. Is there any way to modify any of this so that grub would be found by the system at boot? At this point it still hangs at “boot from CD” and does not start grub, unless the installation disc is in.

Reading back through your posts, the sata drives are moving to the front (ie sda & sdb), but if grub is looking for the hd id, this shouldn’t matter. Is that correct? This was a semi-clean installation. The root was reformatted to ext4, but I specified existing /home and /local partitions. It seems as though, when grub was installed, it selected the previous location on hd0, which is the ide drive which can now not be found. Would it work to simply reinstall or refocus grub to look to somewhere on the sata drive (hd1-sda)? Perhaps change the settings to boot from the root drive? I am guessing and still hoping for an answer to get this back up and running.

If this is possible I will try to move /windows/c on hd0 over to /windows/c on hd1. Then everything important will be on hd1. If grub were looking to install from the /boot dir on root, that may correct this. The other option would be for it to look for the MBR of hd1 instead of hd0 where it is getting lost today. Then the ide drive is just a bit of extra space. I can remount it as /windows/d. Am I any where close on this?

As far as grub and the windows boot, since /windows/c will be changed to hd1 - sda6, then that location would now be (hd1,5) correct? Can I change that location via YaST?


Here are some things to consider:

  1. The names sda, sdb, sdc and so forth are determined by how the hardware is plugged together.
  2. The Logical Drive names HD0, HD1 HD2 and so forth, as far as Grub is concerned, are determined by the /boot/grub/device.map file.
  3. The actual disk boot order is determined by the BIOS setup AND what ever drive you select as the boot drive, must be HD0 in your device.map file. The other entries may follow anything you like, but if you change who is hd1, then the same change must be made in your grub menu.lst file.
  4. The mapping location of the Windows drive is determined by the fstab file in the /etc folder. Changing how a drive is connected, has nothing to do with where it is mounted as long as it is the same hard drive.
  5. By default, the device.map file and the fstab file use the disk by id naming, which means it is normally immune to changing the physical connection of the drive. The Grub boot loaded is affected by this however.
  6. The grub boot loader can be placed in the MBR (Master Boot Record) or into partitions 1, 2, 3 or 4 ONLY.
  7. The grub menu.lst file must be located on the same hard drive as the /grub/menu.lst file is located. You can not boot from drive sda with grub and load the menu.lst file from sdb.

Thank You,