7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 1/22

 

Thoughts and Scribbles 

Random assortment of all things microcomputers, development and systems

   NIX Posts o o o o o o o o o 

  Windows o o o o 

  Forum   Contact   About   Image Gallery 

o o 

  Ol’Java Site 

« Red Hat Linux Fedora: Fedora 13 to Fedora 14(64) upgrade. Linux LVM: Resizing partitions. »

Linux LVM: Recovering a lost volume. 

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 2/22

It may become necessary to recover or rebuild an LVM in case either a backup/etc/lvm/backup/<VOLGROUP> is not available or becomes lost or other conditions arisecausing loss of system volume data. What might otherwise appear destroyed, deleted or inaccessible, LVM comes with a few backup options in case of disaster. Here are the recoverysteps I took to recover previously lost data without either a backup and using only a few open

source tools:

NOTE: Do not attempt these steps unless you have a firm understanding of UNIX /

LINUX. The concepts here are relatively advanced. Also ensure you have a backup of the

data that will be affected by your actions below. Also take note that your mileage may vary

and that this may or may not necessarily work for you. Use with caution.

Before we proceed any further, the LVM version used here is:

LVM version: 2.02.83(2)-RHEL6 (2011-03-18)Library version: 1.02.62-RHEL6 (2011-03-18)Driver version: 4.20.6

If your version differs, the below steps may not work for you.

The first step to take is to grab the start sectors of the partitions that used to hold your LVM. TheLinux LVM holds the equivalent of /etc/lvm/backup/<VOLGROUP> just in case of loss toallow for recovery later, as we will be doing here. To do this, invoke dd and grab 255, 512 byte

sectors from the start of, in this case, /dev/sda2:

# dd if=/dev/sda2 bs=512 count=255 skip=1 of=./sda2.lvm 

This will create a binary file that I found only best to use a hex editor to view with. I usedOkteta to get a look at the file in HEX notation, simply because it was installed on mysecondary system at the time. I used it to identify start and end of blocks I need to get the correct block from the file. The start and end sectors of a block begin with the 0 ASCII character:00. Here is how the file looked like in Okteta, showing start and end markers for the LVM PV's,VG's, and LV's definition block:

Okteta Linux LVM – START of LVM Definition. 

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 3/22

 

Okteta Linux LVM – END of LVM Definition. 

Okteta Linux LVM – END of LVM Definition (alternate example). 

Please note the end point actually marked by the green in the second image, NOT the red. Theyare marked on a 00 byte boundary. I did not find the START and END as easily descernable inVI. I expect Okteta, or any other HEX editor for that matter, to better indicate the starting and

ending points. Your mileage may vary. The recovered file looked like this (sda2-lvm-final.lvm):

VolGroup {id = "l6D50I-m8tf-2iPJ-ef1R-O9kf-kH2v-7SslkB"seqno = 51status = ["RESIZEABLE", "READ", "WRITE"]flags = []

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 4/22

extent_size = 8192max_lv = 0max_pv = 0metadata_copies = 0

 physical_volumes {

 pv0 {id = "AR2cbu-Zlxw-8nR0-423o-20pa-3g3l-Te3gcI"device = "/dev/sda2"

status = ["ALLOCATABLE"]flags = []dev_size = 392161281 pe_start = 384 pe_count = 47871

}

 pv1 {id = "1tycCU-hDC0-USvN-fuS8-gdgd-QIHq-UHcb0Y"device = "/dev/sda3"

status = ["ALLOCATABLE"]flags = []dev_size = 392161281 pe_start = 2048 pe_count = 47871

}}

logical_volumes {

lv_root {id = "b3XsIw-JC3l-cIEU-njSP-1NbY-kPaO-gvMJda"status = ["READ", "WRITE", "VISIBLE"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 8192

type = "striped"stripe_count = 1 # linear 

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 5/22

stripes = ["pv1", 0]}

}

lv_swap {

id = "KBdB2L-j1ZS-8iA6-Uilh-43G1-NKxX-eE06FW"status = ["READ", "WRITE", "VISIBLE"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 1024

type = "striped"stripe_count = 1 # linear 

stripes = ["pv1", 8192]}

}

LogVol02 {id = "beOzB5-znIO-SD44-bkgr-aT9F-gb6N-9Ayyia"status = ["READ", "WRITE", "VISIBLE"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 38655

type = "striped"stripe_count = 1 # linear 

stripes = ["pv1", 9216]}

}}

}# Generated by LVM2 version 2.02.83(2)-RHEL6 (2011-03-18): Sun Sep 11 05:51:56 2011

contents = "Text Format Volume Group"version = 1

description = ""

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 6/22

creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-131.0.15.el6.x86_64 #1 SMP Sat May 21 10:27:57 CDT 2011 x86_64creation_time = 1315720316 # Sun Sep 11 05:51:56 2011

After trying to apply the restored VolGroup sda2-lvm-final.lvm file, received the message:

# lvm vgcfgrestore -f sda2-lvm-final.lvm VolGroup Couldn't find device with uuid AR2cbu-Zlxw-8nR0-423o-3g3l-Te3gcI.Couldn't find device with uuid 1tycCu-hDC0-USvN-fuS8-gdgd-QIHq-UHcb0Y.Cannot restore Volume Group VolGroup with 2 PVs marked as missing.Restore failed.

# 

This is because in order to restore, the vgcfgrestore commands needs to see the same PV's(including matching UUID's) on the system as existed before. At this point, I haven't createdthem yet.

We'll need to PV create on /dev/sda2 and /dev/sda3 as per the VolGroup recovered file aboveand assign the same UUID's as in our restore file. (The alternate might be to change theVolGroup recovery backup file and assign the new PV UUID's to the VolGroup restore file before applying. We will not try that here however so I cannot vouch for the success of thismethod.)

Before we can restore the VolGroup, we need to do so to PV's with the same UUID's. For thiswe create teh PV's first:

# lvm pvcreate -u $(cat sda2-lvm-final.lvm |grep 1tycCU|awk '{ gsub(/"/, "", $0) } {

print $3 }') /dev/sda3 – restorefile sda2-lvm-final.lvm# lvm pvcreate -u $(cat sda2-lvm-final.lvm |grep AR2cbu|awk '{ gsub(/"/, "", $0) } {

print $3 }') /dev/sda2 – restorefile sda2-lvm-final.lvm

Followed by:

# lvm vgcfgrestore -f sda2-lvm-final.lvm VolGroup Restored volume group VolGroup

# 

Unfortunately, in my case, this didn't work. I can't say I didn't expect that entirely because I had

earlier done lvm pvmove from /dev/sda2 to /dev/sda3. Next I tried the same thing but this timeattempting to recover the volume from /dev/sda3. This one I had less hope of recovering because I had previously unsuccessfully tried to recreate the LVM structure on /dev/sda3 that Ithought I had lost. Unfortunately unknown to me at the time, I did NOT know about this type of recovery process. But I degress and now on to the show.

Below is the derived VolGroup definition I could derive from my former installation from the beginning of the partition using the means already explained above:

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 7/22

VolGroup {id = "l6D50I-m8tf-2iPJ-ef1R-O9kf-kH2v-7SslkB"seqno = 5status = ["RESIZEABLE", "READ", "WRITE"]flags = []

extent_size = 8192max_lv = 0max_pv = 0metadata_copies = 0

 physical_volumes {

 pv0 {id = "x0O0xW-TAXH-Vrz2-g299-pJm6-Mj5g-srkOBH"device = "/dev/sda3"

status = ["ALLOCATABLE"]flags = []dev_size = 392161281 pe_start = 2048 pe_count = 47871

}}

logical_volumes {

lv_root {

id = "b3XsIw-JC3l-cIEU-njSP-1NbY-kPaO-gvMJda"status = ["READ", "WRITE", "VISIBLE"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 8192

type = "striped"stripe_count = 1 # linear 

stripes = ["pv0", 0]}

}

lv_swap {id = "KBdB2L-j1ZS-8iA6-Uilh-43G1-NKxX-eE06FW"status = ["READ", "WRITE", "VISIBLE"]

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 8/22

flags = []segment_count = 1

segment1 {start_extent = 0

extent_count = 1024

type = "striped"stripe_count = 1 # linear 

stripes = ["pv0", 8192]}

}

LogVol02 {id = "beOzB5-znIO-SD44-bkgr-aT9F-gb6N-9Ayyia"

status = ["READ", "WRITE", "VISIBLE"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 38655

type = "striped"stripe_count = 1 # linear 

stripes = ["pv0", 9216]}}

}}# Generated by LVM2 version 2.02.83(2)-RHEL6 (2011-03-18): Mon Sep 12 05:04:15 2011

contents = "Text Format Volume Group"version = 1

description = ""

creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-131.0.15.el6.x86_64 #1 SMP Sat May 21 10:27:57 CDT 2011 x86_64creation_time = 1315803855 # Mon Sep 12 05:04:15 2011

Again we mimick the steps taken above to try and recover the lost LVM:

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 9/22

1.  lvm pvcreate -u $(cat sda3-lvm-final-3.lvm |awk '{ if ( $0 ~ /x0O0xW/ ) { gsub(/"/,"",$3); print $3 } }') /dev/sda3 – restorefile sda3-lvm-final-3.lvm

2.  lvm vgcfgrestore -f sda3-lvm-final-3.lvm VolGroup3.  lvm vgscan4.  lvm pvscan

5. 

lvm vgchange VolGroup -a y6.  lvm pvs7.  lvm vgs8.  lvm lvs

The last three commands being the verification. All showed LV's, PV's and VG's listead. Nowto mount the volumes to test. Unfortunately:

# mount /dev/VolGroup/lv_root /mnt/mr

mount: you must specify the filesystem type 

# 

Adding the -vvvvv to the above command reveals that the mounter couldn't see an OS type fromthe head of the volume it appears:

mount: types: "(null)"mount: opts: "(null)"

At this point it looked like I was really in trouble. So I decided to see where my data was reallylocated. For this I used dd:

# dd if=/dev/sda2 bs=512 count=100000 skip=1 of=./sda2.dd.lvm

# dd if=/dev/sda3 bs=512 count=100000 skip=1 of=./sda3.dd.lvm 

Then scp'd the files to my server and analyzed them using:

# strings sda2.dd.lvm | more

# strings sda3.dd.lvm | more 

This quickly revealed where the problem looked to be. I could see my file names off the old partition on sda2 but NOT on sda3. I had remembered what I did that lead to my predicamentwhich was:

# pvcreate /dev/sda3# vgextend VolGroup /dev/sda3

# pvmove /dev/sda2 /dev/sda3

# vgreduce VolGroup

# pvremove /dev/sda2 

There is also free space between /dev/sda2 and /dev/sda3, about 1TB o f free space if notmore. I had hoped the pvmove will move everything between partitions as advertised but

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 10/22

unfortunately, it did not. But at least now I could confirm that my data was stillon /dev/sda2 and nothing was on /dev/sda3. So I had to work with any remaining LVM configsoff of /dev/sda2 if I have any hope of recovering my data. So I edited the smaller dd outputearlier for sda2 and recreated any and all available definitions I could find and startedreimplementing from the earliest moving backwards:

And this time, mount worked on /dev/VolGroup/LogVol02 and I could see my files:

# mount /dev/VolGroup/LogVol02 /mnt/mr

# du -sh /mnt/mr

119G /mnt/mr

# 

But I wanted /dev/VolGroup/lv_root to be visible. So off I go to the next available definition,inspired by my success above and try that. This time I used the third last one:

VolGroup {id = "l6D50I-m8tf-2iPJ-ef1R-O9kf-kH2v-7SslkB"seqno = 47status = ["RESIZEABLE", "READ", "WRITE"]flags = []extent_size = 8192max_lv = 0max_pv = 0metadata_copies = 0

 physical_volumes {

 pv0 {id = "AR2cbu-Zlxw-8nR0-423o-20pa-3g3l-Te3gcI"device = "/dev/sda2"

status = ["ALLOCATABLE"]flags = []dev_size = 392161281 pe_start = 384 pe_count = 47871

}

 pv1 {id = "1tycCU-hDC0-USvN-fuS8-gdgd-QIHq-UHcb0Y"device = "/dev/sda3"

status = ["ALLOCATABLE"]flags = []dev_size = 392161281

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 11/22

pe_start = 2048 pe_count = 47871

}}

logical_volumes {

lv_root {id = "b3XsIw-JC3l-cIEU-njSP-1NbY-kPaO-gvMJda"status = ["READ", "WRITE", "VISIBLE", "LOCKED"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 8192

type = "striped"stripe_count = 1 # linear 

stripes = ["pvmove0", 0]}

}

lv_swap {id = "KBdB2L-j1ZS-8iA6-Uilh-43G1-NKxX-eE06FW"status = ["READ", "WRITE", "VISIBLE", "LOCKED"]

flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 1024

type = "striped"stripe_count = 1 # linear 

stripes = ["pvmove0", 8192]

}}

LogVol02 {id = "beOzB5-znIO-SD44-bkgr-aT9F-gb6N-9Ayyia"status = ["READ", "WRITE", "VISIBLE", "LOCKED"]flags = []segment_count = 1

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 12/22

segment1 {start_extent = 0extent_count = 38655

type = "striped"

stripe_count = 1 # linear 

stripes = ["pvmove0", 9216]}

}

 pvmove0 {id = "2D2d4C-tTFL-IJLu-CDX8-Ud6l-juav-7Xh9on"status = ["READ", "WRITE", "PVMOVE", "LOCKED"]flags = []allocation_policy = "contiguous"

segment_count = 3

segment1 {start_extent = 0extent_count = 8192

type = "mirror"mirror_count = 2extents_moved = 0

mirrors = ["pv0", 0,"pv1", 0]

}segment2 {start_extent = 8192extent_count = 1024

type = "mirror"mirror_count = 2extents_moved = 0

mirrors = ["pv0", 8192,"pv1", 8192]}

segment3 {start_extent = 9216extent_count = 38655

type = "mirror"mirror_count = 2extents_moved = 0

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 13/22

mirrors = ["pv0", 9216,"pv1", 9216]}

}}

}

# Generated by LVM2 version 2.02.83(2)-RHEL6 (2011-03-18): Sun Sep 11 02:55:09 2011

contents = "Text Format Volume Group"version = 1

description = ""

creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-131.0.15.el6.x86_64 #1 SMP Sat May 21 10:27:57 CDT 2011 x86_64creation_time = 1315709709 # Sun Sep 11 02:55:09 2011

This time, I could see and mount all my partitions again:

# mount /dev/VolGroup/LogVol02 /mnt/mr

# mount /dev/VolGroup/lv_root /mnt/lv_root

# du -sh /mnt/mr

119G /mnt/mr

# du -sh /mnt/lv_root

13G /mnt/lv_root

# 

And this is why I got my partitions back and working on /dev/sda2. I did notice one thing

however. As soon as I restored the above definition the hard drive light on the disk of the targetserver stayed on as if it was copying something. Looking I noticed kblockd using some CPUwhile the hard drive light was on. So I checked what is doing disk I/O using this command:

# for ikh in $(ls /proc/*/io); do echo "[$ikh]: "$(cat $ikh 2>/dev/null)|awk '{ if ( $0 ~ 

/rchar/ && $3 != 0 ) print $1" "$3; }'; done 

Which, when ran twice, reveals which processes show a delta on Disk I/O:

[/proc/1/io]: 388814[/proc/1000/io]: 24292

[/proc/1004/io]: 673413398[/proc/12569/io]: 49573[/proc/12583/io]: 30445[/proc/12592/io]: 170451[/proc/67/io]: 107712397[/proc/773/io]: 7780[/proc/774/io]: 261734[/proc/775/io]: 2412006

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 14/22

[/proc/776/io]: 26700[/proc/778/io]: 1777975[/proc/78/io]: 115248[/proc/794/io]: 440762[/proc/807/io]: 16012

[/proc/836/io]: 7767303[/proc/84/io]: 58436892[/proc/93/io]: 4478177[/proc/self/io]: 1956

Checking processes, this quickly revealed the processes:

root 1004 0.0 0.0 108524 2120 tty1 S Sep17 0:08 bashroot 23238 0.0 0.0 20204 1252 ? S 02:32 0:00 hald-addon-input: Listening on/dev/input/event3

With 1004 belonging to my current shell. So the only thing that I could deduce, that when Irestored the LVM config, the pvmove defined in it, retriggered an lvm pvmove /dev/sda2

/dev/sda3 again. I will let this one finish but I won't vgreduce anymore once it's done, butinstead check with dd exactly where it moved things before I reduce and shrink my partition.

Having let the activity run for a while, I noted that even when it was done, I still could not reducethe VolGroup by /dev/sda3 at all:

# lvm vgreduce VolGroup /dev/sda3 Physical volume /dev/sda3 is still in use.

So I decided to tweak the last VolGroup definition by removing the move blocks or amendingthem like this by editing everything in red out (Now this should work since we verified abovethat /dev/sda3 has NO data):

VolGroup {id = "l6D50I-m8tf-2iPJ-ef1R-O9kf-kH2v-7SslkB"seqno = 47status = ["RESIZEABLE", "READ", "WRITE"]flags = []extent_size = 8192max_lv = 0max_pv = 0metadata_copies = 0

 physical_volumes {

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 15/22

pv0 {id = "AR2cbu-Zlxw-8nR0-423o-20pa-3g3l-Te3gcI"device = "/dev/sda2"

status = ["ALLOCATABLE"]

flags = []dev_size = 392161281 pe_start = 384 pe_count = 47871

}

 pv1 {id = "1tycCU-hDC0-USvN-fuS8-gdgd-QIHq-UHcb0Y"device = "/dev/sda3"

status = ["ALLOCATABLE"]

flags = []dev_size = 392161281 pe_start = 2048 pe_count = 47871

}}

logical_volumes {

lv_root {id = "b3XsIw-JC3l-cIEU-njSP-1NbY-kPaO-gvMJda"

status = ["READ", "WRITE", "VISIBLE", "LOCKED"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 8192

type = "striped"stripe_count = 1 # linear 

stripes = ["pvmove0", 0]}}

lv_swap {id = "KBdB2L-j1ZS-8iA6-Uilh-43G1-NKxX-eE06FW"status = ["READ", "WRITE", "VISIBLE", "LOCKED"]

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 16/22

flags = []segment_count = 1

segment1 {start_extent = 0

extent_count = 1024

type = "striped"stripe_count = 1 # linear 

stripes = ["pvmove0", 8192]}

}

LogVol02 {id = "beOzB5-znIO-SD44-bkgr-aT9F-gb6N-9Ayyia"

status = ["READ", "WRITE", "VISIBLE", "LOCKED"]flags = []segment_count = 1

segment1 {start_extent = 0extent_count = 38655

type = "striped"stripe_count = 1 # linear 

stripes = ["pvmove0", 9216]}}

 pvmove0 {id = "2D2d4C-tTFL-IJLu-CDX8-Ud6l-juav-7Xh9on"status = ["READ", "WRITE", "PVMOVE", "LOCKED"]flags = []allocation_policy = "contiguous"segment_count = 3

segment1 {start_extent = 0extent_count = 8192

type = "mirror"mirror_count = 2extents_moved = 0

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 17/22

mirrors = ["pv0", 0,"pv1", 0]}

segment2 {start_extent = 8192

extent_count = 1024

type = "mirror"mirror_count = 2extents_moved = 0

mirrors = ["pv0", 8192,"pv1", 8192]}

segment3 {start_extent = 9216

extent_count = 38655

type = "mirror"mirror_count = 2extents_moved = 0

mirrors = ["pv0", 9216,"pv1", 9216]}

}}

}

# Generated by LVM2 version 2.02.83(2)-RHEL6 (2011-03-18): Sun Sep 11 02:55:092011

contents = "Text Format Volume Group"version = 1

description = ""

creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-131.0.15.el6.x86_64 #1 SMP Sat May 21 10:27:57 CDT 2011 x86_64

creation_time = 1315709709 # Sun Sep 11 02:55:09 2011

Sure enough, when the above edited file was reimplemented with vgcfgrestore, the volume wasmountable and this time showed enough free space on /dev/sda3 by which to reduce it:

PV /dev/sda2 VG VolGroup lvm2 [187.00 GiB / 0 free]PV /dev/sda3 VG VolGroup lvm2 [187.00 GiB / 187.00 GiB free]Total: 2 [373.99 GiB] / in use: 2 [373.99 GiB] / in no VG: 0 [0 ]

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 18/22

And this time vgreduce worked successfully, and I was back on /dev/sda2 about to attempt amirror instead then a vgreduce and pvremove.

MORAL OF THE STORY: Consider using rsync or scp between volumes and define new ones manually before you copy

over. You may get better mileage that way. Also, most importantly, take backup of the LVMconfig before you reboot. If that fails and you still get yourself into such a mess, then at least bookmark this site.

Cheers!TK 

This entry was posted on Monday, September 19th, 2011 at 10:36 pm and is filed under NIX Posts. You can followany responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

One Response to “Linux LVM: Recovering a lost volume.” 

1.  Sergio Guzman on December 29th, 2011 at 7:36 pm

Thanks for your post, it helped me to recover the config file although it wasn’t as difficultas your case.

Leave a Reply

 Name (required) 

Mail (will not be published) (required) 

Website 

Type the two words:

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 19/22

 

   Pages

o  googlesearchresultso  homeimageso  travelimages

  Databaseso  MySQL command reference (5.0)o  MySQL DBo  Sybaseo  Sybase Reference Manual

  Javao  Java Gaming Forumso   java.sun.com

  Languageso   java.sun.como  PERL Knowledge Baseo  Perl Monks Forum

  Linuxo  Linux Forumso  Linux LVM Cheat Sheeto  Linx LVM2 (IBM) Technical Article

  Miscellaneouso  Quotations

  Perlo  PERL Knowledge Baseo  Perl Monks Forum

  Scriptingo  AWK Cheat Sheeto  Effective AWK Programming

  Webo  Web Hosting Chato  Web Hosting Directory

  Tags

4.0 access Apache  bash command configuration configure connection create error  etc eth0 Fedora 

firewall GNOME httpd ifconfig IP KDE KERNEL konsole ksh Linux login messages mount 

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 20/22

MySQL  Network  networking not password problem resolution restart router  RPM secure 

server  share solution unix upgrade Video Windows yum 

  Metao  Register o  Log ino  Entries RSSo  Comments RSSo  WordPress.org

  

February 2013

M T W T F S S

« Jan  

1 2 3

4 5 6 7 8 9 10

11 12 13 14 15 16 17

18 19 20 21 22 23 24

25 26 27 28

  Categorieso  Assorted Nuts (7)o  Hardware (2)o  JADDB (1)o   Network (6)o   NIX Posts (94)o  Perl (5)o  Web (8)o  Windows (11)

  Recent Postso  Fatal error: Unknown: Cannot use output buffering in output buffering display

handlers in Unknown on line 0o  ksh and ksh93: line arithmetic syntax error o  ksh and ksh93: 0: not found [No such file or directory]o  RANDOM numbers in ksh or ksh93o  The current theme does not natively support menuso  Empty pages after installing WP Super Cache and HTML Minifi

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 21/22

o  Er ror 105 (net::ERR_NAME_NOT_RESOLVED): Unable to resolve the server’s

DNS address.o  The pages do not match! Timestamps differ or were not found!o  google results don’t match the search string o  Error client Files Does Not Exist: 404 Not Found Page

  Archiveso  January 2013o  December 2012o   November 2012o  October 2012o  September 2012o  August 2012o  April 2012o  February 2012o  January 2012o  September 2011o  August 2011o  July 2010o  June 2010o  February 2010o  January 2010o  December 2009o  August 2009o  July 2009o  March 2009o  February 2009o  January 2009

o  December 2008o   November 2008o  September 2008o  July 2008o  June 2008o  March 2008o  February 2008o  January 2008o  December 2007o  July 2007o  June 2007

 Site Searc

 

  Recent Commentso  Michael on Linux RPM GPG Key: V3 DSA signature: NOKEY, key ID

db42a60e

7/28/2019 Recover Lost Lvm

http://slidepdf.com/reader/full/recover-lost-lvm 22/22

o  Eric on Device eth0 does not seem to be present, delaying initialization: Linux Networking

o  Surjit on Device eth0 does not seem to be present, delaying initialization: Linux Networking

o  fede on Empty pages after installing WP Super Cache and HTML Minifio 

 Nick on Device eth0 does not seem to be present, delaying initialization: Linux Networkingo  Tom on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Tom on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Ryan on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Tom on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Ryan on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Ryan on Linux: e1000e kernel panic with Intel 82574L kernel panic and ASPMo  Lutful Kabir on Microsoft Word: A delete key that doesn’t delete. o  David D on HTPC / Backup Home Server Solution using Linuxo  Cannot access windows share on Networking: Sharing folders between Windows

and Linux using Sambao  Tom on Device eth0 does not seem to be present, delaying initialization: Linux

 Networking

Copyright © 2003 - 2012 TomKacperski. All rights reserved.

Privacy / Use / Terms /Disclaimer Policy. 

Copyright © Thoughts and Scribbles - Powered by WordPressProSense theme created by Dosh Dosh and The Wrong Advices.