Woher weiß ich, von welcher Partition ich gebootet habe?

12

Ich habe eine Maschine, die Multi-Boot-Partitionen hat. Ich habe Ubuntu 14.04 auf einer Partition, Ubuntu 15.04 auf der zweiten und Ubuntu 16.04 auf einer dritten. Gibt es eine Möglichkeit, von der Kommandozeile aus zu erfahren, von welcher Partition ich gebootet habe, um herauszufinden, auf welcher Partition /boot/grub/grub.cfgder Bootvorgang durchgeführt wurde? Ich habe /boot/grub/grub.cfg auf jeder der drei Partitionen.

Kevin Wilson
quelle
3
Das geht nicht mit absoluter Allgemeinheit und Zuverlässigkeit. Wie Sie wissen, könnte die /boot/grub/grub.cfgzum Booten verwendete Datei gelöscht, diese Partition aus der Partitionstabelle gelöscht und diese Festplatte physisch aus dem System entfernt worden sein.
Federico Poloni

Antworten:

10

Nachdem GRUB das Booten an den Kernel übergeben hat, hat der Kernel keine Ahnung, wie er gestartet wurde, und ist /bootmöglicherweise nicht derjenige, den GRUB verwendet hat. Sie können die Zugriffszeiten boot/grub/grub.cfgin jeder Partition überprüfen, um festzustellen, auf welche Partition zuletzt zugegriffen wurde. Das könnte Ihnen sagen, welche Partitionskonfigurationsdatei GRUB verwendet.

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

Wenn die Zugriffszeiten nicht aktualisiert werden, müssen Sie nach Unterschieden in den Kernel-Parametern suchen, die von den verschiedenen GRUB-Konfigurationsdateien verwendet werden. Wenn Sie sie ändern können, beispielsweise Add foo=1, foo=2etc. zu GRUB_CMDLINE_LINUXin jedem dieser laufen sudo update-grub2und Neustart, dann können Sie überprüfen /proc/cmdline, welche dieser Werte sehen verwendet wurden.

muru
quelle
interessant! Bedeutet das, dass meine Lösung auch eine bessere Genauigkeit aufweist als die von Ravexina und Katu?
Tatsu
@tatsu IMO alle anderen Antworten sind falsch - Ravexina findet die Partition dort, wo sie /bootsich befindet, aber das ist möglicherweise nicht das, was grub verwendet hat, und Sie und Katu finden, dass die gemountete Partition gemountet /ist, aber, wie Ravexina bemerkte, das hat es wahrscheinlich noch weniger eine verbindung
muru
1
Ja, aber wie kann das Aufheben des Ladevorgangs auf der Partition, auf der Sie gemountet sind, möglicherweise etwas anderes bewirken als einen Fehler? Festplatten liefern Informationen wie das Gerät, die gemountete Adresse und alle ID-Informationen, die Sie möglicherweise benötigen, um zu ermitteln, welche Sie gerade versucht haben, den Ladevorgang aufzuheben. Ich gebe als Erster zu, dass meine Lösung hässlich ist, aber eine Erfolgsquote von 100% hat, oder?
Tatsu
1
@tatsu Erfolgsquote für was? Stellen Sie /sicher, dass Sie die Partition gefunden haben, auf der sie installiert ist. Finden Sie heraus, welche GRUB-Konfiguration der Partition beim Booten verwendet wurde? Ich verstehe nicht, wie das zusammenhängt.
muru
4
Stellt grub tatsächlich diesen Zugriffszeitstempel ein, vorausgesetzt, es ist ein eigenes DOS und nicht an die Konventionen der Linux-Dateisystemtreiber gebunden?
Rackandboneman
4

Wie Sie wissen, befindet sich die gesuchte Datei im /bootVerzeichnis Ihres laufenden Systems. entweder /bootist eine separate Partition oder nicht; Wenn /bootes sich um eine separate Partition handelt, sollten Sie danach suchen:

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

