On 01/20/2014 11:13 AM, Andrey Borzenkov wrote:

PV label is located withing first 4K on device (whole disk or partition), usually second sector. OUCH If partition table was corrupted, PV will not be found. You could search the whole disk for PV label header LABELONE. Is that a literal string?

What about the LVM partitions? I was under the impression that they each had their own LV information somewhere - that was what lvscan looked for - and this would be enough information to 'recover' the LV/partition. -- An ounce of action is worth a ton of theory. -- Friedrich Engels -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

...

I was under the impression that they each had their own LV information somewhere - that was what lvscan looked for - and this would be enough information to 'recover' the LV/partition.

LVM tools work with PV. If there is no PV, nothing will be found. Does pvscan output anything?

lvm usually keeps backup info in /etc/lvm/backup and /etc/lvm/archive (depending on the configuration) If you google lvm backup, you'll find stuff like this: http://www.tldp.org/HOWTO/LVM-HOWTO/recovermetadata.html But make sure you have the problem correctly diagnosed before attempting a repair. Or dd the whole disk somewhere safe first. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 01/20/2014 11:45 AM, Dave Howorth wrote:

...

lvm usually keeps backup info in /etc/lvm/backup and /etc/lvm/archive (depending on the configuration)

If I could read that much of the disk I'd be well ahead!

Yeah, is why I always keep the root and boot as non-RAID, non-LVM :( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/20/14 18:20, Dave Howorth wrote:

Anton Aylward wrote:

...

On 01/20/2014 11:45 AM, Dave Howorth wrote:

...

lvm usually keeps backup info in /etc/lvm/backup and /etc/lvm/archive (depending on the configuration)

If I could read that much of the disk I'd be well ahead!

Yeah, is why I always keep the root and boot as non-RAID, non-LVM :(

I understand why you don't want to use LVM for them. I don't understand why you do not want to use RAID. Using (Software) RAID-1 on all my disks was several times the reason that I could continue my work and prepare for disk exchange at leisure, instead of stumbling into re-imaging new disks and missing project dates. I couldn't imagine to live without it. Disks are cheap, my work time is expensive. I refrain from using hardware RAID, though, since I had problems in migrating RAID disks to a new system in case of fan or power supply unit failure. With software RAID, it worked all the time. In addition, RAID gives nice possibilities for installing new SUSE versions instead of inline upgrades with no backup possibility. Just split the mirror (living for a few days without protection, usually I check smartctl first and look also for the raw numbers :-)) and install the new distribution on the 2nd disk. Fix the fallout from Puppet configuration, for changed ways to do configuration. Fallback is always available on the 1st disk -- after the new distribution works they are re-attached to the mirror again. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/21/14 03:49, Anton Aylward wrote:

This leads me to think that it might be useful to have a small, possibly SSD, disk for 'the system' to boot from and to hold the log file, and use the "mirrored" system for "data"

I asked especially why Dave didn't use RAID for his system disk. That RAID+LVM is a good choice for data file systems, is unquestioned. Well, except: When your data set is so large that you have daily disk failures, or even ones every few hour (as some of my customers have); all this advice is mood, of course. Then you probably use NetApp or EMC, and have system management people roaming your data center once a day with a cart full of replacement disks as part of their regular job tasks. It's part of my job to plan such processes, but in our own shop I don't need it. In this thread I'm talking about developer desktops or small servers in SOHO environments. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/21/14 13:03, Dave Howorth wrote:

Joachim Schrod wrote:

...

On 01/20/14 18:20, Dave Howorth wrote:

...

Yeah, is why I always keep the root and boot as non-RAID, non-LVM :(

I understand why you don't want to use LVM for them.

I don't understand why you do not want to use RAID.

Probably unjustified paranoia. I worry about not being able to boot because of errors during update or upgrade. I've read too many threads about issues with RAID and booting. I do use it for all my data and separately for the backups.

If you're that paranoid, you can use 0.9-style metadata that is placed at the end of the partition. Then the partition can always be accessed as standard ext[234] filesystem during boot. Doing so outside of read-only mounts breaks mirroring, of course; but you may sleep better knowing that you can access these partitions without RAID software.

So I just keep an offline mirror of the root disk. When there's a problem, I just plug that into the root position.

Interesting. How do you organize updates then? I mean, every few days new packages come in that change the root disk. Do you mirror these changes to your offline disk regularly? Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 1/20/2014 9:08 AM, Anton Aylward wrote:

On 01/20/2014 11:45 AM, Dave Howorth wrote:

...

lvm usually keeps backup info in /etc/lvm/backup and /etc/lvm/archive (depending on the configuration)

If I could read that much of the disk I'd be well ahead!

Well its bound to be in your backups, right? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Mon, 20 Jan 2014 12:07:42 -0500 Anton Aylward пишет:

On 01/20/2014 11:33 AM, Andrey Borzenkov wrote:

...

В Mon, 20 Jan 2014 11:25:18 -0500 Anton Aylward пишет:

...

On 01/20/2014 11:13 AM, Andrey Borzenkov wrote:

...

PV label is located withing first 4K on device (whole disk or partition), usually second sector. OUCH If partition table was corrupted, PV will not be found. You could search the whole disk for PV label header LABELONE. Is that a literal string?

Yes

Thank you.

...

...

What about the LVM partitions?

I'm not sure what you call "LVM partitions". PV or LV?

The whole disk is, apart from a boot and swap partition defined using fdisk when I initialized the disk, one big LVM. Only the one "PV". I have lots of LVs, about 20+ of them. Separated out out 'documents', 'downloads', photos' (by year), various projects, email archives and more.

...

...

I was under the impression that they each had their own LV information somewhere - that was what lvscan looked for - and this would be enough information to 'recover' the LV/partition.

LVM tools work with PV. If there is no PV, nothing will be found. Does pvscan output anything?

The trouble is that everything stops 'cos it can't read the first few cylinders. Right now I'm trying to determine if this is electronics, head motor, or if the disk is gouged.

If you have LVM configuration backups and know where partition started, you could try manually recreate LVs. If you do not have LVM configuration backups, you could try to find them on disk; there are multiple copies as text, something like # strings /dev/sda2 ... contents = "Text Format Volume Group" version = 1 description = "" creation_host = "opensuse.site" # Linux opensuse.site 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 creation_time = 1359191911 # Sat Jan 26 13:18:31 2013 system { id = "F1ikgD-2RES-306G-il9M-7iwa-4NKW-EbV1NV" seqno = 6 format = "lvm2" # informational ... physical_volumes { pv0 { id = "gPTUJ8-gNWl-siv1-JUtC-AEA9-Dr0N-Rf0456" device = "/dev/sda2" status = ["ALLOCATABLE"] flags = [] dev_size = 624091824 pe_start = 2048 pe_count = 76182 logical_volumes { swap { id = "rYCSC8-VwT5-8QtZ-ueTB-HGQU-WYer-tk0PJv" status = ["READ", "WRITE", "VISIBLE"] flags = [] segment_count = 1 segment1 { start_extent = 0 extent_count = 256 type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 0 ... This gives you full information about defined volume groups, PV they include and composition of each LV. Restoring this manually would be really boring. If possible, you should us dd_rescue to duplicate as much data as possible on another disk at the same location and use recovery procedure outlined in link that was posted. It will recreate LV structure. You may need to spend some time to guess partition offset of you do not know it (e.g. looking for know signatures like swap or FS UUIDs. I'd really recommend search for data recovery tools. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org