15

I have a machine which has multi-boot partitions. I have Ubuntu 14.04 on one partition, Ubuntu 15.04 on the second and Ubuntu 16.04 on a third one. Is there a way to know, from the command line, from which partition I had booted, in order to find you on which partition is the /boot/grub/grub.cfg which was used for the boot process? I have /boot/grub/grub.cfg on each of the three partitions.

1
  • 3
    You can't do that with absolute generality and reliability. For what you know, the /boot/grub/grub.cfg file used for booting could have been deleted, that partition could have been deleted from the partition table, and that disk removed physically from the system. May 10, 2017 at 14:13

6 Answers 6

11

Once GRUB has handed off booting to the kernel, the kernel has no idea what started it, and /boot might not be the one which that GRUB used. You might check the access times of boot/grub/grub.cfg in each of the partitions to see which one was most recently accessed. That could tell you which partition's configuration file GRUB used.

stat -c %x /boot/grub/grub.cfg

If the access times aren't updated, you'll have to look for any differences in the kernel parameters used by the various GRUB configuration files. If you can change them, for example, add foo=1, foo=2, etc. to GRUB_CMDLINE_LINUX in each of these, run sudo update-grub2 and reboot, then you can check /proc/cmdline to see which of these values were used.

8
  • interesting! does that mean my solution also has a better accuracy rate then Ravexina's and Katu's?
    – tatsu
    May 10, 2017 at 11:42
  • @tatsu IMO all the other answers are incorrect - Ravexina is locating the partition where /boot is located, but that might not be what grub used, and you and Katu are finding the partition mounted on / is mounted, but, as Ravexina noted, that probably has even less of a connection
    – muru
    May 10, 2017 at 11:51
  • 1
    yes but how can unmounting possibly do anything other than fail on the partition you are mounted on : disks delivers such information as the device the mounted adress, any id info you could possibly need as to which one you just attempted to unmount. I'm the first to admit my solution is ugly but it does had 100% success rate right?
    – tatsu
    May 10, 2017 at 12:57
  • 1
    @tatsu success rate for what? Finding the partition mounted on /, sure. Finding which partition's GRUB configuration was used while booting? I don't see how that relates.
    – muru
    May 10, 2017 at 15:31
  • 5
    Does grub actually set that access timestamp, given it is its own DOS and not bound by linux filesystem driver conventions? May 11, 2017 at 0:34
4

As you know the file you are looking for is located in /boot directory of your running system. either /boot is a separate partition or it's not; If your /boot is a separate partition you should look for that:

$ lsblk -r | grep '/boot'
sda2 8:1 0 400M 0 part /boot

Means the grub.cfg which been used is located in sda2.

Othewise you should look for root:

$ lsblk -r | grep '/$'
sda1 8:1 0 121.2G 0 part /

this time it's located in sda1.

Or even for fun we can check boot time parameters:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae root=UUID=938495-1fe2-3302 ro quiet

then use UUID to find out which partition is your root.

$ sudo blkid | grep 938495-1fe2-3302
/dev/sda1: UUID="938495-1fe2-3302"

Which means from sda1.

You can also check for these boot parameters to see which one of your grub.cfg files contains them, this only works when your boot parameters in grub.cfg are differ from each other.

