Hi everyone!
Yesterday I had a big Automatic Update including kernel update (first time, I think). Since then I cannot boot, neither OpenSuse 11.0 nor WinXP:
The text “GRUB” appears, but I cannot enter any characters on the console.
I tried to boot from the install DVD, but booting from existing OpenSuse failed too.
I corrected from a live CD the grub menu (higher Kernel Version) but I had no success yet.
I have a backup (self made hourly snapshots by rsync on a 1x therabyte firewire disk). But I had a bad experience in restoring a complete 11.0 installation in one rsync.
I am not so skillfull, as this is my first thread/posting. I apologize.
(Hit by Murphy: I had just loaded 1300 pictures I had to process urgently (mainly DigiKam). Now, here we are!)
My Hardware: Mainboard Asus A8V DL, CPU AMD64 Venice 3200+, RAM 1 GB PC3200, Graphics Asus NT6600GT/128, HDD 2x Samsung 160 GB, WLAN Atheros, 1x DVD, 1x DVDRAM.
Are you getting the "GRUB . . . " after selecting openSUSE from the grub menu, or are you not even getting the menu at all?
Since you have a LiveCD, boot from that and in a terminal switch to root and mount your root partition. So if for example you mounted it at /mnt, then do the following and post the output back here:
cat /mnt/etc/grub.conf
cat /mnt/boot/grub/menu.lst
cat /mnt/boot/grub/device.map
ls /mnt/boot
fdisk -l
I think I am getting no Grub menu. Just on the black console, I get “GRUB” and a blinking underscore, while no input is accepted.
cat /mnt/etc/grub.conf
cat: /mnt/etc/grub.conf: No such file or directory
Did I ever had it? I started a search on my backup disk:
time find /mnt/backup/amd64n -path “*/etc/grub.conf”
Oh yes: while still not completed, the search found gub.conf on these occasions:
drwxr-xr-x 25 root root 4096 May 6 21:09 daily.4
drwxr-xr-x 25 root root 4096 Apr 24 16:12 weekly.0
drwxr-xr-x 27 root root 4096 Apr 4 23:08 weekly.3
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x1f4a1f4a
Device Boot Start End Blocks Id System
/dev/sda1 1 3825 30724281 7 HPFS/NTFS
/dev/sda2 * 5125 5137 104422+ 83 Linux
/dev/sda3 5138 13079 63794115 7 HPFS/NTFS
/dev/sda4 13080 19457 51231285 f W95 Ext’d (LBA)
/dev/sda5 13080 15435 18924538+ 83 Linux
/dev/sda6 15436 19457 32306683+ 83 Linux
Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00089a0b
Device Boot Start End Blocks Id System
/dev/sdb1 1 3917 31463271 83 Linux
/dev/sdb2 3918 7728 30611857+ 83 Linux
/dev/sdb3 7742 19457 94108770 5 Extended
/dev/sdb4 * 7729 7741 104422+ 83 Linux
/dev/sdb5 7742 8251 4096543+ 82 Linux swap / Solaris
/dev/sdb6 8252 13350 40957686 83 Linux
/dev/sdb7 13351 19457 49054446 7 HPFS/NTFS
Partition table entries are not in disk order
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0003c663
Device Boot Start End Blocks Id System
/dev/sdc1 1 12748 102398278+ 7 HPFS/NTFS
/dev/sdc2 12749 12761 104422+ 83 Linux
/dev/sdc3 12762 13271 4096575 82 Linux swap / Solaris
/dev/sdc4 13272 121601 870160725 5 Extended
/dev/sdc5 13272 115257 819202513+ 83 Linux
Disk /dev/sdd: 2021 MB, 2021654528 bytes
63 heads, 62 sectors/track, 1010 cylinders
Units = cylinders of 3906 * 512 = 1999872 bytes
Disk identifier: 0x6b736964
This doesn’t look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdd1 ? 435740 852923 814758329+ 74 Unknown
Partition 1 does not end on cylinder boundary.
/dev/sdd2 ? 340549 478536 269488144 65 Novell Netware 386
Partition 2 does not end on cylinder boundary.
/dev/sdd3 ? 137991 495994 699181456 53 OnTrack DM6 Aux3
Partition 3 does not end on cylinder boundary.
/dev/sdd4 ? 1001027 1001044 32672 bb Boot Wizard hidden
Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
I think some comments may help to describe what I intended to do with my partitions:
sda1 is my WinXP. sda2 is my /boot. sda3 is my pool for common data for Windows ans Linux, done by ntfs-3g. (/windows/D).
sda66 ist my /home.
sdb1 is my OpenSuse 11.0. sdb6 is my swap.
All the rest of sdb is unused (somewhere there is an older broken ubuntu 8.10).
sdc is an external disk ontaining backups for a couple of machines and operating systems. A real crontab backup covers hourly most suse and winXP-Files.
sdd is a memory stick, where I try to document what I do.
It’s pretty late here, I won’t be able to review the data until tomorrow.
Need to be sure about one detail: when you booted the LiveCD and got into the terminal as root, you did mount your root partition like this, right? -
mount -t ext3 /dev/sdb1 /mnt
and then, since /boot is on its own separate partition, you did?:
mount -t ext3 /dev/sda2 /mnt/boot
That is the only way that the data would be from your production system. This is also important because you could not find /etc/grub.conf - that file is a scriptlet created by YaST Boot Loader which is fed to the grub shell telling it where and how to install grub. During a kernel update, menu.lst will be changed but grub is not reinstalled, so to know where grub supposedly is, grub.conf tells us that. There are other ways to determine this, though. Previous copies of grub.conf from your backups are of no use here, unless you can be sure that your last backup was done after the last time grub was reinstalled; if that is the case, then post that copy of grub.conf back here.
Hy mingus725,
I see: you have a more elegant way to mount the installation (I had made a /mnt/root directory, my be fearing a name conflict, on a /mnt/boot. Did not know you can mount on mounted directories.
So, now I have changed to your method
umount /mnt/root /mnt/boot
rmdir /mnt/root /mnt/boot
mount -t ext3 /dev/sdb1 /mnt
mount -t ext3 /dev/sda2 /mnt/boot
Nevertheless grub.conf is still missing:
cat /mnt/etc/grub.conf
cat: /mnt/etc/grub.conf: No such file or directory
grub.conf from backup:
My latest /etc/grub.conf is in a backup from may, 6.09, and was written surely on a former installation of 11.0.
I have no recordings, but I know that, having messed up the installation, I quickly reinstalled OpenSuse 11.0, AFTER I had the backup working with crontab in April. That could have well been middle of May and so fit with the other dates.
First, let’s clarify /etc/grub.conf: Again, that file is created by the YaST Boot Loader module at installation, and re-created any time YaST is used to again install grub to a boot sector. It is simply a text file which contains the grub shell commands to execute for grub installation; YaST calls the grub shell and feeds it this file and grub then does the actual install. If during install you took the grub default, there must have been a grub.conf file at least that one time. But again, it is only used for grub installation; it has nothing to do with the execution of grub at boot. Note that grub.conf is an openSUSE technique; it is not used when installing grub manually from the shell, not is it used by other distro’s such as Ubuntu (and it is possible if there is more than one distro on a machine, for one of the distro’s grub install methods to mess up another’s).
Moving on . . . we need to be clear regarding the mounting you used from the LiveCD. You state that you changed to the method I suggested. Did you do that before the commands in your post #3?
Here is why: It is possible to have data in the /boot subdirectory that is stored within the root partition, and also to have boot data in a separate partition that gets mounted to /boot. This is not correct, but it is possible. When the boot partition (sda2) gets mounted to /boot on the root partition (sdb1), then that supresses whatever data is under /boot within sdb1. So if there are two sets of boot data, one on sda2 and the other under sdb1, and then sdb1 is mounted from a LiveCD, if sda2 is not mounted to the sdb1 mount point then when you look at the contents of boot, you will see the boot files on sdb1 rather than sda2. In short, we need to be sure that (a) the data you posted is in fact from the separate /boot partition on sda2 and that (b) in your production setup as defined in /etc/fstab, you are in fact mounting sda2 to /boot on sdb1.
There is more confusing data in what you posted. Look at the /boot listing - the kernel is 2.6.25.20-0.4. Now look at menu.lst. There is an entry referencing 2.6.25.20-0.1, a different older kernel, and this is the default. Then there is another entry for openSUSE 11.1 with the kernel version released with 11.1, that is, 2.6.27.7-9, residing on sdb4; plus - and this is very important - its stanza is pointing to another different menu.lst on sda2 with syntax indicating that sda2 is not a separate /boot partition but is a root partition.
Additionally, according to the menu.lst you posted, grub is not installed to the MBR. Either the “generic boot code” (which is DOS code) option was installed there instead, or (more likely) the Windows code was left there untouched and grub was instead installed to a partition boot sector. The code in the MBR is currently going to sda2 to find grub; there is grub code in that sector (that’s what you are seeing with “GRUB …”), but the pointer in that sector which tells grub where to find its loader program (/boot/grub/stage2) is wrong (which is why grub locks up).
Given all of the above, I can’t be sure what is actually where, and whether there is duplication, overlap, inconsistency (beyond the inconsistencies within the menu.lst plus between it and the /boot file listing), or errors.
So let me suggest this: We can just reinstall grub to the sda2 boot sector, assuming the inconsistencies are not real problems. If that works, then you can clean up menu.lst. If that doesn’t work, we’ll need to look again at exactly what is where on the machine. So . . .
Boot the LiveCD, open a terminal, switch to root, and do:
Hippyyyyeee! It works already! thank too you (an the crosses fingers) i have my old menu, 11.0 and WinXP are working. here a log of what happened:
su - root
grub
Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
setup (hd0,1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0,1)"... failed (this is not fatal)
Running "embed /boot/grub/e2fs_stage1_5 (hd0,1)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd0,1) /boot/grub/stage2 p /boot/grub/menu
.lst "... succeeded
Done.
quit
I understand that it is important to keep the installation clean. Your previous comments let me hopefully understand what happens, so that I can see what would make my installation messy.
Two things are now important to me to understand:
First, How can I avoid the same problem in the future? Surely I have to accept kernel updates in the future: how can I be prepared to thst? Why did that happen?
And then, I saw that swerdna here (Fixing Vista Multiboot) ]((http://forums.opensuse.org/install-boot-login/386603-fixing-vista-multiboot-opensuse.html)) is pledging for Grub 1n the MBR, while I put it on the boot partition.
Besides, I choose that because I had GRUB problems, both in WinXP and in Vista, whenever I choosed the MBR. (I simply tried to leave the Window disk untouched, as far as I can).
First, make sure you don’t have the duplicate data problem with /boot. Boot the LiveCD, mount your sdb1 root partition, and then look at the contents of /boot - it should be empty, because the boot files are supposed to be on sda2. If you find files under /boot on sdb1, delete all those and then double-check /etc/fstab to verify that sda2 is being properly mounted to sdb1’s /boot sub-directory.
Second, while booted into the system normally, look at the kernel and initrd versions on sda2, and make sure these versions agree with what YaST is showing as the kernel version. Once you’re sure that is all in sync, open menu.lst with a text editor as root and clean it up. The 3rd stanza indicates that 11.1 was installed at one time using sda2 for boot and and sdb4 for root; if true, you may have a mis-match in sda2. If 11.1 was removed, remove that stanza. The two windows stanza’s point to sda1 and sda3; your comment re Vista (note: in your original post, you didn’t mention you have XP plus Vista; always include that info as it can change the picture signficantly) suggests XP on sda1 and Vista on sda3 and if you installed Vista using MS’s default, then Vista’s boot manager was given control of booting XP. When you installed openSUSE or any later time you use YaST to suggest grub installation, openSUSE did not touch the MBR but instead put grub in the sda2 boot sector. Which takes us to your last question . . .
The approach you took leaving the Windows MBR untouched, was IMO smart (as was putting /boot on its own separate primary partition on the primary boot disk - the old traditional method now considered too advanced for users). I don’t know if you manually instructed openSUSE to take that route, but even if you had not, there is a high probability openSUSE would have done so anyway. While it is true that by far most of the time it is simplest to just let grub be installed to the MBR on a Vista machine, there are still a number of possible complications unique to Vista that create risk doing that. When there is a problem, Vista users rarely have the tools (a Vista Recovery Disc) let alone know-how to fix it. When the machine has both XP and Vista - which just the two together can easily create problems - and then grub is added to the equation, the probability of boot problems goes up significantly. Vista’s boot manager is powerful, but it is very difficult to administrate (which is why there are a couple very popular 3rd-party tools for this), and presumes to have control of the machine (so, for example, even if one has a working setup with another boot loader, a Vista upgrade can break that). In view of this, when a user has XP only or Vista only, and the machine’s disk setup is straightforward, then installing grub to the MBR is low risk. On a machine with both XP and Vista, the preferred approach is to install grub to a primary partition boot sector (which can even be the “extended primary”) and mark that partition active, leaving the MBR untouched; in this way the Windows code in the MBR chains to grub which along with booting SuSE can also chain back to Vista’s boot manager (this is your setup). There are some partitioning and/or bios setups where this isn’t possible and so require installing grub to the MBR or using Vista’s boot manager to boot openSUSE instead (which actually works quite well). Finally, given the number of different possible combinations in this equation and many Windows users’ unfamiliarity and nervousness in this area, that is another reason why for some it is again best to use Vista to control the boot. Clearly, this is an area where often there is not just a simple yes-or-no decision.
Hi mingus725,
Here some information which got lost (yesterday I had a hangup and reboot after an hour to answer to you, loosing the work, so I gave up and did only the minimum work.) Now again, (this info is only “IT Archeology”, but is good if there are misunderstandings):
11.1-I tried 11.1 on the desktop only once, as it came fresh from the announcement, beginning of November 08. I gave up because of Grub puzzling and missing Bluetooth, and fell back to 11.0. Surely I did reformat root. But if you do not reformat /boot it seems to remember all your Grub sins and dreams.
Vista- On the desktop I never had Vista. But I have tried dual boot with Vista and 11.1 (due to Intel graphic card) on the Asus notebook for my son. (After weeks of struggle it worked… one or two days, then Grub disappeared!) Vista is still working. But that is another story. When I have spare time I will open a new thread for it. I meant this yesterday
I had GRUB problems, both in WinXP and in Vista
So, you see, the situation is not so dangerous as one might think.
I have not yet done the cleaning job, but all seems ok.
Thanks for your help. You are a good teacher.
I’m not sure, but I believe your problem might be caused by the fact that you have run out of space on your /boot partition.
I had to rebuild my system yesterday because I tried to fix an error by using “chattr +i”, which is an immutable change that can not be undone even by root in suse (for security reasons).
When I rebuilt, two kernels installed because I am trying to set up vmware. I could not update. I finally traced the problem to a lack of disk space on /boot directory. Only 20 megabites is allocated to this partition by default, which partition is responsible for storing grub and the boot image. If “/boot” runs out of space it will cause problems such as you are describing.
To check how “/boot” is doing for space you can right click on it and look at properties under the “general” tab, if you can get booted somehow and mount the system.
Alternately you can look at the partitioning table to see how big “/boot” is. If you have a couple of kernel images stored in “/boot”,then you are probably out of space there. The 20 meg idea I believe came in years ago when the kernel was smaller, but I am finding out that it is not enough today.
I had decided to use LVM on this build, which I have never attempted to use before, and now need to figure out how to allocate more space to my /boot. I was able to do a work around to update my system by moving some of the files out of “/boot”, and then moving them back in after running the updates. The same might work to see if that is your problem with booting.
I hope this helps you. Have a lot of fun!
Can anyone tell me how to allocate more space to “/boot” when it is set up using lvm?