VMware disk (GPT) krijg ik niet gemount

[Yzord]

Ik ben bezig met Amanda backupserver te installeren op een VM (VMware vSphere) waarop RHEL6 geinstalleerd is. Om voldoende ruimte te hebben voor de servers die ik wil backuppen heb ik er een 3TB disk aan gekoppeld.

Deze wil ik laten mounten op /vtape/amanda, maar het lukt me niet echt. Als ik fdisk -l doe lees ik dus het volgende:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdb: 3298.5 GB, 3298547466240 bytes
255 heads, 63 sectors/track, 401025 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 267350 2147483647+ ee GPT

Doe ik een dmesg | grep sdb, dan krijg ik:

sd 2:0:2:0: [sdb] 6442475520 512-byte logical blocks: (3.29 TB/3.00 TiB)
sd 2:0:2:0: [sdb] Write Protect is off
sd 2:0:2:0: [sdb] Mode Sense: 81 00 00 00
sd 2:0:2:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1
sd 2:0:2:0: [sdb] Attached SCSI disk
dracut: Scanning devices sdb1 for LVM logical volumes vg/swap vg/root

Vraag 1: betekent dracut: Scanning devices sdb1 dat hij de disk al gebruikt voor vg/swap & vg/root?

Dit is de output van df -h:

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg-root 488M 223M 241M 49% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/sda1 194M 36M 149M 20% /boot
/dev/mapper/vg-home 488M 396K 462M 1% /home
/dev/mapper/vg-opt 976M 1.3M 924M 1% /opt
/dev/mapper/vg-tmp 488M 412K 462M 1% /tmp
/dev/mapper/vg-usr 2.0G 452M 1.4G 25% /usr
/dev/mapper/vg-var 976M 28M 898M 3% /var
/dev/mapper/vg-cache 2.0G 857M 993M 47% /var/cache
/dev/mapper/vg-log 2.0G 3.9M 1.9G 1% /var/log

De kernel supports EFI volgens deze output

CONFIG_EFI=y
CONFIG_FB_EFI=y
CONFIG_UEFI_CPER=y
CONFIG_EFI_VARS=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
CONFIG_EFI_PARTITION=y
CONFIG_EARLY_PRINTK_EFI=y

Maar partioneren en formateren van de disk resulteert in resource busy erors:

sfdisk /dev/sdb
Checking that no-one is using this disk right now ...
BLKRRPART: Device or resource busy

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.
Use the --force flag to overrule all checks.

mkfs.ext4 /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
/dev/sdb1 is apparently in use by the system; will not make a filesystem here!

Ik krijg dus op geen enkele manier de disk gemount op /vtape/amanda. GPT is nieuw voor me, dus ik zal vast wel iets niet goed doen, maar ik ben al een heel weekend er aan het sleutelen, maar ik krijg het niet voor elkaar. Wat doe ik fout?

[Thralas]

Yzord schreef op maandag 29 juni 2015 @ 01:00:
Deze wil ik laten mounten op /vtape/amanda, maar het lukt me niet echt. Als ik fdisk -l doe lees ik dus het volgende:

Die eerste regel heb je ook gelezen neem ik aan? Wat heb je ermee gedaan? Hint: gdisk

Dit is de output van df -h:

Dat is aardig, maar volgens mij wil je primair weten wat er allemaal gemount is. lsblk of mount ipv. df is dan handiger.

Vraag 1: betekent dracut: Scanning devices sdb1 dat hij de disk al gebruikt voor vg/swap & vg/root?

Mogelijk. pvdisplay -m of pvs weet meer.

Ik krijg dus op geen enkele manier de disk gemount op /vtape/amanda. GPT is nieuw voor me, dus ik zal vast wel iets niet goed doen, maar ik ben al een heel weekend er aan het sleutelen, maar ik krijg het niet voor elkaar. Wat doe ik fout?

Ik vraag me dan toch een beetje af hoe je gedurende dat weekend er niet op komt om 'fdisk for gpt' of 'how to find disks used for lvm' even door Google te gooien.

Die twee heb je nu cadeau, en mogelijk kom je dan inderdaad tot de conclusie dat sdb gebruikt wordt door lvm.

Het feit dat mkfs je erop wijst dat een partitie reeds in gebruik is betekent dat je eigenlijk al veel te onvoorzichtig bent. Een tool als dd bevat een stuk minder van dat soort safeguards, verzeker je er dus van op welke disk je opereert voordat je dat soort ingrijpende commando's uitvoert.

Let er ook op dat disk device node names niet statisch zijn onder Linux, en zaken als removable drives een shift in drive names kan veroorzaken. Leer jezelf aan disks te labelen (e2label voor extfs, of als je GPT gebruikt kun je iedere willekeurige partitie een label geven) en ze vervolgens te specificeren als /dev/disk/by-[part]label, dan hoef je jezelf niet aan te melden bij de club van onfortuinlijken die de verkeerde device aan een dd if=/dev/zero voeren (guilty ).

[Yzord]

Bedankt voor je antwoord. Ik was even een paar dagen weg, dus kon niet eerder de tijd nemen om te antwoorden.

lsblk gaf inderdaad het antwoord dat de schijf al gebruikt werd door de installatie van RHEL. Die heb ik dus ontkoppeld en RHEL opnieuw geïnstalleerd, zodat ik de 3TB schijf geheel kan gaan gebruiken om hem te mounten op /vtapes/amanda.

Parted ben ik me aan het verdiepen erin