About booting with GRUB2 chainloading both Slackware 32bit and 64bit systems, while being installed in the same hard drive
by LuckyCyborg from LinuxQuestions.org on (#6GCB4)
One recurring theme which I have seen in this forum is regarding using os-prober to boot Slackware from Ubuntu, or vice-versa. So they say that we need "compatibility" ...
Well, regarding this "compatibility" let's ignore that Slackware uses its own kernel files naming scheme and (possible in future) huge initrds, which will be not intelligible for the Ubuntu tools.
The main issue is that that os-prober never worked well, so today the usual recommendation on other Linux forums is to avoid it like the hell. The recommended solution today is instead everywhere the chainloading.
So, for my kde4town project and building packages for it on architectures x86_64 and i586, I have arrived at idea to setup on a 500GB hard drive, mounted in an USB portable case, both Slackware 15.0 32bit and 64bit clean systems, side by side - they sharing a bigger data partition. And using GRUB2 as bootloader for both of them.
How we talk about a portable USB hard drive, which should work on any computer, the GRUB2 should accurately find the partitions of both systems - then I chosen to use the UUIDs which (still) is the default.
So, I have setup first the Slackware 15.0 x86_64 on what is on my laptop the /dev/sdc2 with the size of 80GB. There I did the typical installation excluding the KDE series (which I will replace soon with the kde4town packages) and installed the GRUB2 on hard drive MBR, aka on /dev/sdc
Secondly, I have installed the Slackware 15.0 i586 on /dev/sdc3, again a typical installation without the KDE series. BUT, this time I have installed the GRUB2 bootloader on the partition itself, hence on /dev/sdc3
Of course, the grub-install protested to this idea, and I have needed to use the --force parameter. Why this? Because usually it's a bad idea to install GRUB2 bootloader in an partition, because it will look directly by hard drive sectors for /boot/grub/i386-pc/core.img just like LILO.
This means that if that file is moved in another location by filesystem or a filesystem tool like e4defrag, the boot will fail. The same issue exists on a LILO setup, but who counts this kind of failures, when it's usual to reinstall it after each kernel update? BUT, for GRUB2 the issue is aggravated because you install it one time, later is about a config file play.
So, I have made that file immutable - also a general recommendation for this case, using the command:
Code:chattr +i /boot/grub/i386-pc/core.imgOf course, this must be reversed when the GRUB2 bootloader will be eventually reinstalled.
Using a SYSLINUX bootsector, I have tested and booted successfully this GRUB2 on partition setup, then using a 64bit kernel, I have returned back on the 64bit system and reinstalled the GRUB2 on the harddrive's MBR.
Finally, I needed to chainload the bootable 32bit partition from the main GRUB2 installation, beloging to the 64bit system.
For this, I have added on /etc/grub.d/40_custom the following code:
Code:# Set the partition's UUID where we chainload:
set chainload_uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
menuentry 'Slackware-15.0 GNU/Linux i586 (chainload)' $menuentry_id_option gnulinux-advanced-chainload-$chainload_uuid {
savedefault
insmod chain
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 $chainload_uuid
else
search --no-floppy --fs-uuid --set=root $chainload_uuid
fi
# Chainload the bootloader from this partition:
chainloader +1
}So, each time I will run update-grub, along with the 64bit kernel entries, will be added also this menu item which will boot the third partition from hard drive. Of course, it was possibile also to install on partition the GRUB2 bootloader for the 64bit system, and to use a third bootloader as bootmanager, i.e. another GRUB2 or SYSLINUX installed on a small boot partition. On this way both installation will behave the same, but I thought is kinda a complication.
As bottom line, this setup permits to have 2 independent configured GRUB2 installations, with a little trick: on the main GRUB2 menu I have a menu item to boot the other Slackware system - practically also a GRUB2 bootloader.
BUT, of course, you can chainload another kind of bootloader (i.e. LILO) or another kind of operating system (i.e. Ubuntu or Windows 10), if we speak about BIOS boot, compatible also with 32 bit Linux installations.
Well, regarding this "compatibility" let's ignore that Slackware uses its own kernel files naming scheme and (possible in future) huge initrds, which will be not intelligible for the Ubuntu tools.
The main issue is that that os-prober never worked well, so today the usual recommendation on other Linux forums is to avoid it like the hell. The recommended solution today is instead everywhere the chainloading.
So, for my kde4town project and building packages for it on architectures x86_64 and i586, I have arrived at idea to setup on a 500GB hard drive, mounted in an USB portable case, both Slackware 15.0 32bit and 64bit clean systems, side by side - they sharing a bigger data partition. And using GRUB2 as bootloader for both of them.
How we talk about a portable USB hard drive, which should work on any computer, the GRUB2 should accurately find the partitions of both systems - then I chosen to use the UUIDs which (still) is the default.
So, I have setup first the Slackware 15.0 x86_64 on what is on my laptop the /dev/sdc2 with the size of 80GB. There I did the typical installation excluding the KDE series (which I will replace soon with the kde4town packages) and installed the GRUB2 on hard drive MBR, aka on /dev/sdc
Secondly, I have installed the Slackware 15.0 i586 on /dev/sdc3, again a typical installation without the KDE series. BUT, this time I have installed the GRUB2 bootloader on the partition itself, hence on /dev/sdc3
Of course, the grub-install protested to this idea, and I have needed to use the --force parameter. Why this? Because usually it's a bad idea to install GRUB2 bootloader in an partition, because it will look directly by hard drive sectors for /boot/grub/i386-pc/core.img just like LILO.
This means that if that file is moved in another location by filesystem or a filesystem tool like e4defrag, the boot will fail. The same issue exists on a LILO setup, but who counts this kind of failures, when it's usual to reinstall it after each kernel update? BUT, for GRUB2 the issue is aggravated because you install it one time, later is about a config file play.
So, I have made that file immutable - also a general recommendation for this case, using the command:
Code:chattr +i /boot/grub/i386-pc/core.imgOf course, this must be reversed when the GRUB2 bootloader will be eventually reinstalled.
Using a SYSLINUX bootsector, I have tested and booted successfully this GRUB2 on partition setup, then using a 64bit kernel, I have returned back on the 64bit system and reinstalled the GRUB2 on the harddrive's MBR.
Finally, I needed to chainload the bootable 32bit partition from the main GRUB2 installation, beloging to the 64bit system.
For this, I have added on /etc/grub.d/40_custom the following code:
Code:# Set the partition's UUID where we chainload:
set chainload_uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
menuentry 'Slackware-15.0 GNU/Linux i586 (chainload)' $menuentry_id_option gnulinux-advanced-chainload-$chainload_uuid {
savedefault
insmod chain
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 $chainload_uuid
else
search --no-floppy --fs-uuid --set=root $chainload_uuid
fi
# Chainload the bootloader from this partition:
chainloader +1
}So, each time I will run update-grub, along with the 64bit kernel entries, will be added also this menu item which will boot the third partition from hard drive. Of course, it was possibile also to install on partition the GRUB2 bootloader for the 64bit system, and to use a third bootloader as bootmanager, i.e. another GRUB2 or SYSLINUX installed on a small boot partition. On this way both installation will behave the same, but I thought is kinda a complication.
As bottom line, this setup permits to have 2 independent configured GRUB2 installations, with a little trick: on the main GRUB2 menu I have a menu item to boot the other Slackware system - practically also a GRUB2 bootloader.
BUT, of course, you can chainload another kind of bootloader (i.e. LILO) or another kind of operating system (i.e. Ubuntu or Windows 10), if we speak about BIOS boot, compatible also with 32 bit Linux installations.