Booting solus-2017.01.01

As mentioned in my previous post, here is my separate post on booting Solus.

What’s wrong with the installation defaults for booting?

Probably nothing, at least for most users.  But they do not suit my needs.

The main issue, for me, is that I have several linux systems installed.  So I don’t want Solus to take control of the booting.  I would prefer to have an entry added to my openSUSE boot menu.

Do I even need a bootloader?

You probably do.  The grub configuration (as with “grub2-mkconfig” in openSUSE) can find other linux systems and add menu items for them.  But that configuration process looks at the boot menus for the other linux systems, to decide how to boot them.

For an earlier version of Solus, I tried doing without a bootloader install.  I then booted to openSUSE and updated the grub boot menu there.  It added an entry for Solus.  But it did not work.  So I went back and installed a bootloader for Solus, then tried again.  This time, the entry added to the grub menu did work, because it was based on the Solus boot menu.

I’ll describe what I did.  I actually installed Solus-2017.01.01 twice — once on a legacy MBR system and once on a UEFI box.  So I will describe those is separate sections below.

MBR Legacy booting

On my older MBR Legacy system, I installed Solus on the partition “/dev/sda8”.  The Solus installer wanted to boot from the MBR, which would overwrite the opensuse bootloader that I am using.  So I set the installer to “do not install a bootloader”.

I then completed the install, without a bootloader.  At the end of the install, I closed the installer window.  But I did not reboot.  Instead, I opened a terminal window (Gnome Terminal).  And here’s what I did in that window:  (I have added comments to the end of several lines).

sudo bash ## become root
# mount /dev/sda8 /mnt ## mount the installed system
# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# chroot /mnt

That put me into a “chroot” session on the installed Solus system.  The plan, now, is to install grub in the root partition (i.e. in “/dev/sda8”). This is done while still in the “chroot” session.

# grub-install --force /dev/sda8
# cd /boot/grub
# grub-mkconfig -o grub.cfg
# exit (leave the "chroot" session.

Finally, I rebooted, updated my opensuse grub menu, and then booted into Solus.

UEFI booting

On my UEFI system, I was installing Solus into “/dev/sdb6”.  I’ll note that the disk is GPT partitioned (uses a GPT format partition table).

I’ll note that the default for Solus, on a UEFI system, is to use a derivative of “gummiboot”, which is a UEFI loader.  This can work, but again I prefer to use the grub2 menu from my opensuse system on that box.

For the UEFI case, the Solus installer does not seem to give any options.  I could not set it to not install a bootloader.  So I took the alternative approach.  I went into BIOS settings on the computer, and configured it to do Legacy booting.  And then I booted the Solus installer USB with legacy mode.  And I chose to install Solus that way.

From there, what I did was similar to the legacy MBR case.  However, I did not need to tell the installer “do not install a bootloader”.  That was the default, and the only option available.  Apparently, the Solus installer does not know how to handle a GPT partitioned disk when booted in legacy mode.

I finished the install that way, but did not reboot.  I again opened a terminal window to manually install booting.

sudo bash  ## become root
# mount /dev/sdb6 /mnt
# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# chroot /mnt

That put me into a “chroot” session. There, I continued with:

# grub-install --force /dev/sdb6
# cd /boot/grub
# grub-mkconfig -o grub.cfg
# exit

And now I could reboot to my openSUSE system, and update the bootloader there before booting to Solus.  Before booting to openSUSE, I booted into BIOS settings and restored the system to UEFI booting.

Final notes

I have not attempted to legacy-boot the UEFI box to “/dev/sdb6”.  That probably doesn’t work, because I have not installed any boot code in the MBR of that disk.  There is suitable bootcode as part of “syslinux”, which is normally installed with openSUSE.

Both systems can now boot smoothly into Solus using the boot menu installed by openSUSE.  Solus can stay there, until I need that disk space to test something else.

Advertisements

Tags:

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

3 responses to “Booting solus-2017.01.01”

  1. Max says :

    Many thanks for this. I have tried twice to get solus to run alongside Mint 18 on my ancient and bios powered xps m1330 and the first time the nvidia driver upgrade (solus recommended) made it hang at the login screen (no boot loader installed).
    The second install was done with the solus boot loader installed and this worked fine until the solus update updated the bootloader then Mint 18 options vanished.
    The only way I got back in was by deleting the solus partition from a live usb and running boot repair.
    Great operating system save for the fact it doesn’t play nice with grub. A work in progress methinks.

    Once again thanks for posting your solution to this problem.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: