1 -How should I set it up in case of a new install, with respect to primary/logical partitions and where to put the /data respectively swap partition.
I don’t follow your question re a new install, as you already have 3 root partitions. You can install a linux root in any partition of sufficient size anywhere on the disk. Obviously, depending on what the current layout is, that could involve moving/resizing if more space is required. As far as where to locate the data or the swap, physical placement on the disk particularly the swap was once important but with Linux and modern drives, that is no longer a concern. Unless you have limited RAM, Linux will use the swap partition very little. And even if so, with today’s disk speeds, cache, and platters (especially if the drive is perpendicular), it’s just not an issue.
2 -Currently 2 systems (Vista and openSUSE 11.0 with KDE 4.1) boot directly from 1st Grub menu list while the other 2 boot via a 2nd Grub menu list. Can I correct this situation and if yes how?
3 -While doing a new install of one of the openSUSE systems I am still puzzled with how to set up bootloader with respect to various bootloader locations for the succesive openSUSE systems and the bootloader options to use. Please explain or is there a clear how to.
I don’t think there will be a simple howto about this. But, it’s simple enough to understand. You can choose to have a single menu.lst control the boot for all the OS’s (called “direct”), or you can “chainload” between them just as you chainload to Windows. In each OS instance’s menu.lst the stanza that boots it has a “root” line which points grub to the partiton where its kernel and initrd are located, and on the kernel line there is a “root=” argument which tells the kernel where to find the matching root (/) partition (which can be different). In the method of using a single menu.lst for control, it is simply a matter of copying the boot stanza from the other menu.lst’s. This is how Debian works. And, you can get YaST’s help to do this; in the Boot Loader module under the Other button you can tell YaST to “Propose and Merge with Existing Grub Menus”. The downside of this approach is that when the kernel changes and menu.lst is updated in one of the other instances, you must go thru the copying routine again to keep the primary menu.lst in sync. The upside is you don’t need to pay any attention to installing grub from the secondary instances, there is a single grub installation in the MBR. The alternative, which also uses grub in the MBR, is to install grub in the boot sector of the root partition of each instance. You still have a primary menu.lst which the MBR grub points to, but in that menu.lst instead of the standard root/kernel/initrd stanza you use a chainloader stanza (like with Windows). That instructs grub to hand-off control to whatever is in the ref’d partition’s boot sector, which is another copy of grub.
It’s really just a matter of preference. On my primary workstation where I have several test instances installed plus a backup mirror of my production instance, I use a hybrid setup (and note, this machine has 5 disks). My production instance /boot is on its own partition (well, actually 2, because I have /boot on a RAID 1 array); for the test instances I chainload as that’s most convenient. I don’t want to maintain a synchronized master because I make changes to those instances all the time. For the mirrored instance, I also have the boot sector installed for chainloading from the production /boot menu.lst. But, the mirror is on its own drive, so I also have grub installed in that drive’s MBR and the mirror has a menu.lst which is to be used if I boot from that drive, i.e., in the event of failure of my primary /boot, I can switch the bios boot sequence to boot from the mirror and it can control all the booting as can the production grub. Obviously, this is more complex, but it just illustrates the flexibility you have. If I had your setup, I would probably just choose which is the primary instance, install grub to the root boot sector for all other instances, and have the primary menu.lst chainload to the others.
Hope that helps.
). The work order was: