Recover Lost Lvm
Transcript of Recover Lost Lvm
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.