Problem with Yast/Grub and the root device

Another kernel update hit my system rendering it unbootable.

This happened also in the past and on prior versions of OpenSuSE (now I have 12.1). So far I was unable to find te root cause.

What happens:

The correct root device for my grub entries is (hd0,0). Hwever whenever Yast touches the file, as this time after th eonline update of the kernel it modifies all entries to “root (hd0)” omitting the “,0”. This renders the system unbootable until I modify this back via th erescue system.

Is there anybody who can give me a clue why this happens ?

Thanks,
Gaston

This is weird. I could explain why it would replace hd0 with hd1 (wrong device.map) but not why it replaced “root (hd0,0)” with “root (hd0)”. It doesn’t make sense, because this command can only refer to a partition and not to a disk. The only case where it would refer to a disk would be while chainloading the MBR of this or another disk, and it would use “rootnoverify” instead of “root”. For some reason the Perl BootLoader is unable to read your partitions. There is something wrong. Notice that the Perl Bootloader itself is quite buggy. But I suspect something is wrong or unconventional in your partitioning.

On 02/07/2012 05:16 PM, gaston67 wrote:
> This happened also in the past and on prior versions of OpenSuSE

and you logged a bug? but they didn’t fix the problem so you have it
again…is that right?

what is the number of your still open bug??


DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

On 2012-02-07 17:16, gaston67 wrote:

> This happened also in the past and on prior versions of OpenSuSE (now I
> have 12.1). So far I was unable to find te root cause.

Surely you wrote a bugzilla?


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Thanks for the hint. Not touching grub very often I am far from being an expert in it, and thus did not know about the possible impact of the device.map on this. But you were right the entry in it was showing the wrong (hd0). I fixed it now and hope it will restart correctly the next time.

Thanks !

Thanks also to the two other posters. I tried to apply the sacarsm but it did not fix the problem. But thanks to “please_try_again” I was able to figure out.

On 2012-02-07 23:56, gaston67 wrote:
>
> Thanks also to the two other posters. I tried to apply the sacarsm but
> it did not fix the problem. But thanks to “please_try_again” I was able
> to figure out.

No sarcasm intended, but serious advice. If system tools are writing wrong
entries, they must be reported.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Well, maybe the “puzzeled Penguin” is missleading, this is only as far as the forum is concerned. I am with Linux since 1993 or so, requiring a huge number of floppy disks to install it.

I would report a bug as soon as I would have clear indication it is a bug. Bugzillas throughout the world are full of topics that should rather fit into a forum IMHO. So far I did not have the time to investigate, thus I was fixing the problem myself each time. Now I wanted to take th etime to finally fix it. As I do not know where the wrong mapping comes from I don’t file a bug for it. Might have been me at some time whil emaniupulating with my own kernels.

Cheers,
Gaston

You can try to play with /sbin/update-bootloader. It’s the script which rewrites the menu after a kernel update.
Have a look at this post: http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/471406-how-does-yast-use-grub-4.html#post2434151

Yes this is the point where I am currently working on. i tried to install a new kernel and it failed because Perl-Bootloader is still looking for hd0. Th eolf file contained hd0 pointing to the boot partition by label. Now I have recreated the file via grub-isntall

However I did a mistake in my initial post, it is not the root= but the kernel “directive” which is wrong.

Ok, moved up to th ehigher level using yast2 bootloader instead of grub-install directly.

This generates device.map:

(hd0) /dev/disk/by-id/scsi-200193c0000000000
(hd1) /dev/sdb

Now seems to work with ‘make install’, but I am still investigating

On 02/08/2012 08:56 AM, gaston67 wrote:
> I would report a bug as soon as I would have clear indication it is a
> bug.

your experience (either long or short) in Linux has no bearing on what i
posted: there was no sarcasm in my post…look at it this way:

is it your opinion that you caused the error both times it happened to
you?

if so i understand it would be inappropriate to file a bug…

but if not, then if the problem was caused by the software–then please
WRITE a bug on the software…

or, if the problem was because the documentation is either incorrect or
incomplete–then PLEASE write a bug on the documentation…

either bug could/should lead to a better experience for all…

> Bugzillas throughout the world are full of topics that should
> rather fit into a forum IMHO.

if the point were for everyone to build a local workaround, with help
from a forum, for the problem they find then i would agree with
you…but, it is not the goal of this distribution to continue pumping
out faulty code that requires local patching…

and, unreported bugs take a LOT longer to squash…despite your opinion,
bug reports are one way you can contribute…and, you should.

by the way: i couldn’t/didn’t see the “puzzeled Penguin” which
apparently YOU thought i was responding to…but, that was not the
case…not at all…the fact is couldn’t see it because i don’t use the
web interface and those ‘ranks’ are not sent with nntp posts…

now, if you will like them removed (both yours, mine and everyone elses)
i’ll support that 100%…because, for example i know for sure there are
many folks here miss-categorized (some paint an expert such as
yourself as puzzled, and others paint the uninformed as omniscient or
flux capacitor (whatever that is!)…its all for the kids who never had
a title…and, it too often gets in the way!


DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

Now you see. It can not work. More exactly it will work up to a certain point. When you install openSUSE, BIOS drives get mapped to disk IDs. But when you update the kernel and device.map doesn’t exist, they get mapped to kernel devices. With your device map, there is a risk that both (hd0) and (hd1) refer to sdb.