Just updated M7 from Factory OSS. Get a pretty new boot menu but the updated
system is no longer on it. Nice one guys!
–
Graham P Davis, Bracknell, Berks., UK. E-mail: newsman not newsboy
“I wear the cheese. It does not wear me.”
Updater made me choose between kernel-default and kernel-default-base, while both are needed (your problem AFAICS). Ever since I run Factory I always check /boot/grub/menu.lst after kernel update. It was almost empty after update (no menu lines).
I installed kernel-default-base after the update. The menu.lst was ok afterwards.
What a lovely new Grub screen.
P.S.
Yup, taking care that kernel-$FLAVOR-base is also installed avoided me falling into that little trap (although I always check menu.lst after every kernel update to be on the safe side).
As a multi-booter and always with openSUSE 11.1’s Grub booting from mbr, I have to check and edit /boot/grub/menu.lst after every kernel update, because it drops the odd parameter, or changes disk addresses in other distro definitions, within the menu.lst of openSUSE.
Make a grub partition!
Making a Dedicated Grub Partition
Makes life sooooo much easier.
(I think some people put knoppix on it too, as a rescue - I reason if you’ve got more than one distro there’s little point.)
…also, the point of transferring the important information from the distro’s menu.lst across to the grub partition’s one, when you can just let the distro’s bootloaders do the actual booting, eludes me.
My menu.lst looks like this.
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
title Suse
rootnoverify (hd0,1)
chainloader +1
title Arch
rootnoverify (hd0,2)
chainloader +1
title Debian
rootnoverify (hd0,6)
chainloader +1
And I haven’t broken it yet. 
All testers should know how to use the grub menu editor
Agreed, but shouldn’t we keep it simple for those don’t?
Correct me if I’m wrong,but I thought we were doing this testing with an eye toward making 11.2 simple for Windows converts & newbies. After all when they come in they won’t have a clue about grub.
Not really these aren’t rcs now were they rcs then you have a very valid point but these are snapshots.
Put it this way you have 2 ways of dealing with them you can grab a snapshot and you find a glitch… Now you can prowl through the bug reports and the mailing lists or hit update and pray as you may find it has been fixed.
Now either way you will find the bug but without some crude understanding of bug shooting which does include using cli grub, if not then it is nothing more than a looksie. Devs haven’t got the time to talk people through the simple things in tracking bugs.
Anyone bug shooting should have some basic skills even if that is as simple as actually getting a gdb bt without even understanding it, and to be able to eliminate where in the stack a problem maybe. If not then it is nothing more than a looksie and not much help to a dev. Now you may find someone on the forum or perhaps the mailing lists willing to assist. But… you may also come away with works for me, or simple one liners, or short replies of read the mailing list. Either way will leave most users with a bad taste. So eliminate it go in with the skills that can assist, you don’t have to be able to write a patch but you do need to be able to investigate a bug, and give a decent report on the problem and be able to research it.
All in all I’ve got a little fed up as it seems a few of us have, of people running milestone releases like it is the latest. Regardless of how many times they get told, it seems we have an influx of them at the moment.
Simply put devs like wheat not chaff.
Not sure why you had to say this. My point was that even openSUSE 11.1 fiddles with grub entries in ways that it shouldn’t.
Grub was designed so that a single menu can be configured to directly boot from multiple partitions. The “chainloader” command wasn’t originally included for the purpose of booting from partitions, as it results in a second boot menu. If you don’t believe me, you can read it in the grub documentation.
Thanks, but you’re welcome to it. It’s an old lash-up, and yet another partition - already use a /boot partiton. There are users (not me) worrying about reducing boot times by shaving a few seconds, and here you are adding more seconds (8) each time you boot to a second menu.
I agree your point about the need to add knoppix i.e. no point.
I think it’s possible to overstate this - but then perhaps I would, I’ve never backtraced anything.
Obviously expecting basic help with a development release is unreasonable, and if you are going to run one a willingness to attempt to learn technical bug tracking (within reason) if asked certainly helps - but a reproducible bug report is always better than no bug report, even without technical detail.
@consused: fair enough! Works for me… 
The fact you knew it was a backtrace puts you in the right direction so here I think we agree
I never said you would use it. I have had to send one in for bug shooting and did have some help, that was when I realised my bug shooting skills could be a lot better and sucked. Asking devs how to do a bt is quite a humbling experience I was just grateful I encountered guys with time.
@ Feathermonkey from Sagemta
Okay, thanks for the explanation it made sense. Until I read your post I thought that we were supposed to looking at all aspects from square one from the view of someone who’d be using 11.2 for the 1st time. Now I see it’s a case of all things in their time.
dale14846 wrote:
>
> All testers should know how to use the grub menu editor
>
>
I know how to use the editor. Getting it to do what I want it to do is the
next step.
Anyway, I don’t see that as a necessity. What a software designer wants is
lots of testing by users running the software in a situation as close to
their usual operational system as possible. It doesn’t matter how
technically savvy they are, just that they are able to provide bug reports
with accurate details of how to reproduce the problems - or at least that’s
what I wanted from my users.
–
Graham P Davis, Bracknell, Berks., UK. E-mail: newsman not newsboy
“I wear the cheese. It does not wear me.”
There’s a big difference between the Milestone releases and the RC’s. The first are just snapshots, the latter have an ‘almost ready’ status.
Years ago I messed up my system by kicking the power switch on the back of my computer, trying to connect headphones. This happened during kernel update, it was halfway installing. Somebody suggested a week of 1 hour per day reading on GRUB would make me feel more confident. This has been one of the best suggestions in my linux life. GRUB is not that complicated, it scares us, because it’s about booting/not booting. If not booting, then what?
For average every day users, GRUB should reach perfection. Many people only have the one computer that won’t boot.
The huge masses going for Milestones as the latest and greatest worry me too. Thoughts like “if you don’t know how to solve this, don’t run Milestones” come to my mind too often. Maybe some sticky ?
Knurpht wrote:
> The huge masses going for Milestones as the latest and greatest worry
> me too. Thoughts like “if you don’t know how to solve this, don’t run
> Milestones” come to my mind too often. Maybe some sticky ?
You think the huge masses will (a) know where stickies are - or even what
they are - and (b) read them?
Perhaps the download page should contain a general warning - in big red
letters?
–
Graham P Davis, Bracknell, Berks., UK. E-mail: newsman not newsboy
“I wear the cheese. It does not wear me.”
The Grub editor and being able to use it is a basic survival skill for
testers. I have been teting since the tail end of 10.3 and I can’t tell you how many times Grub has been broken.
of course being diligent and checking the boot loader before doing a reboot would be best and ls /boot and being sure that
initrd has been built would be wise too. if it hasn’t a simple mkinitrd does that trick.
btw what is emerald
Yes indeed, not only for testers but also a knowledge of Grub for everyday users of openSUSE. The forum help sections are littered with past grub problems.
consused wrote:
>
> dale14846;2041128 Wrote:
>> The Grub editor and being able to use it is a basic survival skill for
>> testers. I have been teting since the tail end of 10.3 and I can’t tell
>> you how many times Grub has been broken.
> Yes indeed, not only for testers but also a knowledge of Grub for
> everyday users of openSUSE. The forum help sections are littered with
> past grub problems.
>
>
All of which confirms that GRUB needs fixing. Why doesn’t GRUB recovery work
properly? When I make a fresh installation on a machine with two or three
other OS’s, they are recognised and appear in GRUB. Later, if GRUB gets
mangled, I should be able to use the same installation disk to re-make GRUB.
It gets remade but where are the other systems? It can recognise them one
time but not another? All I get on the GRUB menu is one OS plus a floppy
drive - which I don’t have.
I agree that knowledge of GRUB and how it works is useful but no way should
it be a necessity.
I was a designer of interactive software some twenty to thirty years ago and
there is no way I wanted my customers to have to get under the bonnet and
tinker with the machine. In fact, I had to make damn sure they couldn’t do
so.
–
Graham P Davis, Bracknell, Berks., UK. E-mail: newsman not newsboy
“I wear the cheese. It does not wear me.”