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.
6 Answers
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.
-
interesting! does that mean my solution also has a better accuracy rate then Ravexina's and Katu's?– tatsuMay 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– muruMay 10, 2017 at 11:51 -
1yes 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?– tatsuMay 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.– muruMay 10, 2017 at 15:31 -
5Does 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
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.
-
2An 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
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
-
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– tatsuMay 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.– mook765May 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
-
-
@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
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 sda3
but 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 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.– user37165May 11, 2017 at 14:08
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
-
2It'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?– user595510May 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
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.
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:
Open
/etc/default/grub
file as the superuser, then add the lineGRUB_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" ...
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
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.
/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.