Mount volume on linux

How to mount Linux volume and keep mount point consistency

Customers often use Amazon Elastic Compute Cloud (Amazon EC2) Linux based instances with many Amazon Elastic Block Store (Amazon EBS) volumes attached. In this case, device name can vary depending on some facts, such as virtualization type, instance type, or operating system. As the device name can change, the customer shouldn’t rely on the device name to mount volumes from it. The customer wants to avoid the situation where a volume is mounted on a different mount point just because the device name changed, or the device name doesn’t exist because the name pattern changed.

Customers who want to utilize the latest instance family usually change the instance type when a new one is available. The device name can be different between instance families, such as T2 and T3. T2 uses /dev/sd[a-z] , while T3 uses /dev/nvme6n1 . If you mount a device on T2 called /dev/sdc , when you change the instance family to T3 the same device won’t be called /dev/sdc anymore. In this case, it will fail to mount.

Amazon EBS volumes are exposed as NVMe block devices on instances built on the AWS Nitro System. The block device driver can assign NVMe device names in a different order than what you specified for the volumes in the block device mapping. In this situation, a device that should be mounted on /data could end-up being mounted on /logs .

On Linux, you can use the fstab file to mount devices using kernel name descriptors (the traditional way), file system labels, or the file system UUID. Kernel name descriptors aren’t persistent and can change each boot. Therefore, they shouldn’t be used in configuration files.

UUID is a mechanism for giving each filesystem a unique identifier. These identifiers’ attributes are generated by filesystem utilities (mkfs.*) when the device is formatted, and they’re designed so that collisions are unlikely. All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID.

As UUID is a filesystem attribute, it can also be used with Logical Volume Manager (LVM) and Linux software RAID (mdadm).

Depending on the fstab file configuration, you may find that you can’t access your instance, which requires you to follow a rescue process to fix issues. This is the case if you configure the fstab file with the device name and change the instance type.

This post shows how to mount Linux volumes and keep mount points preserved when the instance type is changed or the instance is rebooted.

Overview of solution

When you create an instance, you specify block devices mapping. It doesn’t mean that the Linux device has the same name or can be discovered in the same order as specified on the instance mapping. This situation can be more evident when using applications that require more volumes.

Using UUID to mount volumes lets you mitigate future issues when you stop and start your instance or change the instance type.

Figure 1: EC2 instance block device mapping

Walkthrough

You will create one instance with three volumes: one root volume and two data volumes. We use Amazon Linux 2 in this post. In this instance type, volumes have a specific name format. Later, you will change the instance type. The new instance type volumes will have another name format.

• Create an instance with three volumes
• Create the filesystem on the volumes and mount them
• Change the instance type

Prerequisites

For this walkthrough, you should have the following prerequisites:

Create instance

Create one instance with three volumes: a root volume and two data volumes. Use Launch Instance Wizard with the following details.

Launch Amazon Linux 2 instance

1. On Step 1, choose Amazon Linux 2 AMI (HVM), SSD Volume Type.
2. On Step 2, choose micro.
3. On Step 3, choose Next.
4. On Step 4, add two new volumes, device /dev/sdb 10 GiB and device /dev/sdc 12 GiB.

Figure 2: Launch instances, add storage

Create filesystem and mount

Connect to your instance using EC2 Instance Connect or any other method that feels comfortable for you. Mount the device using UUID instead of the device name. Run the following instructions as the user root.

Format and mount the device

mkfs.xfs /dev/xvdb mkfs.xfs /dev/xvdc

mkdir /mnt/disk1 mkdir /mnt/disk2

echo "$(blkid -o export /dev/xvdb | grep ^UUID=) /mnt/disk1 xfs defaults,noatime" | tee -a /etc/fstab echo "$(blkid -o export /dev/xvdc | grep ^UUID=) /mnt/disk2 xfs defaults,noatime" | tee -a /etc/fstab

mount -a touch /mnt/disk1/file1.txt touch /mnt/disk2/file2.txt

You will have an fstab file like the following:

cat /etc/fstab UUID=7b355c6b-f82b-4810-94b9-4f3af651f629 / xfs defaults,noatime 1 1 UUID="2c160dd6-586c-4258-84bb-c79933b9ae02" /mnt/disk1 xfs defaults,noatime UUID="3e7a0c28-7cf1-40dc-82a1-2f5cfb53f9a4" /mnt/disk2 xfs defaults,noatime 

Change instance type

Change the instance type from t2.micro to t3.micro.

Launch Amazon Linux 2 instance

1. Stop instance.
2. Change the instance type to micro.
3. Start instance.
4. Connect to your instance using EC2 Instance Connect.
5. Check the device name, and run the following command:

Note that the device names are changed from xvd* to nvme* . All of the devices are mounted without any issue and with the correct mount points.

Cleaning up

To avoid incurring future charges, delete the instance and all of the volumes that you created in this post.

The other side