Bedeutet, dass sich das, grub.cfgwas verwendet wurde, in befindet sda2.

Andernfalls sollten Sie suchen root:

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

Dieses Mal befindet es sich in sda1.

Oder auch zum Spaß können wir die Boot-Zeit-Parameter überprüfen:

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

Verwenden Sie dann, UUIDum herauszufinden, welche Partition Ihre Wurzel ist.

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

Welches bedeutet aus sda1.

Sie können auch überprüfen, ob diese Boot-Parameter in einer Ihrer grub.cfgDateien enthalten sind. Dies funktioniert nur, wenn sich die Boot-Parameter in grub.cfgvoneinander unterscheiden.

Ravexina
quelle
2
Eine einfachere Möglichkeit (die keine Superuser-Berechtigungen erfordert), den Geräteknoten hinter einer Dateisystem-UUID zu finden, wäre readlink -f /dev/disk/by-uuid/<UUID>.
David Foerster
3

So zeigen Sie das Gerät an, auf dem sich das aktuell gemountete Root-Dateisystem befindet:

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

So zeigen Sie die aktuell ausgeführte Ubuntu-Release-Version an:

lsb_release -rs
David Foerster
quelle
das macht tatsächlich eine Menge Sinn in Bezug auf die Frage und scheint die passendste Antwort noch zu sein. Ich wette, dass keine zwei Distributionen in seinem Setup dieselbe Versionsnummer haben, die er lsb_release -rsjedes Mal verwenden wird. KISS
Tatsu
Das geht leider nicht. Ich habe Ihren Befehl auf meinem Computer mit mehreren Betriebssystemen getestet. Nur auf meinem "Master" -Betriebssystem ist Grub im MBR installiert. Auf anderen Betriebssystemen ist Grub im PBR installiert. Der Befehl scheint den Ort anzuzeigen, an dem das Betriebssystem Grub installiert hat, aber nicht zeigen, von welchem ​​OS Grub die Konfigurationsdatei lädt
mook765
@ mook765: Meine Antwort hat absolut nichts mit Grub oder MBR zu tun (oder mit irgendeinem Bootloader oder Partitionstabellentyp wirklich). Ich bin mir nicht sicher, was genau du versucht hast und was du erwartet hast.
David Foerster
Dann hat diese Antwort nichts mit der Frage zu tun ...
mook765
@ mook765: Wenn du es wörtlich nimmst, dann ja. Mir scheint jedoch, dass OP wissen möchte, welche seiner mehreren Ubuntu-Installationen gerade gebootet wird, und dafür sollte meine Antwort in Ordnung sein.
David Foerster
2

Wir könnten in jedem Betriebssystem einen einfachen benutzerdefinierten Menüeintrag hinzufügen und im Grub-Menü sehen, von welchem ​​Betriebssystem Grub die Konfigurationsdatei geladen hat.

Beispiel:

Wir booten in 16.04 und bearbeiten die Datei /etc/grub.d/40_custom, um einen Menüeintrag hinzuzufügen.

#! / bin / sh
Exec Tail -n +3 $ 0
# Diese Datei bietet eine einfache Möglichkeit, benutzerdefinierte Menüeinträge hinzuzufügen. Tippen Sie einfach die
# Menüeinträge, die Sie nach diesem Kommentar hinzufügen möchten. Achten Sie darauf, sich nicht zu ändern
# die 'exec tail' Zeile darüber.
#

Menüeintrag 'grub.conf vom 16.04' {        
            neustarten  
    }

Wir stellen sicher, dass die Datei ausführbar ist und ausgeführt wird sudo update-grub.

Dann nehmen wir die gleichen Änderungen in den anderen Betriebssystemen vor, wir verwenden nur andere Namen für den Menüeintrag, z. B. ändern wir 16.04zu 15.04und so weiter.

