Problème :::
J'installe Redhat 5.10 x64 sur le serveur qui avait un disque dur défectueux. J'ai retiré l'ancien disque dur défectueux et j'en ai installé un nouveau avec une capacité de 500 Go et après l'installation, j'ai besoin de copier certaines données de l'ancien disque dur vers le nouveau disque dur sous / u001. J'ai donc connecté un ancien disque dur (320 Go) au serveur. Il apparaît fdisk -lmais quand j'essaie de monter en utilisant
montage sudo / dev / sdb2 ou / dev / sdb5
Remarque: l'ancien fdisk -l
disque dur avait également installé l'ancien système d'exploitation, comme vous pouvez le voir dans / dev / sda = Nouveau disque dur
/ dev / sdb = Ancien disque dur
Le périphérique est déjà monté ou la ressource est occupée
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 25 200781 83 Linux
/dev/sda2 26 10346 82903432+ 8e Linux LVM
/dev/sda3 10347 11390 8385930 82 Linux swap / Solaris
/dev/sda4 11391 60801 396893857+ 5 Extended
/dev/sda5 11391 60801 396893826 8e Linux LVM
Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 13 104391 83 Linux
/dev/sdb2 14 10242 82164442+ 8e Linux LVM
/dev/sdb3 10243 11286 8385930 82 Linux swap / Solaris
/dev/sdb4 11287 38888 221713065 5 Extended
/dev/sdb5 11287 38888 221713033+ 8e Linux LVM
[admin@testsrv ~]$ sudo mount /dev/sdb2 /media/test/
mount: /dev/sdb2 already mounted or /media/test/ busy
[admin@testsrv ~]$ sudo mount /dev/sdb5 /media/test/
mount: /dev/sdb5 already mounted or /media/test/ busy
Résultat du montage :::
/dev/mapper/VolGroup00_root-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/VolGroup00_u001-LogVol00 on /u001/app/oracle type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
PVDISPLAY :: sortie
sudo pvdisplay
--- Physical volume ---
PV Name /dev/sda5
VG Name VolGroup00_u001
PV Size 378.51 GB / not usable 7.63 MB
Allocatable yes (but full)
PE Size (KByte) 32768
Total PE 12112
Free PE 0
Allocated PE 12112
PV UUID E2ibW6-uaDJ-7FMA-OZS0-sApR-DNwK-0jO3Ob
--- Physical volume ---
PV Name /dev/sda2
VG Name VolGroup00_root
PV Size 79.06 GB / not usable 392.50 KB
Allocatable yes
PE Size (KByte) 32768
Total PE 2530
Free PE 1
Allocated PE 2529
PV UUID YSGQwx-yIsO-CR0C-4G6r-GI9O-nUya-gE22yk
LVMDISkSCAN :: Output
sudo lvmdiskscan
/dev/ramdisk [ 16.00 MB]
/dev/root [ 79.03 GB]
/dev/ram [ 16.00 MB]
/dev/sda1 [ 196.08 MB]
/dev/mapper/ddf1_4035305a8680822620202020202020203532aa703a354a45 [ 297.90 GB]
/dev/ram2 [ 16.00 MB]
/dev/sda2 [ 79.06 GB] LVM physical volume
/dev/mapper/ddf1_4035305a8680822620202020202020203532aa703a354a45p1 [ 101.94 MB]
/dev/ram3 [ 16.00 MB]
/dev/sda3 [ 8.00 GB]
/dev/mapper/ddf1_4035305a8680822620202020202020203532aa703a354a45p2 [ 78.36 GB] LVM physical volume
/dev/ram4 [ 16.00 MB]
/dev/mapper/ddf1_4035305a8680822620202020202020203532aa703a354a45p3 [ 8.00 GB]
/dev/ram5 [ 16.00 MB]
/dev/sda5 [ 378.51 GB] LVM physical volume
/dev/mapper/ddf1_4035305a8680822620202020202020203532aa703a354a45p5 [ 211.44 GB] LVM physical volume
/dev/ram6 [ 16.00 MB]
/dev/VolGroup00_ora/LogVol00 [ 211.44 GB]
/dev/ram7 [ 16.00 MB]
/dev/VolGroup00_u001/LogVol00 [ 378.50 GB]
/dev/ram8 [ 16.00 MB]
/dev/ram9 [ 16.00 MB]
/dev/ram10 [ 16.00 MB]
/dev/ram11 [ 16.00 MB]
/dev/ram12 [ 16.00 MB]
/dev/ram13 [ 16.00 MB]
/dev/ram14 [ 16.00 MB]
/dev/ram15 [ 16.00 MB]
/dev/sdb1 [ 101.94 MB]
/dev/sdb2 [ 78.36 GB]
/dev/sdb3 [ 8.00 GB]
/dev/sdb5 [ 211.44 GB]
3 disks
25 partitions
0 LVM physical volume whole disks
4 LVM physical volumes
filesystems
rhel
mount
OmiPenguin
la source
la source
mount?findmntoumount?lsof +D /media/test/serait utilelvdisplayquels périphériques LVM sont détectés. Vous devriez pouvoir y accéder au lieu de/dev/sdbX.Réponses:
Même en 5.x, RHEL utilisait LVM par défaut. Vous devrez d'abord effectuer quelques étapes avant de pouvoir monter des volumes LVM.
Si vous avez utilisé le même nom de VG sur le nouveau disque que sur l'ancien, vous avez un petit problème: vous avez deux VG portant le même nom. Pour identifier de manière unique les VG que vous souhaitez manipuler (c'est-à-dire celui qui est activé
/dev/sdb), vous aurez besoin des VG UUID. Courir:pour répertorier tous les PV LVM détectés, y compris leurs UUID VG. Vous verrez également le nom VG de chaque partition, afin que vous puissiez voir s'il existe ou non des conflits de noms.
LVM est dans l'ensemble assez intelligent pour ne pas gâcher votre configuration VG active à moins que vous ne vous mettiez vraiment en quatre pour la confondre. Donc, si la
pvscommande mentionnée ci-dessus n'affiche rien/dev/sdb, exécutezvgscanpuis réessayez.Une fois que vous connaissez les UUID VG, vous pouvez utiliser la commande vgrename pour renommer les VG en conflit. S'il n'y a pas de conflits de noms, vous pouvez passer à
vgchange.(Afin de monter le ou les LV à l'intérieur d'un VG, vous devrez activer le VG, et un VG ne s'activera pas si son nom est en conflit avec un VG déjà existant.)
La commande pour renommer un VG ressemble à ceci:
où la
Zvlifi-...soupe à l' alphabet est le VG UUID, et l'autre paramètre n'est que le nouveau nom de ce VG.Une fois les conflits de nom VG résolus (ou s'il n'y a pas de conflit en premier lieu), vous devrez activer le ou les VG
/dev/sdb. Vous pouvez simplement activer tous les VG non activés que LVM voit avec cette commande:Lors de l'activation d'un VG, les noms (liens) des périphériques de tous les LV à l'intérieur apparaîtront comme
/dev/mapper/<VG name>-<LV name>. (Aussi/dev/<VG name>/<LV name>pour des raisons de compatibilité héritées.)À ce stade, vous pouvez les monter comme d'habitude.
la source
vgchange -aymount -t ext4 /dev/mapper/my--server--vg-root /tmp/myserverSi par exemple
impressions
vérifiez s'il existe un processus utilisant ce périphérique (/ dev / sda1).
Il s'agit souvent d'un processus fsck qui s'exécute automatiquement au démarrage du système. Vous pouvez le vérifier rapidement, par exemple en
la source
J'ai fait face à une telle situation. L'expérience et la solution sont racontées dans mon blog .
l'extrait est ici:
Erreur: montage: / dev / mapper / sauvegarde STORBCK déjà montée ou / STORBCK occupé?
Diagnostic: lorsque nous essayons de monter le / STORBCK FS, nous obtenons l'erreur mentionnée ci-dessus.
Résolution: 1. Comme l'autre FS est devenu en lecture seule, j'ai arrêté / démarré le service iscsi. il s'est connecté avec succès à l'appareil. /etc/init.d/iscsi stop /etc/init.d/iscsi start https://manastri.blogspot.in/2016/11/mount-devmapperstorbck-backup-already.html
la source