On 02/20/2015 05:53 PM, Felix Miata wrote:

Frans de Boer composed on 2015-02-20 12:07 (UTC+0100):

...

I have a server running 12.3 and want to install on a different partition the newer 13.2 distribution. Alas, after installation I can't boot 12.3 anymore because of wrong references. Every time I install a fresh kernel I have to manually edit the grub.cfg files to get 12.3 booted again.

...

I also want to install a third system (LFS) without having to manually edit grub.cfg every time. So, is it possible to install the GRUB core image in a different partition and have the kernels be placed in the /boot directory of their respective partitions? Using this method I just need to chain to the relevant partition to start the local GRUB menu handler.

That's more or less how all my own installations are configured....

...

- Between MBR and first partition: GRUB bootloader. - First partition: GRUB core and simple menu. - Second partition contains swap space - partitions 3..n Contain GRUB menu handlers and local linux kernels in local /boot dir.

...

I need local GRUB handlers because of preserving the kernel version as supported by openSuse and newer standard kernels with better or newer support modules.

...

Reading the GRUB 2.00 manual is not so helpful - to me - because of lack of unambiguous explanations or examples.

That's a misfeature of most man pages. It's more troublesome with Grub2 because it's a moving target, and getting the man page matching your own from the Internet while the machine you are working on has the problem you are trying to solve can be quite problematic.

...

Any suggestions?

Configure the system with a "primary" /boot partition, to which the bootloader is installed instead of to the MBR, but, after installing the first system, reconfigure it to be mounted someplace other than boot, and manage it yourself manually. openSUSE makes it easy to self-manage a master boot partition this way, in part, because of the symlinks it always creates to the latest installed kernel and initrd.

To do the reconfiguration, edit /etc/fstab yourself, changing the existing mount location of its /boot device from /boot to someplace like /realboot, /disks/boot or /media/boot. You won't actually need to change its [menu.lst|grub.cfg] until you're ready to include any additional installation. You will need to copy the content from the new location to the newly emptied /boot, and subsequently reconfigure and reinstall the installed system's bootloader to its / partition.

Because of the initrd and kernel symlinks, your manual management of the master boot menu won't often be required. IOW, once your system is fully installed with however many distros it will have, the only edits that will be required are when *you* wish some change be made, whether a new cmdline option added, an old removed, an old edited, or a label changed. At each kernel update time, after the very first, only the /boot directory of the / filesystem will be affected by the kernel or OS installer.

Done right, you'll have multiple entries for every installed Linux operating system, and one for each Windows, DOS and/or OS/2. For Linux, you'll have one entry that is a near clone of the default entry from each / partition's /boot/grub(2) to directly boot it from the master boot menu, and at least one more that is either a chainloader entry and/or a configfile entry, which you'll use when the main one won't do what you want and you need to choose an older kernel to boot from, or a failsafe stanza for whatever reason.