Wenn wir diesen Menüeintrag während des Bootens im Grub-Menü auswählen, wird die Maschine nur neu gestartet. Wir haben sie erstellt, um kein Betriebssystem zu booten, sondern um zu sehen, welches Betriebssystem tatsächlich zum Laden verwendet wird grub.conf.

Zusätzliche Information

Diese Art von Verwirrung tritt auf, wenn wir mehrere Betriebssysteme installieren, die alle Grub verwenden, und während der Installation eines Betriebssystems denselben Bootloader-Speicherort auswählen. Wir brauchen in der Tat nur ein Betriebssystem, das Grub installiert. Grub kann in jede Linux-Distribution booten. Wenn also eine Distribution (einschließlich Grub) installiert ist, können wir zusätzliche Betriebssysteme installieren, ohne Grub zu installieren.

Bei älteren Installationen ist es ziemlich einfach, den Speicherort für die Bootloader-Installation zu ermitteln, da wir den Partitions-Boot-Record als Speicherort auswählen können, aber wir müssen darauf achten, die richtige Partition auszuwählen. Ein Betriebssystem installiert also den Bootloader auf dem MBR und weitere Betriebssysteme installieren den Bootloader auf dem PBR der OS-Partition. Diese Möglichkeit haben wir nur, wenn wir Something elsewährend der Installation die -Option verwenden.

Bei UEFI-Installationen ist es etwas seltsamer, der Bootloader wird in einem Ordner in der EFI-Systempartition (ESP) installiert, und mehrere Bootloader können problemlos gleichzeitig installiert werden. Das Problem dabei ist, dass alle Ubuntu-Varianten und auch einige andere Linux-Distributionen Grub im selben Ordner im ESP installieren und wir keine Wahl haben. Das Installieren einer zusätzlichen Linux-Distribution würde also unseren bereits vorhandenen Bootloader überschreiben. Die einzige Möglichkeit, dies zu vermeiden, besteht darin, eine Live-Sitzung zu starten und das Installationsprogramm mit zu starten sudo ubiquity -b.

Eine andere einfache Lösung

Nehmen wir an , dass wir drei Linux - Distributionen auf den Partitionen installiert haben sda1, sda2und sda3. Nun werfen wir einen Blick auf Grubs Bootmenü-Einträge. Während des Bootens werden wir so etwas sehen:

1 Ubuntu
2 Erweiterte Optionen für Ubuntu
3 Gedächtnistest (memtest86 +)
4 Speichertest (memtest86 +, serielle Konsole 115200)
5 Ubuntu (on / dev / sda2)
6 Erweiterte Optionen für Ubuntu (unter / dev / sda2)
7 Ubuntu 17.04 (on / dev / sda3)
8 Erweiterte Optionen für Ubuntu (unter / dev / sda3)

Die ersten beiden Einträge sind die Einträge für das Betriebssystem, das die grub.conftatsächlich verwendete -Datei generiert hat . Die Einträge # 3 und # 4 sind im Moment nicht interessant. Die Einträge # 5, # 6, # 7 und # 8 sind die Einträge, die mit dem OS-Prober generiert wurden, und wir sehen, auf welchen Partitionen sich die Betriebssysteme für diese Einträge befinden. In diesem kleinen Beispiel können wir also schließen, dass die grub.configtatsächlich verwendete -Datei nicht zum eingeschalteten Betriebssystem sda2oder sda3aber zum eingeschalteten Betriebssystem gehört sda1. /bootWenn ein oder mehrere Betriebssysteme mit einer separaten -Partition installiert sind, müssten wir herausfinden, welche /boot-Partition zu welchem ​​Betriebssystem gehört. Dies kann jedoch problemlos durch Ausführen des findmnt-Befehls in jedem Betriebssystem erfolgen.