UUID is an attribute of the filesystem that was generated when you formatted your device. Therefore, it will follow your device even if you create an AMI or snapshot. So you don’t need to worry about a restore process, and it will smoothly proceed to an instance restore. You must be careful if you restore a snapshot from one volume and attach it to the same instance, as you will end-up with two volumes that are using the same UUID. If you try to mount the restored volume on the same instance, then it will fail and you will find this message on /var/log/messages file. kernel: XFS (xvdf1): Filesystem has duplicate UUID f6646b81-f2a6-46ca-9f3d-c746cf015379 — can’t mount It is even more important to be careful if you attach a volume created from the snapshot of the root volume and restart your instance. Since both volumes have the same UUID, you may find that a volume other than the one attached to /dev/xvda or /dev/sda has become the root volume of your instance. See the following example for details. Note that both volumes have the same UUID, but the one mounted on / is /dev/xvdf1, not /dev/xvda1, which is the real root volume for this instance.

$ blkid /dev/xvda1: LABEL="/" UUID="f6646b81-f2a6-46ca-9f3d-c746cf015379" TYPE="xfs" PARTLABEL="Linux" PARTUUID="79fae994-3708-4293-bb29-4d069d1c786b" /dev/xvdf1: LABEL="/" UUID="f6646b81-f2a6-46ca-9f3d-c746cf015379" TYPE="xfs" PARTLABEL="Linux" PARTUUID="79fae994-3708-4293-bb29-4d069d1c786b" 

$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part xvdf 202:80 0 8G 0 disk └─xvdf1 202:81 0 8G 0 part /

Conclusion

In this post, we covered how to use UUID to mount Linux devices using fstab file. This keeps the mount point on the correct device. It also lets you change the instance type without changes to the fstab file. You can use UUID with LVM and Linux software RAID (mdadm), UUID, as an attribute of the filesystem, will be the same even after a backup and restore process, snapshot, or clone. To learn more, check out our block device mappings and device names on Linux instances documentation.

Источник

How to mount an LVM volume?

I’m trying to mount an LVM2 volume in Linux, but all the instructions I see online say to mount the Volume Group, such as:

mkdir -p /mnt/VolGroup00/LogVol00 

but I don’t know how to figure out the name of it. I see the drive in Palimpsest, and that’s all the info I know.

I am surprised that no one mentioned about findmnt command. You can just do a findmnt -l and you’ll get what you want. And for a better version Try this : findmnt -l | grep ‘ /dev/\S\+’

Sadly does not see any solution for the mount of an LVM volume from a dd/raw image in the answers. Would be great to see if some of the solutions are also working for this use case.

7 Answers 7

Here are the steps I used to accessing a LVM from Fedora 17, it should work with most forms of Linux.

Make sure lvm2 is installed:

Load the necessary module(s) as root:

Scan your system for LVM volumes and identify in the output the volume group name that has your Fedora volume (mine proved to be VolGroup00):

$ sudo vgchange -ay VolGroup00 

Find the logical volume that has your Fedora root filesystem (mine proved to be LogVol00):

Create a mount point for that volume:

$ sudo mount /dev/VolGroup00/LogVol00 /mnt/fcroot -o ro,user 

You’re done, navigate to /mnt/fcroot and copy the files and paste somewhere else.

Note: In case of bad sectors on the disk, one can prevent journaling with the option noload .

Working through this was easy to follow and worked for me in ubuntu (exchanging yum for apt-get of course). Activation in particular, not covered by other answers, was important. This is the way to go if you have an old drive with LVM and attach it to another working system.

In RedHat 7, I first had to run pvscan —cache. Without that, vgscan would not even see the new volume group.

Don’t forget to create a file system on the LV before mounting if there is none. mkfs -t ext4 /dev/VolGroup00/LogVol00 Otherwise the mount: wrong fs type, bad option, bad superblock error message will appear.

Faced this problem a while ago, I’d posted this on my blog

List out all your partitions, type

You will get a list of something like this

File descriptor 3 left open File descriptor 4 left open /dev/dm-0 [ 9.67 GB] /dev/sda1 [ 78.41 MB] /dev/dm-1 [ 6.44 GB] /dev/sda2 [ 115.52 GB] /dev/dm-2 [ 2.00 GB] /dev/sda3 [ 18.11 GB] LVM physical volume /dev/sda5 [ 15.33 GB] 

Make a note of /dev/dm-x , those are the devices which correspond to the LVM partitions. Also do note the sizes.

Next, type lvdisplay to show a detailed list of all the logical volumes available.

LV Name /dev/system/home VG Name system LV UUID 1QP9XM-vlKi-umNO-CXvV-TnZN-RCLk-e1FDIr LV Write Access read/write LV Status available # open 1 LV Size 9.67 GB Current LE 2475 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 — Logical volume — LV Name /dev/system/root VG Name system LV UUID D1fKUJ-uU1C-jlVB-4imh-rrgy-FQu0-TC2Ssm LV Write Access read/write LV Status available # open 1 LV Size 6.44 GB Current LE 1649 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 — Logical volume — LV Name /dev/system/swap VG Name system LV UUID w5LqIb-xvcr-Xsbk-y3wg-lT3i-LqdN-GFK8Mi LV Write Access read/write LV Status available # open 0 LV Size 2.00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2 

Now from the above set of data, we can deduce that my /home partition, of size 9.67 GB is available as LV group /dev/system/home on /dev/dm-0

Now that we know where the partition is available, we can proceed with the mounting using the mount command, as

And there you go, your LV partition is mounted!

Источник