Buggy 11.0 update?

There’s some recent update that’s hostile to my 11.0 install. I have an enterprise-level server that dual boots Win2k3Server and openSuSE 11.0 (both x64). All was going swimmingly for over a year, then the most recent update resulted in GRUB hard-crashing and restarting the system whenever I tried to boot SuSE.

I just finished reinstalling 11.0, and all was perfect until I did the online update - now I get GRUB error 17. Maybe it’s misdetecting the drives after the update?

sda swap and scratch Adaptec RAID0
sdb Linux & Win 500GB drive
sdc (not used) 500GB driveIt turns out that it was
sdd scratch 250GB drive

I’m in the process of reinstalling right now, but obviously I cannot afford to update until I get this resolved.
UPDATE: I can’t tell from the installer where exactly it’s putting the boot loader - only the “Boot from MBR” is checked, but does that mean sda? It seems like it would be better to boot from sdb, but I don’t really know how to do that - that is, I don’t understand the /boot directory and its relationship to the MBR - I think they’re distinct boot mechanisms, but there’s no option in the installer to boot from the MBR of different drives

Help!
Patti

EDIT: I should have said
sdb1 = win
sdb2 = swap
sdb3 = /
sdb4 = /home
… I checked “Boot from MBR” and “custom boot partition on sdb3” - - - I hope this works. The installer appears to have been installing the boot loader (by default) to the MBR of the RAID0.

EDIT2: OK, I had to uncheck the “Boot from MBR” to make it stop trying to MBR the sda RAID0 drive… (odd)

Patti, are you actually running openSUSE 11.0 or SLES 11??

you can check with

cat /etc/SuSE-release

if you are using SLES you need to be in a different forum…if you
are running openSUSE 11.0 then someone here should be able to help you
(not me, i think 11.x is mostly flakey (with regular upsets by what
should be rock solid updates…so, i’m still on 10.3)


brassy

Thanks - I’m running standard OpenSuSE 11.0

PattiMichelle wrote:
> Thanks - I’m running standard OpenSuSE 11.0

well…ok then…but, i still can’t help except to say that if you do
a full install while connected to the net it WILL (unless you stop it)
download all updates as part of the process…

there is a chance then that if will arrive broken (if there is
something about YOUR machine that breaks…OR, maybe it will all go
smooth and you never have another problem…

hard to say…

of course, you could get lucky and the guru you need finds your post…

another thing you could do (while waiting for competent help) is to
mine these fora for insight and possible fixes…here, try this in a
google search box:

site:opensuse.org “11.1” “GRUB error 17” update

but, sub in the exact error message…and, if you don’t have success
immediately then wiggle the input line some

ahhhhh…and, i’m not sure i understand what you are telling me with
that breakdown of drive…well i understand all except the “sdc
(not used) 500GB driveIt turns out that it was” what does that
mean?

i wonder if when you get the install done, before you allow the update
if you and do these one at a time in a terminal and copy paste the
output back to here:

cat /etc/fstab

df -h

df --print-type

sudo cat /boot/grub/menu.lst

(i THINK whoever trys to help might need those things…maybe, if
not: sorry!)


brassy

Updates during install is an option - they take a LONG time to do so I defer them to after install. sdc is simply not mounted anywhere - its a drive I use to “ghost” (G4L) my main drive so I don’t have to reinstall OSs in the event of a disk crash.

OK, so the reinstall just finished and now the bootloader is supposed to be on sdb (where Win and OS are). Presumably that will make the update work - but I really wish a guru would render an opinion on the problem before I risk needing another install.

I should reiterate that this system was stable for over a year and updates were done every few weeks - it’s only the last time (a few weeks ago) that the update rendered my OpenSuSE 11.0 unbootable (in fact, it entered an unending reboot loop). The problem was repeatable - after a reinstall (with MBR grub on sda) and update was unbootable (but this time it was GRUB error 17, not an endless reboot). being located on the raid0 MBR. (sda)

So something in that last update was hostile to my bootloader. I guess it’s not a major problem (assuming moving the bootloader to sdb works!) because probably nobody sets up on a raid0 MBR. Still, it worked for a long time.

i take it you skipped over my suggestion to see if you can’t find
the answer to your problem in the forum files…

hmmmm…see, most of the folks here read 11.0 and think OLD
stuff…and, don’t read past the subject line…

but, maybe you will be lucky…on the other hand i do remember a
flurry of questions about suddenly broken grubs in the last month…

you could, if you are so inclined, go to
http://forums.opensuse.org/search.php

and set the search from “A Month Ago”, and use words like “grub error”
to search “entire posts”…

here…there are only four with those terms, many one is spot on
http://forums.opensuse.org/search.php?searchid=1147297
if not get creative…or just sit and wait, and hope…


brassy

Thanks - I tried looking around the forums but didn’t catch a lot on RAID - then I had to run off to two meetings… <sheesh!> I think I may have found the problem: my last 11.0 install Error17’d during GRUB on first reboot, so likely that’s the source of the update problem (since this time I fresh-installed grub to the boot drive).

Trying 11.1 install I notice that my RAID0 is now called sdd (not sda as in 11.0) - so that flurry of broken GRUBs you mentioned is probably a result of a change in startup drive detection or else menu.lst syntax.

11.1 is installing… we’ll see if it has the same trouble.

I found the problem - the BIOS had the disks in the wrong boot order, and I guess Linux didn’t check the next disk in the BIOS chain for the files it wanted.

I also learned something - during install you can set the boot order - for some reason sdd (the adaptec raid) gets set as the first, so that’s where the install wants to modify the MBR for booting. I changed the boot order and the GRUB Error14 disappeared.

Now I’m doing a reinstall with setting the disk order in the installer so that sda is first - now it’s modifying the MBR of sda, as desired.

congrats! you done good!!


brassy

…funny that it didn’t have a problem with the disks in the wrong boot order until that one update a couple of months ago!