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?
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
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# 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 - 2.6.34.7-0.5
root (hd1,1)
kernel /boot/vmlinuz-2.6.34.7-0.5-desktop 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-2.6.34.7-0.5-desktop
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 - 2.6.34.7-0.5
root (hd1,1)
kernel /boot/vmlinuz-2.6.34.7-0.5-desktop 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-2.6.34.7-0.5-desktop
###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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
Morning,
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?
The names sda, sdb, sdc and so forth are determined by how the hardware is plugged together.
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.
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.
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.
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.
The grub boot loader can be placed in the MBR (Master Boot Record) or into partitions 1, 2, 3 or 4 ONLY.
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.