mook765
quelle
+1 Trotz langwieriger Antwort enthält diese tatsächlich relevante Punkte. Bei BIOS-Systemen sollten Benutzer, die mehrere Startvorgänge ausführen, "Etwas anderes" im Installationsprogramm vorziehen, um mehr Kontrolle zu haben. Keine Notwendigkeit zu erzwingen, "GRUB-Bootloader nicht zu installieren" (siehe meine ältere Antwort ). Bei UEFI-Systemen scheint das Multi-Boot-Setup weitgehend ungeklärt oder ungetestet zu sein.
Clearkimura
1
lsblk

Und überprüfen Sie, in welcher Festplatte gemountet ist /. Bitte lesen Sie die Kommentare unten oder Ravexinas Antwort, wenn Sie /bootin Ihren berittenen Punkten haben.

Wenn Sie sich nicht sicher sind, überprüfen Sie die UUID

lsblk -o UUID,NAME,SIZE,MOUNTPOINT
Katu
quelle
2
Es ist nicht wahr, was ist, wenn meine /booteine separate Partition ist? dann /boot/grub/grub.cfgbefindet sich nicht in der /Partition.
Ravexina
@Ravexina Werde technisch, das könnte stimmen. Zählt die /Partition für die Zwecke dieses Benutzers jedoch nicht ?
@MarkYisri Ich denke, dass ich sagen sollte, dass es nicht immer wahr ist, aber das OP sagt uns, dass er die Datei auf drei verschiedenen Partitionen hat. Ich denke, es ist besser, zuerst nach einer separaten zu /bootsuchen.
Ravexina
1
Vielen Dank für den Hinweis auf @Ravexina Ich habe die Antwort aktualisiert.
Katu
0

Um herauszufinden, von welcher Partition der Benutzer gestartet hat, sehen Sie sich das Bootloader-Menü an, bevor Sie eines der installierten Systeme starten . Es ist schwer zu sagen, ohne das Bootloader-Menü zu sehen.

Wohin schauen?

In den folgenden kombinierten Screenshots habe ich drei Hinweise angegeben, von denen man möglicherweise weiß, von welcher Partition der Benutzer gebootet hat.

Multi-Boot-Menü mit GNU GRUB PC / BIOS-Version mit Annotation

Label (1): GNU GRUB-Menüeinträge unter dem ersten Eintrag

Label (2): GNU GRUB-Version oben im Bootloader-Menü

Label (3): GNU GRUB-Hintergrundbild (manuelle Einrichtung erforderlich)

Der offensichtlichste Hinweis ist label (3), mit dem das GNU GRUB-Hintergrundbild auf dem System geändert werden soll, auf dem das Bootloader-Menü gesteuert wird. Dies lässt sich am einfachsten feststellen, vorausgesetzt, der Benutzer hat es zuvor eingerichtet.

Label (1) erklärt

Suchen Sie nach Partitionen, die nicht in den Menüeinträgen unter dem ersten Eintrag aufgeführt sind. Im Screenshot sind nur zwei Betriebssysteme installiert, nämlich "Ubuntu" und "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)

Letzterer hat erwähnt (on /dev/sda3), was bedeutet, dass ersterer sich auf /dev/sda2oder befinden könnte /dev/sda1. Um sicherzugehen, führen Sie nach dem Booten des Systems, dh "Ubuntu", den entsprechenden Befehl aus, um die verfügbaren Partitionen aufzulisten ( lsblkscheint am einfachsten zu sein).

$ 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 

Erst nach dem Vergleich mit der Ausgabe von lsblkwissen wir, dass das System zB "Ubuntu" unter /dev/sda2(welches nicht in Menüeinträgen aufgeführt war) von welchem ​​Bootloader-Menü aus verwaltet wird.

Label (2) erklärt

Suchen Sie nach der GRUB-Version, die oben im Bootloader-Menü gedruckt wird. Beachten Sie diese Version und vergleichen Sie sie mit der GRUB-Version, die sich auf dem gebooteten System befindet, dh "Ubuntu".

Im Screenshot (untere Hälfte): GNU GRUB version 2.02~beta2-9

