Racine "aléatoire"


#1

C’est simple : lors de l’installatyion, c’était :slight_smile:

/dev/sdc6

Cela l’a été pendant un bon nombre de démarrages d’OMA.
Maintenant, la / est “aléatoire”. Tantôt :slight_smile:

/dev/sdc6
/dev/sdb6
éventuellement /dev/sda6

[root@localhost jjm]# parted -l

Modèle: ATA ST500DM002-1BD14 (scsi)
Disque /dev/sda : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 32,3kB 500GB 500GB primary ntfs démarrage

Modèle: ATA Maxtor 6L080L0 (scsi)
Disque /dev/sdb : 82,0GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 32,3kB 1078MB 1077MB primary linux-swap(v1)
2 1078MB 41,5GB 40,4GB primary btrfs
3 41,5GB 82,0GB 40,4GB primary ext4 démarrage

Modèle: ATA Maxtor 6L100P0 (scsi)
Disque /dev/sdc : 100GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 1049kB 100GB 100GB extended lba
5 2097kB 2146MB 2144MB logical linux-swap(v1)
6 2147MB 55,8GB 53,7GB logical ext4
7 55,8GB 100GB 44,4GB logical ext4

Ce n’est pas grave, mais cela m"ennuie ce manque de cohérence. Comment régler cela?
Il est fait bien des reproches aux systèmes Windows, mais leur partition racine est toujours :slight_smile:

C:\

Merci.


#2

Salut,
pourrais-tu afficher /etc/fstab et le résultat de

blkid

et

df -h

Est-ce que l’ordre de tes disques dans le bios est constant ? Je suppose que tu ne t’amuses pas à les permuter physiquement avant chaque redémarrage. Ou bien, est-ce que tu as plusieurs gestionnaires d’amorçage (plusieurs grubs), par exemple un sur chaque disque ? C’est-à-dire que tu choisirais le disque de démarrage au moment du lancement de ton ordinateur quand le bios s’initialise ?

EDIT: cela pourrait avoir un lien avec ton autre question.


#3

jcl,

Merci pour ta réponse.

Dans le BIOS :slight_smile:

/dev/sdb : 80 Go primary master
/dev/sdc : 100 Go primary slave

/dev/sda 500 Go : SATA, master 1 ou 2 (je ne me souviens plus.

Chaque disque son “grub” :slight_smile:
/dev/sda : le “grub” de nos bons Amis de Redmond jamais modifié, espèce protégée
/dev/sdb : grub2 d’openSUSE Leap 42.2 (/dev/sdb2, Release)
/dev/sdc : grub2 de Mageia 5.1 (/dev/sdc7)

Les deux grub2 peuvent démarrer tous les systèmes (ou presque!)

grub2 de /dev/sdb : Leap 42.2, Tumbleweed (Rolling release), XP, Mageia 5, OpenMandriva
grub2 de /dev/sdc : Mageia, Tumbleweed (as unknown Lin. distr), XP, OpenMandriva. Le grub2 de Mageia 5 ne voit pas Leap 42.2, malgré actualisation : je viens peut-être de trouver la cause. La / de Leap est en BtrFS, système permettant de revenir à un état antérieur comme les points de restauration de Windows, mais disponibles dans le menu de grub2. BtrFS a “tendance” à consommer de l’espace disque avec ses “snapshots”!.
Pour revenir au BIOS, je ne peux modifier l’ordre des disques reconnus par lui.
Mais je peux modifier leur ordre par rapport à la touche F9 qui me permet de choisir quel OS démarrer. Rappel : /dev/sda est pour XP uniquement!
[root@localhost jjm]# df -hT
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
devtmpfs devtmpfs 1,6G 0 1,6G 0% /dev
tmpfs tmpfs 1,6G 25M 1,6G 2% /dev/shm
tmpfs tmpfs 1,6G 1,3M 1,6G 1% /run
tmpfs tmpfs 1,6G 0 1,6G 0% /sys/fs/cgroup
/dev/sdc6 ext4 50G 32G 16G 68% /
tmpfs tmpfs 1,6G 0 1,6G 0% /tmp
tmpfs tmpfs 327M 40K 326M 1% /run/user/1001
F9 : /dev/sdb, /dev/sdc, /dev/sda

Mais le problème ne vient pas de là, puisque le problème est récent, et la config du BIOSrestée inchangée depuis longtemps.

fstab

UUID=2716cce4-bb77-4d16-befe-b6147c90f56c swap swap defaults,noatime 0 0
UUID=b05cb77d-3b8e-4017-aa1b-2da4b7785427 swap swap defaults,noatime 0 0
UUID=b07445f0-82f2-478b-910f-19fdbe259874 / ext4 defaults,noatime 0 1

[root@localhost jjm]# blkid
/dev/sda1: UUID="B020E14B20E1195C" TYPE="ntfs" PARTUUID="0d890d88-01"
/dev/sdb1: UUID="2716cce4-bb77-4d16-befe-b6147c90f56c" TYPE="swap" PARTUUID="000e1c66-01"
/dev/sdb2: UUID="4ebac9be-fbbb-4a6c-b6f9-387fc7a5c04e" UUID_SUB="c53522e7-e764-43ad-a91a-c1a48be79f22" TYPE="btrfs" PTTYPE="dos" PARTUUID="000e1c66-02"
/dev/sdb3: UUID="5f911f3c-99d6-462d-addd-b11ab6fa87e9" TYPE="ext4" PTTYPE="dos" PARTUUID="000e1c66-03"
/dev/sdc5: UUID="b05cb77d-3b8e-4017-aa1b-2da4b7785427" TYPE="swap" PARTUUID="0001e487-05"
/dev/sdc6: UUID="b07445f0-82f2-478b-910f-19fdbe259874" TYPE="ext4" PTTYPE="dos" PARTUUID="0001e487-06"
/dev/sdc7: UUID="bde3327c-68a7-4a41-8678-fc5852b5215f" TYPE="ext4" PTTYPE="dos" PARTUUID="0001e487-07"

    [root@localhost jjm]# df -hT
    Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
    devtmpfs         devtmpfs   1,6G       0  1,6G   0% /dev
    tmpfs            tmpfs      1,6G     25M  1,6G   2% /dev/shm
    tmpfs            tmpfs      1,6G    1,3M  1,6G   1% /run
    tmpfs            tmpfs      1,6G       0  1,6G   0% /sys/fs/cgroup
    /dev/sdc6        ext4        50G     32G   16G  68% /
    tmpfs            tmpfs      1,6G       0  1,6G   0% /tmp
    tmpfs            tmpfs      327M     40K  326M   1% /run/user/1001

Quant à une corrélation entre les deux problèmes, il me semble qu’il n’y en ait pas : la modification du grub2 de /dev/sdc est apparue avant celle de la “racine glissante”.