let user boot random unknown OSes by some kind of magic

[Eugenia Loli-Queru]

Binary package hint: base-installer

The installer didn’t even ask me WHERE I want Grub to get installed (on MBR or on the / partition). It overwrote my MBR without asking me, and not only that, but it doesn’t recognize my BeOS and FreeBSD partitions as bootable and so these OSes are not included anymore in the booting menu. I have no way to boot them anymore. Anaconda does this elegantly without confusing the newbies and without removing this important feature from the power users.

You need to add an extra screen at the end of the installation to ask the user if he/she wants to place Grub on MBR (keep as default so newbies won't get confused) or on / and maybe even allow the user to add/remove OSes from the list.

[William Grant (wgrant)]

Is this in the desktop installer (Ubiquity) or the alternate installer (text-based)? The alternate installer asks you about it, I believe...

[Eugenia Loli-Queru (eloli)]

This is the desktop installer. I don't know how to get to the text-based installe. It didn't seem to give me any choice about it.

[Colin Watson (cjwatson)]

Thanks for your report. This is also bug 41579.

[Colin Watson (cjwatson)]

The alternate installer is on a separate CD image, available from http://releases.ubuntu.com/6.06/

[Eugenia Loli-Queru (eloli)]

Please consider adding the needed screen on the GUI version of the installer. People don't want to download alternative CDs, they want the defaults. And they want the defaults (and good looking GUI installers) to do the right thing.

So, please **UNMARK** this bug as duplicate of the 41579 as I ask for two things instead of one:
1. Offer the choice of MBR and / (this part is a bit of a duplicate)
2. Allow the user to edit the suggested boot menu to add/remove OSes by clicking the /dev/hdaXX numbers and write names to each one of them (e.g. click on /dev/hda3 and let the user call it "BeOS")

[towsonu2003 (towsonu2003)]

> Allow the user to edit the suggested boot menu to add/remove OSes

I second that

[Colin Watson (cjwatson)]

In future, please file multiple bug reports as distinct bugs if you don't want them marked as duplicates. This is very helpful to those of us doomed to managing bugs as well as filing them. :-)

You do realise that a boot menu would need an enormous amount of UI to actually *work*, right? You can't just say "call it BeOS" - you need to know how to boot BeOS as well; and once you know how to boot BeOS, then you might as well just arrange for it to be added to the boot menu automatically. A UI on top of this process would not in my opinion add any significant value over automatic discovery.

[Colin Watson (cjwatson)]

I've removed the duplicate marking, but I'm afraid I'm going to reject this bug in its new guise, for reasons mentioned in my previous comment. I don't think "type in menu.lst chunk" makes a remotely sensible UI, and that's basically the only way to do this with unknown operating systems. Users who are capable of dealing with that UI would be just as capable of editing menu.lst themselves.

[Colin Watson (cjwatson)]

By the way, I'm happy to accept bugs against grub-installer or os-prober that ask for support for booting specific operating systems, particularly if they come with instructions on how to detect them (os-prober's job) and set up boot stanzas in menu.lst for them (grub-installer's job) that are detailed enough for me to go and write code; typically detection involves some kind of unique thing in the filesystem that lets you identify the operating system given only the ability to mount it. I'm just not willing to accept a bug report that says "please implement support for booting every other operating system", because with all due respect that is essentially impossible to close.

[Eugenia Loli-Queru (eloli)]

>I don't think "type in menu.lst chunk" makes a remotely sensible UI

I don't either. But you should not reject this bug. Here is how you should do it:

1. You add one more screen after installing the OS, to let the user decide if he wants the boot manager on MBR (default) or on /.
2. Below these widgets there is a button that says "more options".
3. By clicking that button you go to another screen that you detail the partitions one after the other vertically (each in its drop-down menu) and their names that are being assigned by the boot manager each in its own input widget (e.g. "ubuntu", "ubuntu recovery", etc)
4. Below these, there are non-selected drop down menus and blank input boxes (if more partitions are available). Through the drop down menu the user can select let's say /dev/hdb4 and then type next "BeOS".

That's it, the boot manager now should add BeOS to its menu and chainload it when selected. BeOS and FreeBSD and other OSes don't require special arguments in the boot line. You just load them as you would load a chainloaded Linux (that has another boot manager on its /) or Windows.

As to how to recognize these partitions: fdisk understands them. It understands both BeOS and BSD-marked partitions. And especially with BeOS, 99.9% of the time, if there is such a BeFS partition there, it IS bootable.

The way I propose to do it is doing some important things:
1. The main screen only has options for MBR or /, this is VERY important to be there so you don't nuke the existing boot manager. The way you do it now -- by nuking it-- it's UNFORGIVABLE.
2. The more advanced screen is only available to those who want it and understand it. The rest, they can just press "cancel" and go back to the previous screen.

You give this important option to those who need it, without confusing the newbies and without doing this terrible thing of deleting existing information. Ubuntu is plain destruction with the way you do it now by erasing the MBR. I am sorry, it is really bad way of handling one person's PC. Don't expect the person to KNOW that you would do that, you don't give such indication BEFORE installation!

Please, do something about it. And if you can't add the second screen (which IMHO is needed), at least the MBR screen is needed 150%.

[Colin Watson (cjwatson)]

I'm sorry, I don't buy the destruction angle at all. You get a working OS at the end of this installer and you can make menu.lst boot other operating systems with a pretty small amount of work. People with complicated multi-boot systems can handle editing a single configuration file. Don't throw terms like "plain destruction" around unnecessarily; it's crying wolf.

With regard to detecting BeOS and BSD, thank you, but it would help me considerably if you would file a separate bug about *just that issue*, like I asked. I also don't especially like relying on partition types; in my experience it is much, much more reliable to look at the contents of the filesystem.

[Eugenia Loli-Queru (eloli)]

AT LEAST, do offer a screen to ask the user if he wants the boot manager on the MBR or the /. This is the LEAST you can do, and it is something that it MUST be done, because EVEN if you are familiar on how to manually edit menu.lst, you still can wipe out significant work done by the previous boot manager on complex systems.

So PLEASE, hear me out on this. IF you don't want to add an advanced screen for non-Linux OSes, I kinda understand it, but you must add the screen for MBR and /. This MUST be there.

Sorry for the caps, but you really bring me in my ends. I had a perfectly working system with a perfectly configured boot manager (I used the BeOS bootman), and your OS wiped it out without asking me anything. This is LOSS OF DATA in my book and it's a usability bug of your installer. It must be fixed, you must add a screen about the boot manager.

[Colin Watson (cjwatson)]

That's the other bug that you TOLD me in CAPITALS this one wasn't a duplicate of! I've accepted that one. This one, I'm rejecting. Sorry.