1
  • 2
    An easier way (that doesn't require super-user privileges) to find the device node behind a file system UUID would be readlink -f /dev/disk/by-uuid/<UUID>. May 10, 2017 at 12:14
3

To display the device holding the currently mounted root file system:

awk '$2=="/"{print $1}' /proc/mounts

To display the currently running Ubuntu release version:

lsb_release -rs
6
  • that actually makes alot of sence in regards to the question and seems like the most fitting answer yet. I bet given no two distro on his setup have the same version number he'll just use lsb_release -rs everytime. KISS
    – tatsu
    May 10, 2017 at 13:06
  • Unfortunately this does not work. I tested your command on my machine with multiple OS's, only my "master`-OS has grub installed in MBR, other OS's have Grub installed in the PBR, the command seem to show the location where the OS has Grub installed, but does not show from which OS Grub loads the config-file.
    – mook765
    May 11, 2017 at 14:12
  • @mook765: My answer has absolutely nothing to do with Grub or MBR (or any boot loader or partition table type really). I'm not sure what exactly you tried and what you expected to see. May 11, 2017 at 17:24
  • Then this answer has nothing to do with the question...
    – mook765
    May 12, 2017 at 2:29
  • @mook765: If you take it literally, then yes. However to me it appears that OP wants to know which one of his multiple Ubuntu installation is currently booted and for that my answer should be just fine. May 12, 2017 at 6:27
2

We could add a simple custom menu entry in each OS and we would see in the Grub-menu from which OS Grub loaded it's configuration-file.

Example:

We boot into 16.04 and edit the file /etc/grub.d/40_custom to add a menu-entry.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#

menuentry 'grub.conf loaded from 16.04' {        
            reboot  
    }

We make sure the file is executable and run sudo update-grub.

Then we do the same changes in the other OS's, we just use different names for the menuentry, i.g. we change 16.04 to 15.04 and so on.

If we select this menu-entry in the Grub-menu during boot, the machine will just reboot, we created them not to boot any OS but to see which OS is actually used to load grub.conf.

Additional information

This kind of confusion appears, when we install multiple OS's which all use Grub and during install of an OS we choose the same boot-loader location. We need indeed only one OS which installs Grub, Grub can boot into any Linux distribution, so if we have one distribution installed (including Grub), we could install additional OS's without installing Grub.

In legacy-installs it is pretty easy to handle the location for the boot-loader installation, as we can choose the partition-boot-record as location, but we have to take care to choose the correct partition. So one OS installs the boot-loader to the MBR and additional OS's install the boot-loader to the PBR of the OS-partition. This possibility we have only when we use the Something else-option during install.

In UEFI-installs it is a bit more weird, the boot-loader will be installed to a folder in the EFI System Partition (ESP) and multiple boot-loaders can easily coexist. The problem here is that all Ubuntu-flavours and also some other linux-distributions will install Grub to the same folder in the ESP and we don't have a choice. So installing an additional Linux-distribution would overwrite our already existing boot-loader. The only way I know to avoid this is to boot into a live session and start the installer with sudo ubiquity -b.

Another simple solution

Let us assume that we have three Linux distributions installed on the partitions sda1,sda2 and sda3. Now we take a look at Grub's boot menu entries. During boot, we will see something like this:

1  Ubuntu
2  Advanced options for Ubuntu
3  Memory test (memtest86+)
4  Memory test (memtest86+, serial console 115200)
5  Ubuntu (on /dev/sda2)
6  Advanced options for Ubuntu (on /dev/sda2)
7  Ubuntu 17.04 (on /dev/sda3)
8  Advanced options for Ubuntu (on /dev/sda3)

The first two entries are the entries for the OS which generated the grub.conf-file we actually use. The entries #3 and #4 are not interesting at the moment. The entries #5, #6, #7 and #8 are the entries which were generated with the OS-prober and we see on which partitions the OS's for these entries reside. So in the case of this small example we can conclude that the grub.config-file we actually use doesn't belong to the OS on sda2 or sda3but to the OS on sda1. In the case one or more OS's are installed with a separate /boot-partition we would have to check out which /boot-partition belongs to which OS, but that is easily done by running the findmnt-command in each OS.

1
  • +1 Despite lengthy, this answer actually includes relevant points. For BIOS systems, users who do multi-boot should prefer "Something else" in the installer to have more control; No need to force "not to install GRUB boot loader" (see my older answer). For UEFI systems, multi-boot setup seems to be much unexplained or untested.
    – user37165
    May 11, 2017 at 14:08
1
lsblk

And check what disk is mounted in /. Please read the comments below or Ravexina's answer if you have /boot in your mounted points.

If you are not sure, check the UUID

lsblk -o UUID,NAME,SIZE,MOUNTPOINT
4
  • 2
    It's not true, what if my /boot is a separate partition? then /boot/grub/grub.cfg is not located in / partition.
    – Ravexina
    May 10, 2017 at 10:33
  • @Ravexina Get technical, that might be true. However, for the purposes of this user, doesn't the / partition count?
    – user595510
    May 10, 2017 at 10:39
  • @MarkYisri I guess that I should say it's not always true, however the OP is telling us that he got the file on three different partition so I guess it's better to check for a separate /boot first.
    – Ravexina
    May 10, 2017 at 10:46
  • 1
    Thanks for pointing that out @Ravexina I have updated the answer.
    – Katu
    May 10, 2017 at 11:36
0

To know from which partition the user had booted, look at the boot loader menu before booting any of the installed systems. It's difficult to tell without seeing the boot loader menu.

Where to look at

In the following combined screenshots, I have labeled three hints that one might know from which partition the user had booted.

Multi boot menu using GNU GRUB PC/BIOS version with annotation

Label (1): GNU GRUB menu entries below the first entry

Label (2): GNU GRUB version at top of boot loader menu

Label (3): GNU GRUB background image (manual setup required)

The most apparent hint is label (3), which is to change GNU GRUB background image on the system that have control of boot loader menu. It is the easiest to tell, provided user set it up beforehand.

Label (1) explained

Look for partition that is not listed in menu entries below the first entry. In the screenshot, there are only two operating systems being installed i.e. "Ubuntu" and "Ubuntu 14.04.5 LTS".

Ubuntu
Advanced options for Ubuntu
Memory test (memtest86+)
Memory test (memtest86+, serial console 115200)
Ubuntu 14.04.5 LTS (14.04) (on /dev/sda3)
Advanced options for Ubuntu 14.04.5 LTS (14.04) (on /dev/sda3)

The latter has mentioned (on /dev/sda3), which means the former might be located on /dev/sda2 or /dev/sda1. To be sure, after booting the system i.e. "Ubuntu", run relevant command to list down available partitions (lsblk seems to be most straightforward).

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0    13G  0 disk 
├─sda1   8:1    0   976M  0 part [SWAP]
├─sda2   8:2    0     6G  0 part /
└─sda3   8:3    0     6G  0 part 
sr0     11:0    1  55.7M  0 rom 

Only after comparing to the output of lsblk, then we know that the system i.e. "Ubuntu" is found at /dev/sda2 (which was not listed in menu entries) from which boot loader menu is managed.

Label (2) explained

Look for GRUB version that is printed at top of boot loader menu. Note that version and compare to the GRUB version that is found on the booted system i.e. "Ubuntu".

In the screenshot (bottom half): GNU GRUB version 2.02~beta2-9

After booting the system i.e. "Ubuntu", run relevant command to check the version of GRUB package (grub-install --version is relevant and most straightforward).

$ grub-install --version
grub-install (GRUB) 2.02~beta2-9

How is this relevant? Because grub-install and update-grub commands are both provided by the same package grub2-common. Given that the boot loader menu is created and updated using tools from the same package, the printed version at top of boot loader menu will be the same.

Label (3) explained

This hint requires to be set up manually, since the default background image of boot loader menu is none (just plain black). The background image must be 8-bit depth.

If desktop-base package is installed on your system, such background images that are made specially for GRUB are readily found with file name suffix *grub.png in the target directory.

$ ls /usr/share/images/desktop-base/*grub.png
/usr/share/images/desktop-base/desktop-grub.png
/usr/share/images/desktop-base/joy-grub.png
/usr/share/images/desktop-base/moreblue-orbit-grub.png
/usr/share/images/desktop-base/spacefun-grub.png

To set up the background image:

  1. Open /etc/default/grub file as the superuser, then add the line GRUB_BACKGROUND= with full path to the image of choice and quoted.

    $ sudo nano /etc/default/grub 
    ...
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
    GRUB_CMDLINE_LINUX=""
    
    # Show background in GRUB boot menu
    GRUB_BACKGROUND="/usr/share/images/desktop-base/spacefun-grub.png"
    ...
    
  2. Then, run sudo update-grub to update /boot/grub/grub.cfg that includes the boot loader menu. User will see similar output to the following.

    $ sudo update-grub
    Generating grub configuration file ...
    Found background: /usr/share/images/desktop-base/spacefun-grub.png
    Found background image: /usr/share/images/desktop-base/spacefun-grub.png
    Found linux image: /boot/vmlinuz-3.13.0-24-generic
    Found initrd image: /boot/initrd.img-3.13.0-24-generic
    Found memtest86+ image: /boot/memtest86+.elf
    Found memtest86+ image: /boot/memtest86+.bin
    Found Ubuntu 14.04.5 LTS (14.04) on /dev/sda3
    done
    
  3. Reboot the machine and see if the boot loader menu had any visible changes made by the update command from the system.

Else, repeat steps for other systems, one at a time. The repeated steps would have been unnecessary, should the user aware of which system had control over the boot loader menu (again, this depends on how the installation was made).

Disclaimer

This answer explains for proven and well tested criteria for BIOS system with multi boot setup using GNU GRUB PC/BIOS version. The following exceptions will apply.

  • For UEFI system counterpart using GNU GRUB EFI version, it is not guaranteed or not known if the criteria would appear to be the same as described above.

  • Emphasis is given to the looks of boot loader menu (how it may appear different i.e. top half of screenshot) rather than to demonstrate how the chainloading works. As such, regarding "how multi boot was set up as seen in the screenshot" would not be explained in this answer.

  • If multi boot setup is ever made of exactly same copies of similar operating system i.e. Ubuntu 14.04, Kubuntu 14.04, Xubuntu 14.04, etc., then the only reliable way to know from which partition the user had booted is label (3).

  • Label (3) might work better using custom background image that explicitly writes from which it is booted i.e. "This boot menu is managed from /dev/sda1". Similarly, regarding "how to create custom background image for GRUB" would not be explained in this answer.

TL;DR Look at the boot loader menu before booting any of the installed systems. The easiest and most reliable way to know is label (3), which is to set up GRUB background image manually.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .