Comment savoir à partir de quelle partition j'ai démarré?

12

J'ai une machine qui a des partitions multi-boot. J'ai Ubuntu 14.04 sur une partition, Ubuntu 15.04 sur la deuxième et Ubuntu 16.04 sur une troisième. Existe-t-il un moyen de savoir, à partir de la ligne de commande, à partir de quelle partition j'ai démarré, afin de vous trouver sur quelle partition est celle /boot/grub/grub.cfgqui a été utilisée pour le processus de démarrage? J'ai /boot/grub/grub.cfg sur chacune des trois partitions.

Kevin Wilson
la source
3
Vous ne pouvez pas faire cela avec une généralité et une fiabilité absolues. Pour ce que vous savez, le /boot/grub/grub.cfgfichier utilisé pour le démarrage aurait pu être supprimé, cette partition aurait pu être supprimée de la table de partition et ce disque supprimé physiquement du système.
Federico Poloni

Réponses:

10

Une fois que GRUB a transféré le démarrage au noyau, le noyau n'a aucune idée de ce qui l'a démarré, et /bootpeut-être pas celui que GRUB a utilisé. Vous pouvez vérifier les temps d'accès de boot/grub/grub.cfgchacune des partitions pour voir laquelle a été accédée le plus récemment. Cela pourrait vous dire quel fichier de configuration de la partition GRUB a utilisé.

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

Si les temps d'accès ne sont pas mis à jour, vous devrez rechercher toute différence dans les paramètres du noyau utilisés par les différents fichiers de configuration GRUB. Si vous pouvez les modifier, par exemple, ajouter foo=1, foo=2etc. pour GRUB_CMDLINE_LINUXdans chacun d'eux, courir sudo update-grub2et redémarrer, vous pouvez vérifier /proc/cmdlinepour voir quelles de ces valeurs ont été utilisées.

muru
la source
intéressant! cela signifie-t-il que ma solution a également un meilleur taux de précision que celui de Ravexina et Katu?
tatsu
@tatsu IMO toutes les autres réponses sont incorrectes - Ravexina localise la partition où elle /bootse trouve, mais ce n'est peut-être pas ce que grub a utilisé, et Katu et vous trouvez que la partition montée /est montée, mais, comme Ravexina l'a noté, cela a probablement encore moins de connexion
muru
1
oui, mais comment le démontage peut-il faire autre chose que l'échec sur la partition sur laquelle vous êtes monté: les disques fournissent des informations telles que l'adresse du périphérique monté, toutes les informations d'identification dont vous pourriez avoir besoin quant à celle que vous venez de tenter de démonter. Je suis le premier à admettre que ma solution est moche mais elle a un taux de réussite de 100%, non?
tatsu
1
Taux de réussite @tatsu pour quoi? Trouver la partition montée /, bien sûr. Trouver la configuration GRUB de la partition utilisée lors du démarrage? Je ne vois pas comment cela se rapporte.
muru
4
Est-ce que grub définit réellement cet horodatage d'accès, étant donné qu'il s'agit de son propre DOS et qu'il n'est pas lié par les conventions des pilotes de système de fichiers Linux?
rackandboneman
4

Comme vous le savez, le fichier que vous recherchez se trouve dans le /bootrépertoire de votre système en cours d'exécution. soit /bootune partition séparée, soit ce n'est pas le cas; Si votre /bootpartition est distincte, vous devez la rechercher:

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

Signifie que celui grub.cfgqui a été utilisé se trouve dans sda2.

Sinon, vous devez rechercher root:

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

cette fois, il est situé dans sda1.

Ou même pour le plaisir, nous pouvons vérifier les paramètres de temps de démarrage:

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

puis utilisez UUIDpour savoir quelle partition est votre racine.

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

Ce qui signifie de sda1.

Vous pouvez également vérifier ces paramètres de démarrage pour voir lequel de vos grub.cfgfichiers les contient, cela ne fonctionne que lorsque vos paramètres de démarrage grub.cfgsont différents les uns des autres.

Ravexina
la source
2
Un moyen plus simple (qui ne nécessite pas de privilèges de super-utilisateur) de trouver le nœud de périphérique derrière un UUID de système de fichiers serait readlink -f /dev/disk/by-uuid/<UUID>.
David Foerster
3

Pour afficher le périphérique contenant le système de fichiers racine actuellement monté:

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

Pour afficher la version de sortie d'Ubuntu en cours d'exécution:

lsb_release -rs
David Foerster
la source
cela fait beaucoup de sens en ce qui concerne la question et semble être la réponse la plus appropriée à ce jour. Je parie que deux distributions sur sa configuration n'ont pas le même numéro de version qu'il utilisera à lsb_release -rschaque fois. KISS
tatsu
Malheureusement ça ne fonctionne pas. J'ai testé votre commande sur ma machine avec plusieurs OS, seul mon "master`-OS a installé grub dans MBR, d'autres OS ont installé Grub dans le PBR, la commande semble montrer l'emplacement où l'OS a installé Grub, mais ne le fait pas montrer à partir de quel OS Grub charge le fichier de configuration
mook765
@ mook765: Ma réponse n'a absolument rien à voir avec Grub ou MBR (ou tout type de chargeur de démarrage ou de table de partition). Je ne sais pas exactement ce que vous avez essayé et ce que vous attendiez de voir.
David Foerster
Alors cette réponse n'a rien à voir avec la question ...
mook765
@ mook765: Si vous le prenez à la lettre, alors oui. Cependant, il me semble qu'OP veut savoir laquelle de ses multiples installations Ubuntu est actuellement démarrée et pour cela ma réponse devrait être très bien.
David Foerster
2

Nous pourrions ajouter une simple entrée de menu personnalisée dans chaque système d'exploitation et nous verrions dans le menu Grub à partir duquel OS Grub a chargé son fichier de configuration.

Exemple:

Nous démarrons en 16.04 et éditons le fichier /etc/grub.d/40_custompour ajouter une entrée de menu.

#! / bin / sh
exec queue -n +3 $ 0
# Ce fichier permet d'ajouter facilement des entrées de menu personnalisées. Tapez simplement le
# entrées de menu que vous souhaitez ajouter après ce commentaire. Attention à ne pas changer
# la ligne 'exec tail' ci-dessus.
#

menuentry 'grub.conf chargé depuis 16.04' {        
            redémarrer  
    }

Nous nous assurons que le fichier est exécutable et exécuté sudo update-grub.

Ensuite, nous faisons les mêmes changements dans les autres systèmes d'exploitation, nous utilisons simplement des noms différents pour l'entrée de menu, ig nous changeons 16.04en 15.04et ainsi de suite.

Si nous sélectionnons cette entrée de menu dans le menu Grub lors du démarrage, la machine va simplement redémarrer, nous les avons créés non pas pour démarrer un OS, mais pour voir quel OS est réellement utilisé pour charger grub.conf.

Information additionnelle

Ce type de confusion apparaît, lorsque nous installons plusieurs systèmes d'exploitation qui utilisent tous Grub et lors de l'installation d'un système d'exploitation, nous choisissons le même emplacement du chargeur de démarrage. Nous avons en effet besoin d'un seul système d'exploitation qui installe Grub, Grub peut démarrer dans n'importe quelle distribution Linux, donc si nous avons une distribution installée (y compris Grub), nous pourrions installer des systèmes d'exploitation supplémentaires sans installer Grub.

Dans les installations héritées, il est assez facile de gérer l'emplacement pour l'installation du chargeur de démarrage, car nous pouvons choisir l'enregistrement de démarrage de la partition comme emplacement, mais nous devons prendre soin de choisir la bonne partition. Ainsi, un système d'exploitation installe le chargeur de démarrage sur le MBR et des systèmes d'exploitation supplémentaires installent le chargeur de démarrage sur le PBR de la partition du système d'exploitation. Cette possibilité n'est disponible que lorsque nous utilisons l' Something elseoption -pendant l'installation.

Dans les installations UEFI, c'est un peu plus étrange, le chargeur de démarrage sera installé dans un dossier dans la partition système EFI (ESP) et plusieurs chargeurs de démarrage peuvent facilement coexister. Le problème ici est que toutes les versions d'Ubuntu et aussi certaines autres distributions linux installeront Grub dans le même dossier dans l'ESP et nous n'avons pas le choix. Ainsi, l'installation d'une distribution Linux supplémentaire écraserait notre chargeur de démarrage déjà existant. La seule façon que je connais pour éviter cela est de démarrer dans une session en direct et de démarrer le programme d'installation avec sudo ubiquity -b.

Une autre solution simple

Supposons que trois distributions Linux soient installées sur les partitions sda1, sda2et sda3. Maintenant, nous examinons les entrées du menu de démarrage de Grub. Au démarrage, nous verrons quelque chose comme ceci:

1 Ubuntu
2 options avancées pour Ubuntu
3 Test de mémoire (memtest86 +)
4 Test de mémoire (memtest86 +, console série 115200)
5 Ubuntu (sur / dev / sda2)
6 Options avancées pour Ubuntu (sur / dev / sda2)
7 Ubuntu 17.04 (sur / dev / sda3)
8 options avancées pour Ubuntu (sur / dev / sda3)

Les deux premières entrées sont les entrées de l'OS qui a généré le grub.conffichier que nous utilisons réellement. Les entrées # 3 et # 4 ne sont pas intéressantes pour le moment. Les entrées # 5, # 6, # 7 et # 8 sont les entrées qui ont été générées avec l'OS-prober et nous voyons sur quelles partitions résident les OS pour ces entrées. Donc, dans le cas de ce petit exemple, nous pouvons conclure que le grub.configfichier que nous utilisons réellement n'appartient pas au système d'exploitation sda2ou sda3à celui-ci sda1. Dans le cas où un ou plusieurs systèmes d'exploitation sont installés avec une /bootpartition séparée, nous devons vérifier quelle /bootpartition appartient à quel système d'exploitation, mais cela se fait facilement en exécutant la findmntcommande-dans chaque système d'exploitation.

mook765
la source
+1 Malgré sa longueur, cette réponse comprend en fait des points pertinents. Pour les systèmes BIOS, les utilisateurs qui effectuent plusieurs démarrages devraient préférer "autre chose" dans le programme d'installation pour avoir plus de contrôle; Pas besoin de forcer "à ne pas installer le chargeur de démarrage GRUB" (voir mon ancienne réponse ). Pour les systèmes UEFI, la configuration multi-démarrage semble être très inexpliquée ou non testée.
clearkimura
1
lsblk

Et vérifiez dans quel disque est monté /. Veuillez lire les commentaires ci-dessous ou la réponse de Ravexina si vous en avez /bootdans vos points montés.

Si vous n'êtes pas sûr, vérifiez l'UUID

lsblk -o UUID,NAME,SIZE,MOUNTPOINT
Katu
la source
2
Ce n'est pas vrai, et si mon /bootest une partition séparée? /boot/grub/grub.cfgn'est alors pas situé dans la /partition.
Ravexina
@Ravexina Obtenez technique, cela pourrait être vrai. Cependant, pour les besoins de cet utilisateur, la /partition ne compte-t- elle pas ?
@MarkYisri Je suppose que je devrais dire que ce n'est pas toujours vrai, mais l'OP nous dit qu'il a obtenu le fichier sur trois partitions différentes, donc je suppose qu'il vaut mieux vérifier d'abord une autre /boot.
Ravexina
1
Merci d'avoir signalé @Ravexina que j'ai mis à jour la réponse.
Katu
0

Pour savoir à partir de quelle partition l'utilisateur a démarré, consultez le menu du chargeur de démarrage avant de démarrer l'un des systèmes installés. C'est difficile à dire sans voir le menu du chargeur de démarrage.

Où regarder

Dans les captures d'écran combinées suivantes, j'ai étiqueté trois conseils que l'on pourrait savoir à partir de quelle partition l'utilisateur a démarré.

Menu de démarrage multiple utilisant la version GNU GRUB PC / BIOS avec annotation

Étiquette (1): entrées du menu GNU GRUB sous la première entrée

Étiquette (2): version GNU GRUB en haut du menu du chargeur de démarrage

Étiquette (3): image d'arrière-plan GNU GRUB (configuration manuelle requise)

L'astuce la plus apparente est label (3), qui consiste à changer l'image d'arrière-plan GNU GRUB sur le système qui contrôle le menu du chargeur de démarrage. C'est le plus simple à dire, à condition que l'utilisateur l'ait configuré au préalable.

Étiquette (1) expliquée

Recherchez la partition qui n'est pas répertoriée dans les entrées de menu sous la première entrée. Dans la capture d'écran, seuls deux systèmes d'exploitation sont installés, à savoir "Ubuntu" et "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)

Ce dernier l'a mentionné (on /dev/sda3), ce qui signifie que le premier pourrait être situé sur /dev/sda2ou /dev/sda1. Pour être sûr, après le démarrage du système, c'est-à-dire "Ubuntu", exécutez la commande appropriée pour répertorier les partitions disponibles ( lsblksemble être la plus simple).

$ 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 

Ce n'est qu'après avoir comparé à la sortie de lsblk, que nous savons que le système, c'est-à-dire "Ubuntu", se trouve dans /dev/sda2(qui n'était pas répertorié dans les entrées de menu) à partir duquel le menu du chargeur de démarrage est géré.

Étiquette (2) expliquée

Recherchez la version GRUB imprimée en haut du menu du chargeur de démarrage. Notez cette version et comparez-la à la version GRUB qui se trouve sur le système démarré, c'est-à-dire "Ubuntu".

Dans la capture d'écran (moitié inférieure): GNU GRUB version 2.02~beta2-9

Après avoir démarré le système, c'est-à-dire "Ubuntu", exécutez la commande appropriée pour vérifier la version du package GRUB ( grub-install --versionest pertinente et la plus simple).

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

En quoi est-ce pertinent? Parce que grub-installet les update-grubcommandes sont toutes deux fournies par le même package grub2-common. Étant donné que le menu du chargeur de démarrage est créé et mis à jour à l'aide d'outils du même package, la version imprimée en haut du menu du chargeur de démarrage sera la même.

Étiquette (3) expliquée

Cette astuce doit être configurée manuellement, car l'image d'arrière-plan par défaut du menu du chargeur de démarrage est aucune (juste noir). L'image d'arrière-plan doit avoir une profondeur de 8 bits.

Si le desktop-basepackage est installé sur votre système, ces images d'arrière-plan spécialement conçues pour GRUB se trouvent facilement avec le suffixe du nom de fichier *grub.pngdans le répertoire cible.

$ 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

Pour configurer l'image d'arrière-plan:

  1. Ouvrez le /etc/default/grubfichier en tant que superutilisateur, puis ajoutez la ligne GRUB_BACKGROUND=avec le chemin d'accès complet à l'image de votre choix et citée.

    $ 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. Ensuite, exécutez sudo update-grubpour mettre à jour /boot/grub/grub.cfgqui inclut le menu du chargeur de démarrage. L'utilisateur verra une sortie similaire à la suivante.

    $ 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. Redémarrez la machine et voyez si le menu du chargeur de démarrage a des modifications visibles apportées par la commande de mise à jour du système.

Sinon, répétez les étapes pour les autres systèmes, un par un. Les étapes répétées auraient été inutiles si l'utilisateur savait quel système contrôlait le menu du chargeur de démarrage (là encore, cela dépend de la façon dont l'installation a été effectuée).

Avertissement

Cette réponse explique les critères éprouvés et bien testés pour le système BIOS avec configuration multi-démarrage utilisant la version PC / BIOS GNU GRUB. Les exceptions suivantes s'appliquent.

  • Pour les homologues du système UEFI utilisant la version GNU GRUB EFI, il n'est pas garanti ou on ne sait pas si les critères semblent être les mêmes que ceux décrits ci-dessus.

  • L'accent est mis sur l' apparence du menu du chargeur de démarrage (comment il peut sembler différent, c'est-à-dire la moitié supérieure de la capture d'écran) plutôt que de montrer comment fonctionne le chargement de chaîne. En tant que tel, concernant "la façon dont le démarrage multiple a été configuré comme indiqué dans la capture d'écran" ne serait pas expliqué dans cette réponse.

  • Si la configuration de démarrage multiple est jamais faite d'exactement les mêmes copies d'un système d'exploitation similaire, c'est-à-dire Ubuntu 14.04, Kubuntu 14.04, Xubuntu 14.04, etc., alors le seul moyen fiable de savoir à partir de quelle partition l'utilisateur a démarré est label (3).

  • L'étiquette (3) pourrait mieux fonctionner en utilisant une image d'arrière-plan personnalisée qui écrit explicitement à partir de laquelle elle est démarrée, c'est-à-dire "Ce menu de démarrage est géré à partir de / dev / sda1". De même, concernant "comment créer une image d'arrière-plan personnalisée pour GRUB" ne serait pas expliqué dans cette réponse.

TL; DR Regardez le menu du chargeur de démarrage avant de démarrer l'un des systèmes installés. Le moyen le plus simple et le plus fiable de savoir est l'étiquette (3), qui consiste à configurer manuellement l'image d'arrière-plan GRUB.

clearkimura
la source