“mount: unknown filesystem type ‘LVM2_member'”…
That’s the error message that eventually allowed me to find the solution.
As I mentioned previously (twice already), when you rent a cloud server at 1and1, and you install Linux on it (well, at least Ubuntu), you obtain a weird partitioning scheme. Such as:
# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 3.7G 1.2G 2.6G 31% / none 490M 140K 490M 1% /dev none 500M 8.0K 500M 1% /dev/shm none 500M 0 500M 0% /tmp none 500M 60K 500M 1% /var/run none 500M 0 500M 0% /var/lock none 500M 0 500M 0% /lib/init/rw /dev/mapper/vg00-usr 4.0G 441M 3.6G 11% /usr /dev/mapper/vg00-var 4.0G 215M 3.8G 6% /var /dev/mapper/vg00-home 4.0G 4.3M 4.0G 1% /home
So, in total much less than the 100 GB you get in the smallest case. I tried to follow their (tiny) FAQ on the subject, but seriously this wasn’t worth going farther than:
# fdisk -l Disk /dev/xvda: 100.0 GB, 100000595968 bytes 255 heads, 63 sectors/track, 12157 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/xvda1 1 487 3911796 83 Linux /dev/xvda2 488 731 1959930 82 Linux swap / Solaris /dev/xvda3 732 12157 91779345 8e Linux LVM
(I’ll be trying to provide full output as I guess that’s what’s most helpful if you’re struggling to do just what I wanted to do, i.e. just get the GBs you paid for)
I just tried to mount that big /dev/xvda3 thing, but it failed:
# cd mnt # ls # mkdir part1 # mount /dev/xvda3 /mnt/part1 mount: unknown filesystem type 'LVM2_member'
But this error was not in vain, for searching for it brought me the solution: that thing is an LVM volume, and there’s a particular way to deal with it.
First you can (should!) check out your LVM volumes *and groups*:
# pvs PV VG Fmt Attr PSize PFree /dev/xvda3 vg00 lvm2 a- 87.52g 75.52g
Here it’s simple, we have one volume, /dev/xvda3, which contains one group, vg00, which has a size of 87.52GiB (among which 75.52GiB unassigned aka free). Looks familiar? You bet, remember earlier:
/dev/mapper/vg00-usr 4.0G 441M 3.6G 11% /usr /dev/mapper/vg00-var 4.0G 215M 3.8G 6% /var /dev/mapper/vg00-home 4.0G 4.3M 4.0G 1% /home
Now you’ll want to check out what’s inside that group:
# lvdisplay /dev/vg00 --- Logical volume --- LV Name /dev/vg00/usr VG Name vg00 LV UUID ElBhAu-r2PF-g1sV-UICK-T7Ao-TZmC-uKv0sj LV Write Access read/write LV Status available # open 1 LV Size 4.00 GiB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 251:0 --- Logical volume --- LV Name /dev/vg00/var VG Name vg00 LV UUID gz0jhl-7uzG-1wqj-b1Ok-Mqjk-rWlC-ZHBBhy LV Write Access read/write LV Status available # open 1 LV Size 4.00 GiB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 251:1 --- Logical volume --- LV Name /dev/vg00/home VG Name vg00 LV UUID 2C9KvC-Dcmx-4C6N-T7cg-NzAr-WVOi-KS2xc1 LV Write Access read/write LV Status available # open 1 LV Size 4.00 GiB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 251:2
It’s like the jackpot, because from all the posts I read about LVM (see sources at the end), it seems that the hard part with those LVM volumes is to mount them. Here (on that 1and1 cloud server) we’re totally in luck: they’re already mounted! We just need to find out how to resize them, and this looks fairly easy: lvextend and lvreduce… Now, before going further, I’d like to warn you about something: extending is most likely totally harmless (and super-fast), reducing is probably more risky, or at least more tedious (you need to unmount the logical volume to do it “safely”, and I’m not sure how safe this is).
So the winning strategy, in my opinion, is maybe to try extending an LVM with 1GiB just to see if it works fine, and then wait until you have a better idea of which volume needs space before extending them again (maybe also wait till that volume gets low on free space – but don’t wait too much, it would be stupid to lose data because of lack of assigned space while there’s so much free ^^). Avoid extending the volumes alternatively and regularly to avoid fragmenting them. Avoid assigning too much too fast to avoid having to reduce a volume later (you’ll see below how scary it sounds when you try it ;)).
So, here are the 2 commands and their outputs:
# lvextend -L+1G /dev/vg00/home Extending logical volume home to 5.00 GiB Logical volume home successfully resized
# lvreduce -L-1G /dev/vg00/home WARNING: Reducing active and open logical volume to 4.00 GiB THIS MAY DESTROY YOUR DATA (filesystem etc.) Do you really want to reduce home? [y/n]: n Logical volume home NOT reduced Command failed with status code 5.
(yeah, I aborted that one ^^)
Now that you’ve extended the volume, you’ll have to extend the filesystem first. Something you should know before going on if you’re doing this on 1and1 like me: their cloud servers use XFS, and you can’t shrink an XFS file system so once you’ve expanded it there’s no easy way back. Here we go, for instance for /home (the LVM volume needs to be mounted):
# xfs_growfs /home meta-data=/dev/mapper/vg00-home isize=256 agcount=8, agsize=131072 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1048576, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=65536 blocks=0, rtextents=0 data blocks changed from 1048576 to 1310720
One last thing: let’s check how the free space lost the GiB we assigned:
# pvs PV VG Fmt Attr PSize PFree /dev/xvda3 vg00 lvm2 a- 87.52g 74.52g
And… back to the beginning:
# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 3.7G 1.1G 2.7G 30% / none 490M 140K 490M 1% /dev none 500M 0 500M 0% /dev/shm none 500M 0 500M 0% /tmp none 500M 60K 500M 1% /var/run none 500M 0 500M 0% /var/lock none 500M 0 500M 0% /lib/init/rw /dev/mapper/vg00-usr 4.0G 441M 3.6G 11% /usr /dev/mapper/vg00-var 4.0G 216M 3.8G 6% /var /dev/mapper/vg00-home 5.0G 4.4M 5.0G 1% /home
Success! 🙂
Sources (I didn’t really use all of them, but they might be useful to dig deeper – I tried to put the most relevant ones at the top):
- LinuxQuestions – mount: unknown filesystem type ‘LVM2_member’
- Mounting a Linux LVM volume
- LVM How-to: Reducing a logical volume
- LVM How-to: Extending a logical volume
- Resizing an LVM partition, True Blade Systems, Inc.
- Accessing a Fedora Logical Volume from Ubuntu
- PissedOffAdmins – mount: unknown filesystem type ‘LVM2_member’
- How to mount LVM volumes, help!
- LVM and RAID
Update (15 Jan 2011): checking the queries bringing people here and reproducing them in Google, I was able to find a FAQ in the UK FAQ just about that… I really wonder why the heck the 1&1 FAQ is so totally different from one country to another! Anyway, here’s the link: 1&1 Webhosting FAQ | How can I increase a logical volume?
Thanks a lot for this nice tutorial. Was exactly what I needed!
Just got a 1and1 dedicated server today. All I can say to you is Thank You, Thank You, Thank You!
Are you saying that there is the same issue even on their dedicated servers? (not cloud/VPS, but dedicated?)
Yep, same issue:
Wow… I would have thought you’d have the choice of a custom partitioning during installation… On the cloud I can understand because of the possibility to extend or reduce the available hard drive, but on a dedicated server that doesn’t seem to make sense…
I agree. I’ve had dedicated servers at several places (the majority at Softlayer) and I’ve never seen such a poor system.
Very usefull post, it’s exactly what I was looking for, extremely tough to find good information on this Dynamic Cloud Server resizing … Was a pity to have 100GB, with no possibility to use it …
Thks a lot
You’re welcome. Hi from Paris, btw 🙂
David, Can I pay you do to this for my 1and1 cloud server? I need to increase tmp partition to atleast 2GB
I would if I could, but as far as I know the only folders you can resize this way are /usr, /var and /home. For some reason, /tmp as well as a few others aren’t part of the LVM volume, as you can see from df -h, and thus can’t be resized, as far as I know…
What I could do, if you know you to configure your application to use a different temporary folder, is create another partition on the LVM volume so that you can use it as a temporary partition. But I’d prefer not to do it on a prod server, though, I’m not too confident when dealing with those things: I don’t really do this often.
thanks !!! great job !!