In Suse 12.2, Legacy Grub (aka Grub/Grub1) controls multi-booting of Windows and other Linux distros like Fedora, Mint, etc. via YAST > Boot Loader > …> /boot/grub/menu.lst
However, after installing openSUSE 12.3 RC1 where Grub2 controls the same sort of multi-booting, I see every other operating systems on the Grub menu except Fedora 17.
So, how do edit Grub boot menu to add Fedora? Which file should I use? Et Cetera?
It should not be necessary. It mounts partitions automatically. If it does not detect Fedora 17, there is a bug somewhere. os-prober logs into /var/log/messages, so seeing logs at the time os-prober was run would help.
It is definitely not necessary. However, if os-prober fails to detect an OS (because it failed to mount its root partition read only), mounting this partition once will help os-prober to detect the OS - even if you umount the partition (cleanly) BEFORE running os-prober.
Anyway, it’s probably that old bug I reported a while ago, I’m deeply sorry, Andrey, I could not test your patch because:
I can not reboot any system at the moment
It is reproducible but you can not reproduce it any time, and of course not when you need it*. If you mount/unmount the file system, then you fix the problem (the foreign distro get detected next time you run os-prober, but then you won’t be able to reproduce the bug - until you reboot and shut down the other OS, at some point)
I really don’t have time, sorry.
My port of os-prober uses an environment variable which clearly shows if mounting a file system failed.
Several people reported similar issues. I hope they would try your patch.
A warning though: when you have this problem,** DO NOT mount the root partition of the foreign OS (if you want to help us fixing the bug)**. If you mount the partition and keep it mounted, os-prober will detect the OS. If you mount the partition and umount it, then run os-prober, it will work as well. In both cases, it will solve your problem (add the missing boot entry), but you won’t be able to say if the patch is working.
12.3 RC1 should prefer grub2-mount which may have different behavior. It still may fail if there is large amount of uncommitted changes in journal (I have once seen grub2 that could not load modules from ext4 - just rebooting magically fixed it), but I’m afraid adding in-memory journal replay is not something that can be done quickly.
Absolutely. That’s why it is so hard to reproduce. I’ve seen this bug “often” but on systems which used to reboot 50 times a day.
If openSUSE os-prober can not detect another Linux, what is going to help is to reboot that other Linux, not openSUSE, where you are running os-prober. Usually - most of the time - it does help indeed. But at some point you will shut down and reboot that other OS, and os-prober might not find it next time.
Notice that it already happened that Ubuntu or Fedora didn’t detect openSUSE. It can actually happen any time in one or the other way.
For the user who just wants a boot entry for the foreign Linux to be added, mounting the root partition will do it.
Well, I thought about this approach too - a while ago - but then, we agreed that os-prober should rather not rely on grub2 (didn’t want to have to install grub2 in order to use os-prober). But I understand what “should prefer” means. If it doesn’t find grub2-mount, it will use its internal functions. Looks like you just reversed the order of preferences.
BTW, looking at the title of this thread: it is 12.3 RC1. Thus, it should have worked
No. Upstream os-prober always preferred grub-mount. It just was never adapted to grub => grub2 name change in openSUSE and continued to look for grub-mount which does not exist here instead of grub2-mount.
Hmm … Yes, I see what you mean. I don’t remember if I fixed that little bug or not. I know that I added a couple “2” after some commands for openSUSE in some os-prober scripts. Unfortunately it won’t help: the same problem occurs under Ubuntu, unable to mount openSUSE for example from time to time, and os-prober on Debian, Ubuntu, etc, has been using grub-mount since the beginning (because it is called “grub-mount” on Debian).
Is that actually what you meant in your patch: replacing grub-mount with grub2-mount? If so, I can already tell you that it won’t help. grub(2)-mount might fix other bugs, but not that one (AFAIK).
I have found this tool mentioned in several threads with Grub2 problems. The one above lead me to trying:
boven:~ # which os-prober
/usr/bin/os-prober
Yes, I have it too! Thus:
boven:~ # man os-prober
No manual entry for os-prober
boven:~ #
Ohoh. And
boven:~ # info os-prober
does not reveal much more. Last resort:
boven:~ # os-prober --help
/dev/sdb: open failed: No medium found
/dev/sdc: open failed: No medium found
/dev/sdd: open failed: No medium found
/dev/sde: open failed: No medium found
No volume groups found
/dev/sda2:openSUSE 11.4 (i586):SUSE:linux
boven:~ #
Oops, despite my trial to NOT run any functionality of the tool except the help message, it does run. I am presumably lucky that it is a read-only thing.
IMHO it realy needs some more attention before it can be welcomed as a valuable member of the Linux tools family
Do you volunteer to write the documentation?
os-prober is actually not very difficult to understand (and improve - which we already did). It’s just a bunch of shell scripts. You can read them and see what they do.
But of course, you’re right. It needs a manual page and some --help and --version options. I’m sure Andrey will implement them in factory in half an hour or so…
Of course I know all these things and I do admit that I am only human and thus not free of:
finding it nicer to design and code then to write documentation;
telling other people that they should deliver a complete product instead of only the coding and leaving it to the user to find out what it is for, without making an offer to help in writing the docs;
thinking that everything should work from day one as intended.
And more of these. I also know that I am in the world of volunteers here and thus must accept things as they are, or do something myself about it. Now, my silly thought is that by pointing (say only once a year) to the fact that a product is not ready without it’s doumentation and that praise to the makers of a product (one of the few rewards of the open source volunteer) will increase definitely if good docs is available might be a tiny contribution to the world of FOSS on it’s own.
That said, I am willing to help with this, but somewhere I allways think that people who made something are the best onece to explain about their product (but there are people that are good at software and very bad at writing user oeriented docs, I admit). I do not know what expertise is needed, but implementing a --help function in a script (what script language) might be within my level of knowledge (though I am a bit lost where it is a bout good practises in coding parameter pasring and it seems that there is none in os-prober at all to expand on). For creating a man page, I never did that and the correct formatting might be a bit to much.
EDIT: found out that os-prober is a POSIX shell script.
os-prober is a work of many contributors (including myself and @arvidjaar), and upstream is on Debian, hence the bugs with the missing “2” (grub vs. grub2) mentioned earlier.
That’s for sure. Not any developer is a technical writer (it’s actually a separate job).
Not much … however I was to lazy to do it (or didn’t want to modify the os-prober main script) and added once a debug flag in form of an environment variable instead of a command line option. :shame:
Yeah … I use getopt rather than the buildin getopts (which only works in bash). Don’t know how good or bad it is, but I agree that it’s tricky.
Also usefull. I glanced through the os-prober script (and the included text), but there is not even one line about what the thing is made for. While I have a vague idea why it was made and what it is supposed to do, I wonder if that vague idea (only based on reading parts of threadds here) is enough.
It reminds me of those products that soetimes are mentioned in threads here, people having problems in installinng them. They then point to websites. I then try to see what the product is about and go to the website (and when the URL points to a download page or so, I go to the home page there). I often read twice through that home page and still had no clue at all what the product should so. Often not even a vague idea if it is scientific, game, whatever. A lot of clairvoyance is asked from people these days.
BTW my idea is that we are realy hijacking this thread now. Maybe we shold go for another place?
On 2013-02-15 14:06, Knurpht wrote:
>
> Moved and open for posting.
Saw this too late and posted one post at the wrong place.
If you can delete it, please :-?
On 2013-02-15 12:46, please try again wrote:>
> hcvv;2527374 Wrote:
>> (but there are people that are good at software and very bad at
>> writing user oeriented docs, I admit).
>>
>
> That’s for sure. Not any developer is a technical writer (it’s actually
> a separate job).
Where I trained, technical writing was part of the curricula.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)