Home / ubuntu / Questions / 942943
Accepted
xtrchessreal
Asked: 2017-08-05 00:58:20 +0800 CST

Linux Multiboot Quiet Splash Issue

  • 772

I have Ubuntu 16.04.3 LTS for quite a while, recently added Linux Mint and openSUSE in that order. Prior to openSUSE install the boot partition was /dev/sda1.

ISSUE: I want no splash screen on all distros. I read this article. I achieved this on Ubuntu by editing the /etc/default/grub file and updating when it was first installed. I used Grub Customizer on openSUSE and Mint to remove the splash screen however, openSUSE was the only one of the new distros installed that I achieved the result. I then edited the grub file for Mint directly and it still is showing the splash screen. I am not sure how to proceed. Further, If I decide to delete or uninstall either of openSUSE or MINT how would I proceed? 

dos HDD

/dev/sda1 ext3 Primary GRUB

/dev/sda2 Extended Ubuntu

    /dev/sda5      linux-swap

    /dev/sda6 ext4 /

    /dev/sda7 ext4 home

    /dev/sda8 ext3 mintboot

    /dev/sda9 ext4 mintroot

    /dev/sda10 ext4 minthome

/dev/sda3 btrfs openSUSE      flagged boot

/dev/sda4 xfs   openSUSE

openSUSE /etc/default/grub output: I suspect the bit scrolled at the end and a potential openSUSE grub.cfg edit, just not sure what exactly O.o

# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=1
GRUB_CMDLINE_LINUX_DEFAULT='resume=/dev/disk/by-uuid/0b074c09-c211-407b-ad9d-f7c0c2b3bee7 splash=""'
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
# GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
#Uncomment to disable graphical terminal (grub-pc only)

GRUB_TERMINAL="gfxterm"
# The resolution used on graphical terminal
#note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
# GRUB_DISABLE_LINUX_UUID=true
#Uncomment to disable generation of recovery mode menu entries

# GRUB_DISABLE_LINUX_RECOVERY="true"
#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
dual-boot

1 Answers

  1. Best Answer

    Broadly speaking, there are two ways to set up a multi-boot configuration between multiple Linux distributions:

    • One distribution's boot loader directly boots all of your distributions, leaving the other boot loaders entirely out of the loop. (Chances are it's OpenSUSE's GRUB that's in control in your case, since that's the one you installed last.) As such, you'd need to edit the controlling distribution's GRUB to change the kernel options for the other distributions.
    • Each distribution provides its own boot loader that boots its own kernel and that chainloads to the other distributions' boot loaders. In this configuration, each distribution controls its own kernel options, but to boot anything but the OS whose boot manager comes first in the boot chain, you must boot through multiple boot managers -- for instance, OpenSUSE's GRUB presents a menu with boot options for its own kernels alongside options to boot the other distributions' GRUB instances. To Boot (say) Ubuntu, you'd go through OpenSUSE's GRUB and then Ubuntu's GRUB.

    These two scenarios are not mutually exclusive; you might see (for instance) an OpenSUSE GRUB menu with options to boot OpenSUSE and Ubuntu kernels alongside an option to boot Ubuntu's GRUB.

    Note that a boot manager presents a menu of OS choices, whereas a boot loader loads an OS kernel into memory and starts running it. GRUB does both tasks, so people in the Linux world often use the two terms interchangeably, but the distinction is important in your situation, despite the fact that a single GRUB instance is likely to function in both roles in many configurations.

    Disentangling all this can be a real challenge, particularly on BIOS-based computers (which yours seems to be, judging by your partition summary, although I'm not 100% positive of that). Some experienced multi-booters set aside a boot manager that's outside of any one OS's control to boot each OS's dedicated boot loader, but I don't know of any modern references for how to do this on BIOS-based systems. Such a configuration separates the functions of a boot manager and a boot loader, which opens possibilities for using more specialized programs and can simplify the configuration task.

    Note also that if you boot Distribution B from Distribution A's boot loader, you won't be able to boot new kernels for Distribution B until you update the GRUB configuration in Distribution A. (This is one of the reasons for installing a tool that functions purely as a boot manager, to select between the boot loaders for each distribution; each distribution can then update its own boot loader configuration itself and you won't need to update things manually.)

    As to uninstalling an OS, the main worry comes when you uninstall whatever OS controls the first boot manager. If that boot manager is GRUB 2, then uninstalling the controlling OS's root (/) or /boot partition will erase the GRUB configuration file, which will render GRUB next to useless. At that point, you'll need to use an emergency disk to (re-)install the GRUB for another distribution to take over as the primary boot manager.

    EDIT:

    GRUB 2 configuration is a nightmare. At run (boot) time, GRUB reads a configuration file that's typically located at /boot/grub/grub.cfg, relative to the hosting OS's filesystem. This file is typically built by scripts that run when GRUB is first installed, when you install a new kernel, or manually. (grub-mkconfig -o /boot/grub/grub.cfg is the generic command; but in Ubuntu, update-grub does the trick, too.) The scripts, in turn, rely on multiple configuration files, one of which is the /etc/default/grub file you've referenced. Note that this file does not tell you what OS(es) GRUB will present at boot time; that detail varies from one system to another. What this file does enable you to adjust are certain global defaults, like the timeout value. Note that editing these defaults will not have an immediate effect; your changes will only take effect after you run the script to re-write the grub.cfg file (or after the system does this itself -- say, after a kernel update).

    GRUB's configuration scripts also rely on a bunch of files in /etc/grub.d to help it identify specific OSes and tools. Typically, you don't edit these yourself; however, there is one, called 40_custom IIRC, that you can edit to provide custom entries if the default OS/kernel detection scripts don't work adequately. Just as with changes to /etc/default/grub, any change you make to these files will not take effect unless and until you regenerate /boot/grub/grub.cfg. If you want to remove quiet splash from the options generated by OpenSUSE's scripts for Ubuntu, you'd probably need to edit one of the files in /etc/grub.d/, but I'm afraid I don't know exactly where you'd look. Alternatively, you could hand-edit /boot/grub/grub.cfg, but any changes you make there will be overwritten whenever you build a new grub.cfg file, either deliberately or because the host OS has installed a new kernel.

    As described earlier, another approach is to set things up so that the master boot manager doesn't directly launch Ubuntu's kernels, but instead chainloads to Ubuntu's GRUB, which then manages its own GRUB configuration.

    Note that all three of your distributions have their own GRUB configuration files -- both /boot/grub/grub.cfg and all the supporting files; however, only one GRUB controls the boot process. The others, as noted earlier, are either 100% irrelevant or are called only if the first GRUB is configured to chainload to the secondary GRUBs.

    FWIW, GRUB Customizer is a GUI tool to help edit the various GRUB configuration files. That link, though, is to a Launchpad PPA for Ubuntu. I don't know if GRUB Customizer is even available for OpenSUSE. If not, and if you want to use GRUB Customizer, you should reconfigure your system so that Ubuntu's GRUB is the primary one, relegating OpenSUSE's GRUB to secondary status. If you can find GRUB Customizer built for OpenSUSE (or build it yourself or maybe convert an Ubuntu Debian package to RPM form), you could run it in OpenSUSE to adjust the current configuration. Given the delicacy of GRUB configuration, though, I wouldn't recommend straying from a well-tested build for the host distribution.

    • 1