I don't know why but when I reloaded pclinuxos, the correct information was in menu.lst and was easily edited.

I recently installed Ubuntu 9.10. It did not properly recognize my other partitions where I have other OS's installed. As I learned the hard way it uses grub2 which does not operate from menu.lst but uses grub.cfg. It would not let me edit this file even though I used sudo etc.

I then reinstalled pclinuxos on its partition and it installed its own version of grub. It properly loads all but one of my other partitions. I wanted to edit its menu.lst in order to load this partition. When I went to /boot/grub/menu.lst I discovered that the listing there was not the same as the actually working menu.lst. Where is the correct file?

Please check this link http://ubuntuforums.org/showthread.php?t=1195275 It has tons of info about GRUB 2

If you are doing anything tricky during the boot, like booting into software RAID, or LVM, use the server version of 9.10. It will correctly configure your grub2 files so you forestall the crash course in grub2.

Just what is the advantage of grub2 over the original grub? If it ain't broke, don't fix it.

What's broke is, it is not being maintained and will not (and cannot work due to design flaws) on new BIOS features.

I hated to go to grub from LILO, so I had to learn LILO, and grub. Now it's time to learn grub2. Welcome to the New World. Hey! It's free. Rocket Scientists are building us cool stuff for free! Who am I to complain?

AFAIK, Ubuntu 9.10 comes with GRUB 2 default - so you don't have a choice out-of-box atleast.
And I completely agree with Jerre Cope :-)

Jerre Cope makes a great case for grub2 with one flaw. The purpose of grub is to allow booting of multiple partitions, for most people Windows and Ubuntu. If my experience is typical and I have no reason to think otherwise, when I installed Ubuntu 9.10, it did not pick up one of my other partitions correctly, i.e. in a way that I could boot to them. When I corrected my troubles as described above by reinstalling pclinuxos, it pick up every other partition.

I had a similar problem, with the 3 hard drives on my machine.

The bios allocated the 2 IDE drives as Primary Master/Slave, and the Sata drive, installed later, as Secondary Master. When I installed PCLinuxOS, it kept them in the same order, but when I later tried installing Ubuntu, it's Grub menu allocated the Sata drive first, and the other 2 second and third, and I couldn't boot into anything. I forget the Grub error number, but it's a conflict between the Bios and Ubuntu's Grub.

It's supposed to be possible to edit Ubuntu's Grub menu (using a live cd), but I couldn't get it to work, and just re-installed PCLinuxOS, which I'm quite happy with.

To Sheine; you mention trying to use sudo to edit grub.conf. sudo lets a user execute a program that normally only root can execute. It doesn't temporarily give you general root privileges. grub.conf is rw owner, which is root. As a user, you can't even read it. You need to either log in as root or execute su, which gives you root privileges.

To petern2; you may already know this but grub and Windows do not agree on the order of primary partitions in any single disk. To avoid making pre-existing Windows installations unbootable, I partition and format all of my primaries (including an ext3 for grub) using a Windows-compatible program and then tell grub to not create or format partitions.

Let's see some evidence for that statement. If you had problems in the past it was probably an issue with the distro you were using. The order of primary partitions is fixed by the structure of the partition table - 4 entries of 16 bytes each. Only Windoze boot-loaders check for primary partition and boot flag - the Linux loaders (including grub) don't care.
You are free to set up your system however you want - I do it all from Linux without problem.

To syg00; I first learned of this mismatch from Partition Magic documentation. I'm sure that it still exists because when all four primaries are created under Windows, fdisk -l (under Linux) mentions that the partition table is out of order. When you have successfully installed Windows using only Linux tools, I assume that you mean a fresh installation of Windows. I have also successfully done this. But Windows usually comes preloaded and pre-activated on new computers. I have found that allowing grub to format any other primary partition causes the preloaded Windows to become unbootable. If you have found otherwise, I would be very interested.

[QUOTE=David McCracken;3743498]To Sheine; You need to either log in as root or execute su, which gives you root privileges.

I tried to login as root with Ubuntu 9.10 but could not find a way to do it. It was difficult with the earlier version of Ubuntu 8.xx but I was finally able to do it, not with 9.10.

While somehow Ubuntu has become the most popular distribution, I have never been happy with it. Each version has some kind of serious flaw. In earlier versions, the only way that I could get the display that I wanted was to erase the Ubuntu version of the configuration file and replace it by one from another distribution like Mepis. Mepis and pclinuxos are the distributions that I find best.

I actually meant doing partitioning work from Linux. Never had a problem - with either Windows pre-installed, or doing it later. I have seen Windoze go non-bootable due to (Linux) installers marking more than one (primary) partition with a boot flag. The Windoze bootloaders won't tolerate this - and the Linux installer shouldn't do it. Easy to fix.
Partitions out of order is just a warning - logically they may not follow each other. Say:Nothing wrong with that, just produces messages from things like fdisk.

Or you can run "sudo vi grub.conf"; whatever your editor of choice is, and wherever grub.conf is.

That works if the editor has x permission for Others (all users)and is in the sudoers list for that user. In Fedora 11, nano and vi are installed with x permission for Others. Invoking them through sudo does give a user the right to edit OS files. However, emacs is installed with t permission for Others, preventing users from invoking it through sudo, regardless of the sudoers list. In any case, a user can't sudo an editor without root having modified sudoers and/or the editor program permissions. I think it would be a mistake to give a user who can't be trusted to become root (by login or su) the right to edit all OS files.

To sheine; When you had trouble logging in as root were you at the GUI login? I don't know about Ubuntu, but Fedora will not allow you to do this, considering it a security risk. You can invoke a VTTY (e.g. Ctl-Alt-F2)from which root should be to log in.