Above describes more than 20 multiboot machines I have. It works regardless of the bootloader installed to each operating system's / (including Windows/DOS/OS2; if any bootloader at all, I've been choosing no bootloader installation for 13.2 and up). You, as I do (it's simple and easy to manage), could have Grub Legacy on the master bootloader partition, and any of Grub Legacy, Grub2, Lilo or some other bootloader on the / filesystems.

Ok, I try again: Consider the next disk GPT configuration: sd[ab]1 BIOS Grub sd[ab]2 swap sd[ab]3 EXT4 boot /boot sd[ab]4-7 Raid where md0 EXT4 LFS* md1 EXT4 opensuse13.2* md2 EXT4 opensuse12.3 / md3 EXT4 home /home *Reserved for new installations This is the initial state where only 12.3 is installed. I remount /boot under /mnt/grub2 and copy it's contents to the now empty /boot. Now, I add in grub.cfg (now on /mnt/grub2) a menu entry to chainload hd0,gpt6 or /dev/md2. Question: How can I make /dev/md2 bootable, without altering the BIOS Grub partition. The thing is that I can't put the bootloader code (embedded code) in the new /boot directory. As long as I stick with the distribution supplied kernel, I can make menu entries in the main grub.cfg file. But I update to tailored kernels frequently, which causes me to manually trim the grub.cfg file too. So, that's why I like to confine each distribution to it's own partition, with it's own grub2 configuration and only select during boot time which distribution I want to go for. So far, Felix Miata has given me pointers, but what I am really looking for is how to make a partition bootable so that I can use chainloading. If there is a better way, I like to hear that too. OpenSUSE 12.3 uses an older version of Grub2, so maybe manually updating to Grub2.02-beta3 might help? Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/03/2015 04:46 AM, Andrei Borzenkov wrote:

В Mon, 02 Mar 2015 21:24:00 +0100 Frans de Boer <frans@fransdb.nl> пишет:

...

On 02/20/2015 05:53 PM, Felix Miata wrote:

...

Frans de Boer composed on 2015-02-20 12:07 (UTC+0100):

...

I have a server running 12.3 and want to install on a different partition the newer 13.2 distribution. Alas, after installation I can't boot 12.3 anymore because of wrong references. Every time I install a fresh kernel I have to manually edit the grub.cfg files to get 12.3 booted again.

...

I also want to install a third system (LFS) without having to manually edit grub.cfg every time. So, is it possible to install the GRUB core image in a different partition and have the kernels be placed in the /boot directory of their respective partitions? Using this method I just need to chain to the relevant partition to start the local GRUB menu handler.

That's more or less how all my own installations are configured....

...

- Between MBR and first partition: GRUB bootloader. - First partition: GRUB core and simple menu. - Second partition contains swap space - partitions 3..n Contain GRUB menu handlers and local linux kernels in local /boot dir.

...

I need local GRUB handlers because of preserving the kernel version as supported by openSuse and newer standard kernels with better or newer support modules.

...

Reading the GRUB 2.00 manual is not so helpful - to me - because of lack of unambiguous explanations or examples.

That's a misfeature of most man pages. It's more troublesome with Grub2 because it's a moving target, and getting the man page matching your own from the Internet while the machine you are working on has the problem you are trying to solve can be quite problematic.

...

Any suggestions?

Configure the system with a "primary" /boot partition, to which the bootloader is installed instead of to the MBR, but, after installing the first system, reconfigure it to be mounted someplace other than boot, and manage it yourself manually. openSUSE makes it easy to self-manage a master boot partition this way, in part, because of the symlinks it always creates to the latest installed kernel and initrd.

To do the reconfiguration, edit /etc/fstab yourself, changing the existing mount location of its /boot device from /boot to someplace like /realboot, /disks/boot or /media/boot. You won't actually need to change its [menu.lst|grub.cfg] until you're ready to include any additional installation. You will need to copy the content from the new location to the newly emptied /boot, and subsequently reconfigure and reinstall the installed system's bootloader to its / partition.

Because of the initrd and kernel symlinks, your manual management of the master boot menu won't often be required. IOW, once your system is fully installed with however many distros it will have, the only edits that will be required are when *you* wish some change be made, whether a new cmdline option added, an old removed, an old edited, or a label changed. At each kernel update time, after the very first, only the /boot directory of the / filesystem will be affected by the kernel or OS installer.

Done right, you'll have multiple entries for every installed Linux operating system, and one for each Windows, DOS and/or OS/2. For Linux, you'll have one entry that is a near clone of the default entry from each / partition's /boot/grub(2) to directly boot it from the master boot menu, and at least one more that is either a chainloader entry and/or a configfile entry, which you'll use when the main one won't do what you want and you need to choose an older kernel to boot from, or a failsafe stanza for whatever reason.

Above describes more than 20 multiboot machines I have. It works regardless of the bootloader installed to each operating system's / (including Windows/DOS/OS2; if any bootloader at all, I've been choosing no bootloader installation for 13.2 and up). You, as I do (it's simple and easy to manage), could have Grub Legacy on the master bootloader partition, and any of Grub Legacy, Grub2, Lilo or some other bootloader on the / filesystems.

Ok, I try again:

Consider the next disk GPT configuration:

sd[ab]1 BIOS Grub sd[ab]2 swap sd[ab]3 EXT4 boot /boot sd[ab]4-7 Raid

where md0 EXT4 LFS* md1 EXT4 opensuse13.2* md2 EXT4 opensuse12.3 / md3 EXT4 home /home

*Reserved for new installations This is the initial state where only 12.3 is installed.

I remount /boot under /mnt/grub2 and copy it's contents to the now empty /boot. Now, I add in grub.cfg (now on /mnt/grub2) a menu entry to chainload hd0,gpt6 or /dev/md2.

Question: How can I make /dev/md2 bootable, without altering the BIOS Grub partition.

Unfortunately currently SUSE tools do not support it. You would need to create core.img without actually installing it and it is not possible to do using YaST/perl-bootloader.

What could be possible (without actually testing, just looking at perl-bootloader code)

- do not select any bootloader location in YaST (assuming it allows you to do it ...)

- manually run "grub2-install --no-bootsector /dev/sda" - it won't overwrite your primary bootloader but will create core.img. You will need to repeat it every time after grub2 update; it is possible to create dummy package containing trigger that does it automatically.

- in you "primary" grub2 add menu entry (without error checks)

menuentry "openSUSE 12.3 on ..." { insmod mdraid1x (insert your driver here) insmod ext2 (insert your filesystem here) search --fs_uuid --set "insert-your-UUID-here" multiboot /boot/grub2/i386-pc/core.img }

This will "chainload" another grub. You can find out needed drivers and names by

grub2-probe -t abstraction /boot/grub2/i386-pc grub2-probe -t fs /boot/grub2/i386-pc grub2-probe -t fs_uuid /boot/grub2/i386-pc

...

The thing is that I can't put the bootloader code (embedded code) in the new /boot directory.

As long as I stick with the distribution supplied kernel, I can make menu entries in the main grub.cfg file. But I update to tailored kernels frequently, which causes me to manually trim the grub.cfg file too. So, that's why I like to confine each distribution to it's own partition, with it's own grub2 configuration and only select during boot time which distribution I want to go for.

So far, Felix Miata has given me pointers, but what I am really looking for is how to make a partition bootable so that I can use chainloading. If there is a better way, I like to hear that too.

OpenSUSE 12.3 uses an older version of Grub2, so maybe manually updating to Grub2.02-beta3 might help?

Which grub2.02-beta3?

Thanks Andrei, Yes, of course Perl-Bootloader would have been a source to look at. I completely overlooked it. I go and try your suggestions. As for Grub2.02-beta3, that must be grub2-2.02-beta2. I was told that development had come to a standstill, but looking at the git repository, that is far from the truth. Although an official update has not been released for well over 3 years. Anyhow, if it works or not, I will report it back in due time. Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org