Führen Sie nach dem Booten des Systems, dh "Ubuntu", den entsprechenden Befehl aus, um die Version des GRUB-Pakets zu überprüfen (dies grub-install --versionist relevant und am einfachsten).

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

Wie ist das relevant? Weil grub-installund update-grubBefehle beide von demselben Paket bereitgestellt werden grub2-common. Da das Bootloader-Menü mit Tools aus demselben Paket erstellt und aktualisiert wird, ist die gedruckte Version oben im Bootloader-Menü identisch.

Label (3) erklärt

Dieser Hinweis muss manuell eingerichtet werden, da das Standard-Hintergrundbild des Bootloader-Menüs none ist (nur schwarz). Das Hintergrundbild muss eine Tiefe von 8 Bit haben.

Wenn das desktop-basePaket auf Ihrem System installiert ist, werden solche Hintergrundbilder, die speziell für GRUB erstellt wurden, *grub.pngim Zielverzeichnis leicht mit dem Dateinamensuffix gefunden .

$ 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

So richten Sie das Hintergrundbild ein:

  1. Öffnen Sie die /etc/default/grubDatei als Superuser und fügen Sie die Zeile GRUB_BACKGROUND=mit dem vollständigen Pfad zum gewünschten Bild hinzu.

    $ 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. Führen Sie sudo update-grubdann ein Update aus /boot/grub/grub.cfg, das das Bootloader-Menü enthält. Der Benutzer sieht eine ähnliche Ausgabe wie die folgende.

    $ 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. Starten Sie den Computer neu und prüfen Sie, ob im Bootloader-Menü sichtbare Änderungen durch den Aktualisierungsbefehl des Systems vorgenommen wurden.

Andernfalls wiederholen Sie die Schritte nacheinander für andere Systeme. Die wiederholten Schritte wären unnötig gewesen, wenn der Benutzer gewusst hätte, welches System die Kontrolle über das Bootloader-Menü hatte (dies hängt wiederum davon ab, wie die Installation durchgeführt wurde).

Haftungsausschluss

Diese Antwort erklärt die bewährten und getesteten Kriterien für ein BIOS-System mit Multi-Boot-Setup unter Verwendung der GNU GRUB PC / BIOS-Version. Es gelten die folgenden Ausnahmen.

  • Für UEFI System Pendant Version mit GNU GRUB EFI ist es nicht oder garantiert nicht bekannt, ob die Kriterien anscheinend mit den oben beschriebenen übereinstimmen.

  • Der Schwerpunkt liegt auf dem Aussehen des Bootloader-Menüs (wie es anders aussehen kann, dh in der oberen Hälfte des Screenshots), anstatt zu demonstrieren, wie das Chainloading funktioniert. Daher wird in dieser Antwort nicht erläutert , wie der Mehrfachstart eingerichtet wurde (siehe Screenshot) .

  • Wenn mehrere Boot-Setups mit genau denselben Kopien eines ähnlichen Betriebssystems wie Ubuntu 14.04, Kubuntu 14.04, Xubuntu 14.04 usw. erstellt wurden, ist label (3) die einzige zuverlässige Methode, um festzustellen, von welcher Partition der Benutzer gebootet hat.

  • Label (3) funktioniert möglicherweise besser, wenn ein benutzerdefiniertes Hintergrundbild verwendet wird, das explizit schreibt, von welchem ​​es gestartet wird, z. B. "Dieses Startmenü wird von / dev / sda1 verwaltet". Ebenso wird in dieser Antwort nicht erläutert , wie ein benutzerdefiniertes Hintergrundbild für GRUB erstellt wird .

TL; DR Überprüfen Sie das Bootloader-Menü, bevor Sie eines der installierten Systeme starten . Der einfachste und zuverlässigste Weg, dies herauszufinden, ist label (3), bei dem das GRUB-Hintergrundbild manuell eingerichtet wird.

Clearkimura
quelle