I had a 10.3 (x64) system that I wanted to update to 11.0. I went through the update procedure and rebooted. After I rebooted, entered grub, and selected the OpenSUSE 11.0 line, I got a text screen with the following:
root(hd0,1)
Filesystem type is reiserfs, partition type 0x83
kernel /vmlinuz root=/dev/disk/by-id/
sci-SATA_WDC_WD2000JB-002D-WCAL81036637-PART2
splash=silent
Error 15: file not found
Press any key to continue
The setup I have is that /dev/sda7 contains the root partition and /dev/sda2 contains the boot partition (/boot), and /boot does contain vmlinuz.
Although I could probably reconstruct the necessary lines of /boot/grub/menu.lst, I haven’t found a way of entering them during the Repair Installed System procedures. I can get to the point of repairing the boot loader, but the lines shown there don’t directly correspond to the contents of menu.lst. I can’t even mount the partitions from a command line in a secondary terminal – the device /dev/sda isn’t recognized, and the contents of /dev are just null.
I also noticed that after my attempted repairs to the boot loader and exiting, I got the red screen with the message An error has occurred.
I have just one IDE drive, 150 GB. I’m able to do an fdisk by going into a second console with Alt-Ctl-F2, and all the partitions appear to be as they should be. I was even able to look inside them from the second console, provided that I got there by attempting a repair (it wasn’t successful) of the boot loader using the install DVD. At that point all the partitions were mounted as subdirs of /mnt – but not before. That’s how I determined that vmlinuz was really there.
I don’t understand the comment about making sure that grub is going to the right place. There are two paths I might take: trying to make the repair by doing something on a normal start, or trying to make the repair through the procedures on the install DVD. Which are you suggesting?
Would replacing the MBR be likely to make things better or worse? I’ve held off on doing that for fear that it would make things worse. The explanation of Error 15 in the grub manual says:
This error is returned if the specified file name cannot be found,
but everything else (like the disk/partition info) is OK.
That would seem to suggest that the MBR is OK.
I’m working by using a second machine to collect documentation, converse on this forum about the problem, etc. So, for instance, when I get a grub error I can easily find the explanation. Of course, the ill machine is not in communication with anything else.
If sda7 is the root partition, then the kernel line in menu.lst is wrong. That is what’s causing the error. It should be “. . . PART-7” (which is using the Device-ID); you can change this to be the Device-Name, /dev/sda7.
To fix this in the Repair System, go into Expert mode. On the Boot Loader Settings tab at lower right click on Other, then click on Edit Configuration Files. In the pull-down choose menu.lst. This is actually a little text editor. Make the change to the root clause on the kernel line, click OK, click Finish.
This can also be done from the Rescue Mode, but that is more complicated.
From Expert Tools, my choices are:
Install New Boot Loader
Repair File System
Recover Lost Partitions
Save System Settings to Floppy
Verify Installed Systems
Nothing about “Edit Configuration Files” there.
So I chose “Install New Boot Loader”, and my choices for each line were Add, Edit, and Delete (obviously, Edit is the right choice here). The displayed line to edit was:
image append= splash=silent showopts,image=/boot/vmlinuz,
initrd=/boot/initrd,
root=/dev/sda7
If I try to edit it, I don’t see the line by itself; instead I see individual fields:
Section Name
Kernel Image
Initial RAM Disk
Root Device
VGA mode
with values that agree with the line above. So I tried (again) to just accept that. I got the message The boot loader was installed successfully. I pressed Next, then Finish, and got the message An error occurred during the installation, in red.
At that point I rebooted and got exactly the same behavior as before; the grub line had part7 instead of part2 (as you suggested).
Somewhere /dev/sda7 is getting transformed into that /dev/disk/by-id/ line, but that may not be the problem.
Since /boot/vmlinuz is in the /dev/sda2 (boot) partition rather than in the /dev/sda2 (root) partition, I thought that the boot should be into /dev/sda2, not /dev/sda7. However, I tried it both ways and neither worked.
Well, I found the immediate cause of the problem: the files in /boot were symlinked to their debug versions, not their default versions – and the debug versions did not exist! Through the rescue system I was able to correct that and then got partway through the boot.
Now I got stuck at a different stage: udev was unable to create the device nodes because /sbin/udevadm does not exist.
So —
(1) Why the erroneous symlinks in /boot after a perfectly ordinary upgrade procedure? Looks like a bug, but if it is, why haven’t a lot of other people encountered it?
/sbin/udevadm doesn’t exist because the device node for /dev/sda7 (the root partition) hasn’t been created yet, it seems. But it can’t be created unless /sbin/udevadm is there!
I was in the process of writing instructions to get the boot setup corrected. I know you think that is fixed, but I wonder . . . when you boot, hit the Escape key to drop the graphical screen to text and watch for the root partition (sda7) being mounted. The error you’re seeing may be due to it not being mounted.
If you want to revisit setting up the boot again, post that back and we can do that.
By the way, you wouldn’t happen to have a Live-CD by chance?
I can readily believe that the root partition isn’t getting mounted. I forgot to mention that the system starts up in text mode, not graphical mode, so I can see exactly what’s happening, and I see no indication that /dev/sda7 is being mounted. (The system should, of course start in graphical mode.) So what can I do to cause the root partition to mount?
I assume that once I have a running system it will be much easier to fix the bits that are wrong.
In my latest experiments, I’ve noticed that the version of menu.lst that’s getting loaded on bootup seems different from the one that I configured. How does the installer determine where to put menu.lst?
The installer doesn’t determine where to put menu.lst. It always goes exactly in the same location, under /boot/grub.
I know you aren’t using the Live-CD. I asked if you have a Live-CD available (it doesn’t have to be openSUSE, it could be Knoppix, Kanotix, etc.)? That would make this a lot easier. In this vein, might you have previously installed a command line editor like nano or pico, or have you ever used vi or vim?
I’d like to see exactly what /boot/grub/menu.lst now looks like. With the various attempts you’ve made, that’s unclear. If you have a Live-CD, you can boot that, mount sda7, and copy/paste the contents from a terminal. If you only have the DVD, you’ll have to copy it by hand. We only need to see the first boot stanza, so just those several lines. Here are the commands after booting into Rescue System as root, or can be used from a Live-CD in a terminal window:
mount -t reiserfs /dev/sda7 /mnt
cat /mnt/boot/grub/menu.lst
After you post back, I’ll give you instructions on how to install/set up the boot loader as necessary. If we have to do that from the Repair System it’s a bit tricky, but it can be done.
Good. Besides making it easier to get the info to post back here, I think it will be preferable to just use the CD to fix menu.lst and even re-install grub if necessary. That DVD Repair System boot loader installation module is flakey, and doing this from the Rescue System is not easy.
Turns out I didn’t need to load a live CD at all – from the rescue system, I just mounted /dev/sda2 as /mnt/boot and did the cat to see the contents of menu.lst. Here are the essentials of what I got (manually transcribed, inessentials omitted):
gfxmenu(hd0,6)
title openSUSE 11.0
kernel splash=silent showopts
What’s striking about that is that there are no drive-specific entries for openSUSE 11.0 (in my latest attempt, anyway).
I have another idea on how to get past this problem and get the system loaded, thus giving me full facilities for fixing the problem. Suppose I call grub explicitly from the rescue system. I can do that – I already tried. If I just knew the right sequence of grub commands, I probably could just load the 11.0 system that way. So far I haven’t found the right sequence.
Just to reiterate the essentials: my boot partition is /dev/sda2 and my root partition is /dev/sda7. The boot partition contains /boot/grub/menu.lst, vmlinuz, and initrd, as it should.
One mystery we haven’t talked about is why I’m getting that red message An error has occurred from the installer. The other one is why vmlinuz got symlinked to the nonexistent debug version of the kernel instead of to the default version, which does exist (same problem for initrd).
I tried the following sequence of grub commands from the rescue system:
grub> root (hd0,6)
Filesystem type is reiserfs, partition type 0x83
grub> kernel (hd0,1)/vmlinuz
[Linux-bzImage, setup=0x1e00,size=0x1832e8]
grub> initrd (hd0,1)/initrd
Error 28: Selected item cannot fit in memory
grub> boot
At that point I was instantly bounced back to the command prompt. I have no idea why. Despite the initrd problem, I would have expected the boot to at least start up.
I think the reason that /dev/sda7 can’t be found on bootup is that udev is either defective or missing, so the device nodes never get built. I tried the update procedure again (from the install DVD) and noticed that it wanted to remove udev because of some versioning problem. Previously I had accepted that default, but perhaps that was a mistake. I’m trying it the other way now.
The problem, it seems, was that the update procedure found some apparent problems with udev and a couple of other packages, and recommended removing them. That was the wrong recommendation. I updated yet again (11.0 -> 11.0) but included some additional repositories and rejected those defaults.
Sorry, but just trying things without understanding how these tools work is not going to resolve the problem; it’s only complicating matters. . . the menu.lst you see in the Repair System is not the one on disk, you cannot boot the system from the Rescue mode, the red message is inconsequential . . . OK?
Please boot from the Live-CD, open a terminal window, switch to root, and mount /dev/sda7 and then mount /dev/sda2 -
mount -t reiserfs /dev/sda7 /mnt
mount -t reiserfs /dev/sda2 /mnt/boot
Note: I don’t know what Live-CD you have. The above will work with most. If you get an error on /mnt not being there just create it (mkdir /mnt) and then do the mounts. Now list the contents of the menu.lst on disk, and get a list of the files under /boot, and post all that back here -
cat /mnt/boot/grub/menu.lst
ls -l /mnt/boot
ls -l /mnt/boot/grub
I will then be able to give you exactly how to fix menu.lst, and we should probably re-install grub to be sure. We will do all this from the Live-CD. Please leave the Repair System and Rescue System alone for now.
Since repairing the udev misconfiguration brought my system back to life, I was able to use my OpenSUSE 11.0 system to collect the information you asked for. I still have the problem that the Windows partition won’t boot; I just see the lines from menu.lst and then it stops. Here is the information you asked for:
The Windows partition was working before the 10.3->11.0 upgrade. I’ve tried several variations on the Windows section of menu.lst but haven’t yet found one that works. I’m wondering if somehow the MBR got messed up. Here’s the output of fdisk:
Lactarius:~ # fdisk -l /dev/sda
Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc14bc14b
Device Boot Start End Blocks Id System
/dev/sda1 1 13 104391 6 FAT16
/dev/sda2 * 14 26 104391 83 Linux
/dev/sda3 27 23684 190032885 f W95 Ext'd (LBA)
/dev/sda5 * 27 3850 30716248+ 7 HPFS/NTFS
/dev/sda6 3851 3978 1028128+ 82 Linux swap / Solaris
/dev/sda7 3979 6589 20972826 83 Linux
/dev/sda8 6590 8548 15735636 83 Linux
/dev/sda9 8549 12465 31463271 83 Linux
/dev/sda10 12466 13771 10490413+ 83 Linux
/dev/sda11 13772 15077 10490413+ 83 Linux
/dev/sda12 15078 16383 10490413+ c W95 FAT32 (LBA)
/dev/sda13 16384 22462 48829536 83 Linux
I’m able to mount /dev/sda5 and read its contents, and it looks fine.
Is the system booting now normally into openSUSE? It looks like you got your menu.lst sorted out for SuSE. Assuming so, for Windows then (I need to know all of following) . . .
First, did you install grub to the MBR, or did you install the “generic boot code” to the MBR. (Those are two different things.) Do you know if you installed grub to the sda2 boot sector?
Next, what is on sda1? Is that the Windows “system volume” (which is MS terminology for the partition from where the boot is controlled, which holds the Windows boot loader files)? Given that the Windows “boot volume” (where the OS is; I know, the MS terms are backwards) is on a logical, sda1 must be the system volume (because Windows can’t boot from a logical).
If grub is managing the boot, the MBR is not the reason why Windows isn’t booting. When grub chainloads to Windows, it is directly handing off to a boot sector; the MBR is not in the equation at all. Once I have the above info, we’ll know what the fix is.