1 Topic by lsatenstein

  • lsatenstein
  • New member
  • Offline
  • Registered: 2009-05-18
  • Posts: 6

Topic: Semi-autobuild of menu.lst (grub.conf)

This is really related to the PC platform. Perhaps too, it would apply elsewhere, (power PC).

One gparted is running, we can see the partition layouts.

What would be the problem of allowing one to flag a partition as bootable, and to suggest a name (name by default could be the /sdaxxx (xxx is the partition number).  If I have 3 or 4 drives on  the pc, and I have 4 operating systems, I would really line to flag (gui mode) the partitions that are bootable, and after selections, hit a generate key, and I would have a menu.lst from which I take the title lines and replace them with names of interest to the person doing the booting.

I could flag  hdo as the boot drive,   and the partitions and voila,  a working menu.lst.

Ideally, following up on another idea, would be the creation of a grub partition in which grub would place its stageX files and the menu.lst.   

Grub and partition editor are twinned and need to go hand in hand.

2 Reply by stormhead

  • stormhead
  • Member
  • Offline
  • From: near Frankfurt/Main, Germany
  • Registered: 2008-07-31
  • Posts: 264

Re: Semi-autobuild of menu.lst (grub.conf)

Hi!

Partition names depend on the kernel you use. On recent Ubuntu release, for example, I'Ve seen IDE drives addressed as SCSI devices (/dev/sdX, where IDE drives are traditionally referred to as /dev/hdX). If you create a menu.lst on a system that addreesses everything as SCSI and insert it into a system that diastinguishes between IDE and SCSI (or vice versa), you'll run into troble booting.
Another thing is that if you have more than one IDE (or SATA) controller in your system, the device naming will depend on the order the controllers are initialized. Imagine you have the OnBoard IDE controller plus an UDMA/133 PCI card - one kernel will probe the OnBoard controller first, so the drioves attached here will start from /dev/hda, and the PCI card gets /dev/hde and so on. Another kernel might probe the PCI card first, so the drives connected there will be /dev/hda ans so on, while the OnBoard controller starts from /dev/hde. As a result, the Linux systems referred to in your GRUB configuration would mix up file systems - and you may get a system that behaves "slightly" different from what you were expecting, data is missing and so on.
As a last point, the menu.lst does - especially for Linux systems - contain a lot more than "only" the partition names - you'll find the complete path to the kernel image, along with a set of parameters passed to the kernel during boot-up. Both parts - file name and parameters - are highly distro-specific.
As a result, I don't think it will be so easy to generate a working menu.lst for any distro just off the GParted CD.

But I think it could be possible to use a "Dual-Stage GRUB" approach: A small "GRUB" partition you mentioned, containing everything you need to pass the boot process on to any partition using the "chainloader" mechanism.
Inside these partitions, you'd have a boot loader for the operatiung system installed there - which would (in case of Linux) be a second GRUB that handles all the distro-specific parts.
However, this would require your distro ro install their GRUB not to the MBR, but to the PBR instead - which may required an "expert" install for most distros.

3 Reply by lsatenstein

  • lsatenstein
  • New member
  • Offline
  • Registered: 2009-05-18
  • Posts: 6

Re: Semi-autobuild of menu.lst (grub.conf)

So, lets see if  we can get it done.  Linux use has to be easy and friendly.

4 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Semi-autobuild of menu.lst (grub.conf)

Are there existing command line tools or libraries to perform these functions?

GParted is a graphical front end to many file system tools.  These tools do the actual work, while GParted provides access to these tools in an easy to use GUI.