Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.setup > #2581 > unrolled thread
| Started by | Harry <simonsharry@gmail.com> |
|---|---|
| First post | 2012-04-12 03:29 -0700 |
| Last post | 2012-04-19 18:50 -0700 |
| Articles | 20 on this page of 81 — 10 participants |
Back to article view | Back to comp.os.linux.setup
No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 03:29 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 11:46 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 04:08 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 12:36 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 05:25 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 13:49 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 06:09 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 19:18 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 11:49 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-12 18:27 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-12 18:51 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 12:12 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2012-04-12 17:15 -0400
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 20:30 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 06:58 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 07:13 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-13 19:29 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 21:27 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-14 07:58 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-14 06:35 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-14 19:59 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-14 19:58 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-14 20:13 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-15 15:14 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 02:39 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-16 08:50 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 08:02 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 10:39 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 11:08 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-16 15:58 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 23:02 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-17 10:58 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-18 21:53 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-19 16:45 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-19 18:34 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-20 17:19 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-21 20:37 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-25 16:01 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-28 16:32 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-16 19:15 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 21:20 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 21:40 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 21:56 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-16 18:47 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 20:19 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-13 15:22 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! J G Miller <miller@yoyo.ORG> - 2012-04-13 17:13 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 21:58 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 15:50 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 21:37 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 15:46 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 09:35 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 18:57 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-12 15:59 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 16:39 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 09:53 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 19:03 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 09:48 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 19:07 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 18:43 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 10:55 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-12 18:07 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 19:20 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 19:11 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-12 20:39 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-13 16:50 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-13 21:24 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Doug Freyburger <dfreybur@yahoo.com> - 2012-04-16 19:04 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-16 21:44 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-17 17:18 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-17 18:41 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 19:09 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 10:46 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 19:13 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-12 12:21 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! unruh <unruh@invalid.ca> - 2012-04-12 20:12 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! g.fink@gmx.net (Gernot Fink) - 2012-04-12 18:20 +0000
Re: No success repairing my ext4 file system so far, PLEASE HELP! The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 21:35 +0100
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-19 06:43 -0700
Re: No success repairing my ext4 file system so far, PLEASE HELP! Bob <SEE_SIGNATURE@localhost.localdomain.invalid> - 2012-04-19 11:29 -0500
Re: No success repairing my ext4 file system so far, PLEASE HELP! Harry <simonsharry@gmail.com> - 2012-04-19 18:50 -0700
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-14 19:59 -0500 |
| Message-ID | <jmd6hs$8q5$1@omega-3a.local> |
| In reply to | #2633 |
On 04/14/2012 08:35 AM, Harry wrote:
>
> $ mv /etc/lvm /etc/lvm.off
>
> $ pvscan
> PV /dev/sdb2 lvm2 [74.04 GiB]
> Total: 1 [74.04 GiB] / in use: 0 [0 ] / in no VG: 1 [74.04 GiB]
^^^^^^^^^^^^^^^^
I'm having a hard time imagining what could have happened to make it
appear that there was nothing in use inside that PV, especially since
'pvck' did find metadata records in there. Had this system been
running for a long time without rebooting prior to your escapade?
That would raise the possibility that the structures on disk had
been damaged for quite a while, and the system couldn't have survived
a reboot.
Now, I'm wondering what your chances would be of reconstructing the
VGs and LVs from the data in the backup files. If those volumes had
ever been resized or rearranged since they were created, I fear your
chances of success would be just about nil, but I don't know what
else to suggest. I think I'd want to play around with that on newly
created structures on another disk before trying it for real.
--
Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-14 19:58 -0700 |
| Message-ID | <8999834.918.1334458710835.JavaMail.geo-discussion-forums@pbjk8> |
| In reply to | #2635 |
On Sunday, April 15, 2012 6:29:40 AM UTC+5:30, Robert Nichols wrote:
> On 04/14/2012 08:35 AM, Harry wrote:
> >
> > $ mv /etc/lvm /etc/lvm.off
> >
> > $ pvscan
> > PV /dev/sdb2 lvm2 [74.04 GiB]
> > Total: 1 [74.04 GiB] / in use: 0 [0 ] / in no VG: 1 [74.04 GiB]
> ^^^^^^^^^^^^^^^^
> I'm having a hard time imagining what could have happened to make it
> appear that there was nothing in use inside that PV, especially since
> 'pvck' did find metadata records in there. Had this system been
> running for a long time without rebooting prior to your escapade?
> That would raise the possibility that the structures on disk had
> been damaged for quite a while, and the system couldn't have survived
> a reboot.
This is what, I believe, I did.
The 80G sdb that I'm trying to recover now, used to be sda in my system earlier. I installed a 250G sdb in the system, installed Fedora 16 on it, made sdb bootable, and then booted my machine.
Now, my machine was booting fine from sdb. In my ignorance (of the low, system-level details of MBR, partitioning, BIOS, etc), I thought that if I copied the first 446 bytes of MBR of sdb (which is working fine right now for me) to sda, then I may be able to boot from sda also if I were to place sda into another machine. Since these 446 bytes would be pure boot code which would be common to both sda and sdb (esp, since both had Fedora 16 installs on them) and with no data in it, I thought, I had nothing to lose in trying this out: at worst, sda would continue to remain non-bootable at which point I'd look for some other solution.
So, I issued a:
dd if=/dev/sdb of=/dev/sda bs=446 count=1
and, I believe, sda continued to remain non-bootable.
Since, mentally, I tend to feel more comfortable with sda being the primary/bootable disk in my system, at this point I physically switched sda and sdb cables in my machine.
I still didn't think anything was seriously wrong; I thought, I should be able to fix things now. Now, because I didn't understand LVM *at all* (I have 'some' idea now, though), I incorrectly thought that the sdb2 partition (shown by fdisk -l) was really an ext4 filesystem (and 'not' an LVM volume!), and 'all' I had to do in order to be able to mount it was to use the standard methods suggested on the Net. (sdb was being reported as having a bad superblock and ext4 supposedly has redundant backups of this stored in it.) When I couldn't, I posted the question on superuser.com here, http://superuser.com/questions/410796/unable-to-repair-an-ext4-filesystem-with-bad-superblock .
Note: I when this ext4 repair attempt didn't succeed on the sdb2 (partition), I even (incorrectly) tried the commands on sdb (the device)!
At which point, someone on this forum enlightened me that because it was an LVM and not an ext4, ext4 repair tools were not working.
I *hope* these ext4 repair commands didn't mess up the LVM; each superblock I would specify would fail to get recognized as a valid superblock and so the repair operation would fail. Had the e2fsck command really succeeded by incorrectly identifying some random data as a valid superblock, then I could understand how it may have corrupted the LVM that I'm not struggling to bring back to life.
Only at this point, did I begin to anticipate serious trouble ahead and decided to clone /dev/sdb with dd. Therefore, strictly speaking, the cloned sdb image I have now, does NOT reflect the state of things immediately after the 'MBR 446-byte overwrite' operation. I'm still assuming that none of my repair attempts (e2fsck) corrupted the LVM on sdb2.
> Now, I'm wondering what your chances would be of reconstructing the
> VGs and LVs from the data in the backup files. If those volumes had
> ever been resized or rearranged since they were created, I fear your
> chances of success would be just about nil, but I don't know what
> else to suggest. I think I'd want to play around with that on newly
> created structures on another disk before trying it for real.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
On Sunday, April 15, 2012 6:29:40 AM UTC+5:30, Robert Nichols wrote:
> On 04/14/2012 08:35 AM, Harry wrote:
> >
> > $ mv /etc/lvm /etc/lvm.off
> >
> > $ pvscan
> > PV /dev/sdb2 lvm2 [74.04 GiB]
> > Total: 1 [74.04 GiB] / in use: 0 [0 ] / in no VG: 1 [74.04 GiB]
> ^^^^^^^^^^^^^^^^
> I'm having a hard time imagining what could have happened to make it
> appear that there was nothing in use inside that PV, especially since
> 'pvck' did find metadata records in there. Had this system been
> running for a long time without rebooting prior to your escapade?
> That would raise the possibility that the structures on disk had
> been damaged for quite a while, and the system couldn't have survived
> a reboot.
>
> Now, I'm wondering what your chances would be of reconstructing the
> VGs and LVs from the data in the backup files. If those volumes had
> ever been resized or rearranged since they were created, I fear your
> chances of success would be just about nil, but I don't know what
> else to suggest. I think I'd want to play around with that on newly
> created structures on another disk before trying it for real.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
This is what, I believe, I did.
The 80G sdb that I'm trying to recover now, used to be sda in my system earlier. I then installed a 250G sdb in the system, installed Fedora 16 on it, made sdb bootable, and then booted my sytsem.
Now, my system was booting just fine from sdb. In my ignorance (of the low, system-level details of MBR, partitioning, BIOS, etc), I thought that if I copied the first 446 bytes of MBR of sdb (which is working fine right now for me) to sda, then I might be able to boot from sda also if I were to place sda into another system. Since these 446 bytes would be pure boot code which would be common to both sda and sdb (esp, since both had Fedora 16 installs on them) and with no data in it, I thought, I had nothing to lose in trying this operation out: at worst, sda would continue to remain non-bootable, at which point I'd look for some other solution.
So, I fearlessly issued a
dd if=/dev/sdb of=/dev/sda bs=446 count=1
and, I believe, sda continued to remain non-bootable.
Since, mentally, I tend to feel more comfortable with sda being the primary/bootable disk in my system, at this point I physically switched sda and sdb cables in my system.
I still didn't think anything was seriously wrong; I thought, I should be able to fix things now. Now, because I didn't understand LVM *at all* (I only have a very high-level idea, even now!), I incorrectly thought that the sdb2 partition (shown by fdisk -l) was really an ext4 filesystem (and 'not' an LVM volume!), and 'all' I had to do in order to be able to mount it was to use the standard methods suggested on the Net. (sdb was being reported as having a bad superblock and ext4 supposedly has redundant backups of this stored in it which one could use to repair it.) When I couldn't mount/repair, I posted the question here,
http://superuser.com/questions/410796/unable-to-repair-an-ext4-filesystem-with-bad-superblock .
---------------
Note: When this ext4 repair attempt didn't succeed on the sdb2 (partition), I even (incorrectly) tried the commands on sdb (the device) using various superblock offsets. Because the e2fsck man page has this statement in it
"The location of the backup superblock is dependent on the filesystem's blocksize.
For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for
filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768."
, I even tried this command by assuming different blocksizes, for I thought I wouldn't be able to accurately and easily find out the actual blocksize of the filesystem given that it is in a 'broken' state at this point.
---------------
At this point, someone on this forum enlightened me that, because it was an LVM and not an ext4, ext4 repair tools were not working.
I *hope* these ext4 repair commands didn't mess up the LVM; each superblock offset I would specify would fail to get recognized as a valid superblock by e2fsck and so the repair operation would fail. Had the e2fsck command really succeeded by incorrectly identifying some random junk as a valid superblock, then I could understand (*now*) how it may have corrupted the LVM that I'm now struggling to bring back to life.
Only at this point and not any earlier, did I begin to anticipate serious trouble ahead and decided to clone /dev/sdb. Therefore, strictly speaking, the cloned sdb image I have now, does NOT reflect the state of things immediately after the 'MBR 446-byte overwrite' operation. I'm still hoping that none of my repair attempts (via e2fsck on both the device-sdb and the partition-sdb2!) corrupted the LVM on sdb2.
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-14 20:13 -0700 |
| Message-ID | <33504745.932.1334459589543.JavaMail.geo-discussion-forums@pbcsi9> |
| In reply to | #2635 |
On Sunday, April 15, 2012 6:29:40 AM UTC+5:30, Robert Nichols wrote:
> On 04/14/2012 08:35 AM, Harry wrote:
> >
> > $ mv /etc/lvm /etc/lvm.off
> >
> > $ pvscan
> > PV /dev/sdb2 lvm2 [74.04 GiB]
> > Total: 1 [74.04 GiB] / in use: 0 [0 ] / in no VG: 1 [74.04 GiB]
> ^^^^^^^^^^^^^^^^
> I'm having a hard time imagining what could have happened to make it
> appear that there was nothing in use inside that PV, especially since
> 'pvck' did find metadata records in there. Had this system been
> running for a long time without rebooting prior to your escapade?
> That would raise the possibility that the structures on disk had
> been damaged for quite a while, and the system couldn't have survived
> a reboot.
>
> Now, I'm wondering what your chances would be of reconstructing the
> VGs and LVs from the data in the backup files. If those volumes had
> ever been resized or rearranged since they were created, I fear your
> chances of success would be just about nil, but I don't know what
> else to suggest. I think I'd want to play around with that on newly
> created structures on another disk before trying it for real.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
This is what, I believe, I did.
The 80G sdb that I'm trying to recover now, used to be sda in my system earlier. I then installed a 250G sdb in the system, installed Fedora 16 on it, made sdb bootable, and then booted my sytsem.
Now, my system was booting just fine from sdb. In my ignorance (of the low, system-level details of MBR, partitioning, BIOS, etc), I thought that if I copied the first 446 bytes of MBR of sdb (which is working fine right now for me) to sda, then I might be able to boot from sda also if I were to place sda into another system. Since these 446 bytes would be pure boot code which would be common to both sda and sdb (esp, since both had Fedora 16 installs on them) and with no data in it, I thought, I had nothing to lose in trying this operation out: at worst, sda would continue to remain non-bootable, at which point I'd look for some other solution.
So, I fearlessly issued a
dd if=/dev/sdb of=/dev/sda bs=446 count=1
and, I believe, sda continued to remain non-bootable.
Since, mentally, I tend to feel more comfortable with sda being the primary/bootable disk in my system, at this point I physically switched sda and sdb cables in my system.
I still didn't think anything was seriously wrong; I thought, I should be able to fix things now. Now, because I didn't understand LVM *at all* (I only have a very high-level idea, even now!), I incorrectly thought that the sdb2 partition (shown by fdisk -l) was really an ext4 filesystem (and 'not' an LVM volume!), and 'all' I had to do in order to be able to mount it was to use the standard methods suggested on the Net. (sdb was being reported as having a bad superblock and ext4 supposedly has redundant backups of this stored in it which one could use to repair it.) When I couldn't mount/repair, I posted the question here,
http://superuser.com/questions/410796/unable-to-repair-an-ext4-filesystem-with-bad-superblock .
---------------
Note: When this ext4 repair attempt didn't succeed on the sdb2 (partition), I even (incorrectly) tried the commands on sdb (the device) using various superblock offsets. Because the e2fsck man page has this statement in it
"The location of the backup superblock is dependent on the filesystem's blocksize.
For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for
filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768."
, I even tried this command by assuming different blocksizes, for I thought I wouldn't be able to accurately and easily find out the actual blocksize of the filesystem given that it is in a 'broken' state at this point.
---------------
At this point, someone on this forum enlightened me that, because it was an LVM and not an ext4, ext4 repair tools were not working.
I *hope* these ext4 repair commands didn't mess up the LVM; each superblock offset I would specify would fail to get recognized as a valid superblock by e2fsck and so the repair operation would fail. Had the e2fsck command really succeeded by incorrectly identifying some random junk as a valid superblock, then I could understand (*now*) how it may have corrupted the LVM that I'm now struggling to bring back to life.
Only at this point and not any earlier, did I begin to anticipate serious trouble ahead and decided to clone /dev/sdb. Therefore, strictly speaking, the cloned sdb image I have now, does NOT reflect the state of things immediately after the 'MBR 446-byte overwrite' operation. I'm still hoping that none of my repair attempts (via e2fsck on both the device-sdb and the partition-sdb2!) corrupted the LVM on sdb2.
[toc] | [prev] | [next] | [standalone]
| From | Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-15 15:14 -0500 |
| Message-ID | <jmfa77$v18$1@omega-3a.local> |
| In reply to | #2637 |
On 04/14/2012 10:13 PM, Harry wrote: > > This is what, I believe, I did. [recap snipped] I don't see any way that anything you reported doing could cause the problem you are seeing, and frankly I can't come up with any likely typos in those commands that would do it either. If you had mistyped the destination device as "sda1" or "sda2" instead of "sda", nothing would have been affected (neither ext2/3/4 nor LVM2 store anything in the first 512 bytes). If you had mistyped the blocksize as "446k" or the count as "1k", you would have overwritten the partition table and possibly part of the ext3 file system on that first partition. You've still got what appears to be a good partition table, a good file system on the first partition, and an LVM2 header at the appropriate location in the second partition. e2fsck won't do any writing if it doesn't find something that looks like a valid superblock. Something else had to have happened, but I can't imagine what. What is the history of that LVM2 PV? Is it likely that the LVs were allocated in single extents? As a last resort you could do a brute force search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF) at offset 56 (0x48) in a sector, making that a possible superblock, then use dmsetup to define a virtual device that begins 1024 bytes prior to that sector and see what e2fsck has to say about that (use the "-n" option so that it will open the device read-only). Sounds like it might take a long time, but probably no more than you've already spent. -- Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 02:39 -0700 |
| Message-ID | <6086077.2030.1334569167288.JavaMail.geo-discussion-forums@pbep2> |
| In reply to | #2645 |
On Monday, April 16, 2012 1:44:31 AM UTC+5:30, Robert Nichols wrote:
> On 04/14/2012 10:13 PM, Harry wrote:
> >
> > This is what, I believe, I did.
> [recap snipped]
> I don't see any way that anything you reported doing could cause the problem
> you are seeing, and frankly I can't come up with any likely typos in those
> commands that would do it either. If you had mistyped the destination
> device as "sda1" or "sda2" instead of "sda", nothing would have been
> affected (neither ext2/3/4 nor LVM2 store anything in the first 512 bytes).
> If you had mistyped the blocksize as "446k" or the count as "1k", you would
> have overwritten the partition table and possibly part of the ext3 file
> system on that first partition. You've still got what appears to be a good
> partition table, a good file system on the first partition, and an LVM2
> header at the appropriate location in the second partition. e2fsck won't do
> any writing if it doesn't find something that looks like a valid superblock.
> Something else had to have happened, but I can't imagine what.
I'm happy to hear that.
> What is the history of that LVM2 PV? Is it likely that the LVs were
> allocated in single extents?
Don't know. I recall just going with the Fedora 16 installation-time defaults, and only changing the sizes of the swap and root partitions.
> As a last resort you could do a brute force
> search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF)
> at offset 56 (0x48) in a sector, making that a possible superblock, then
> use dmsetup to define a virtual device that begins 1024 bytes prior to that
> sector and see what e2fsck has to say about that (use the "-n" option so
> that it will open the device read-only). Sounds like it might take a long
> time, but probably no more than you've already spent.
I think, you meant "offset 56 (0x38)".
I have launched the script listed below. It doesn't do the virtual device mapping *yet*; for now, it just looks for the signature. I will add the device mapper later.
After 43 minutes of running, I printed the progress (kill -10) and got this:
Trying sector 948135 of 146997248 .645001 %
ETA: 230 hours ( 9.58 days)
Any way to speed it up... say, by skipping regions of the device, considering interesting regions first?
----------------------------------------------------------------
#!/bin/bash
set -u
function printProgress {
local timeCurr=
local timeTaken=
local eta=
echo "Trying sector $currSector of $lastSector " $(echo "scale=6; $currSector * 100.0 / $lastSector " | bc) " %"
timeCurr=$(date +%s) # seconds
(( timeTaken = timeCurr - timeStart ))
(( eta = timeTaken * (lastSector - currSector) / (currSector - startSector) / 3600 ))
echo " ETA: $eta hours" "(" $(echo "scale=2; $eta / 24" | bc) " days)"
}
timeStart=$(date +%s)
trap "printProgress" 10
extent_count=2243
extent_size=65536
lastSector=$((extent_count * extent_size))
# Start by skipping these many sectors.
#
# Use either the first arg to this script or
# a default value of 2.
skipSectors=${1-2}
((startSector = skipSectors + 1 ))
echo "Started, by skipping $skipSectors sectors."
# ---------------------
# Main loop
# ---------------------
while :; do
((currSector = skipSectors + 1 ))
# Get the signature 'sig'. I have tested that this incantation
# does indeed give the signature 53ef for a device having a
# valid ext4 partition in the beginning.
sig=$(dd if=/dev/sdb2 bs=512 skip=$skipSectors |
xxd -c 10 | head -109 | tail -1 | cut -d ' ' -f2)
if [ "$sig" = "53ef" ]; then
echo "Found an ext4 fs at sector $currSector , quitting."
break
fi
# Did not find ext4 sig at the above location, try the next sector
((skipSectors += 1))
if [ $skipSectors -eq $lastSector ]; then
# No more sectors to skip.
echo "FAILED to find an ext4 fs."
break
fi
done
----------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-16 08:50 -0500 |
| Message-ID | <jmh836$rte$1@omega-3a.local> |
| In reply to | #2650 |
[Multipart message — attachments visible in raw view] — view raw
On 04/16/2012 04:39 AM, Harry wrote: > On Monday, April 16, 2012 1:44:31 AM UTC+5:30, Robert Nichols wrote: [SNIP] >> As a last resort you could do a brute force >> search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF) >> at offset 56 (0x48) in a sector, making that a possible superblock, then >> use dmsetup to define a virtual device that begins 1024 bytes prior to that >> sector and see what e2fsck has to say about that (use the "-n" option so >> that it will open the device read-only). Sounds like it might take a long >> time, but probably no more than you've already spent. > > > I think, you meant "offset 56 (0x38)". Indeed! Sorry about that. > I have launched the script listed below. It doesn't do the virtual device mapping *yet*; for now, it just looks for the signature. I will add the device mapper later. > > After 43 minutes of running, I printed the progress (kill -10) and got this: > Trying sector 948135 of 146997248 .645001 % > ETA: 230 hours ( 9.58 days) Yipe! I've attached a C program that looks for a sector with the EF53 magic number plus a valid blocksize and a label string that is either empty or contains valid ASCII characters. It searched a 160GB partition in about 45 minutes. Note that you will need to subtract 1024 bytes from this offset when setting up the virtual device. -- Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 08:02 -0700 |
| Message-ID | <21079405.567.1334588541327.JavaMail.geo-discussion-forums@pbcuu8> |
| In reply to | #2652 |
On Monday, April 16, 2012 7:20:30 PM UTC+5:30, Robert Nichols wrote:
> On 04/16/2012 04:39 AM, Harry wrote:
> > On Monday, April 16, 2012 1:44:31 AM UTC+5:30, Robert Nichols wrote:
> [SNIP]
> >> As a last resort you could do a brute force
> >> search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF)
> >> at offset 56 (0x48) in a sector, making that a possible superblock, then
> >> use dmsetup to define a virtual device that begins 1024 bytes prior to that
> >> sector and see what e2fsck has to say about that (use the "-n" option so
> >> that it will open the device read-only). Sounds like it might take a long
> >> time, but probably no more than you've already spent.
> >
> >
> > I think, you meant "offset 56 (0x38)".
>
> Indeed! Sorry about that.
>
> > I have launched the script listed below. It doesn't do the virtual device mapping *yet*; for now, it just looks for the signature. I will add the device mapper later.
> >
> > After 43 minutes of running, I printed the progress (kill -10) and got this:
> > Trying sector 948135 of 146997248 .645001 %
> > ETA: 230 hours ( 9.58 days)
>
> Yipe! I've attached a C program that looks for a sector with the EF53
> magic number plus a valid blocksize and a label string that is either
> empty or contains valid ASCII characters. It searched a 160GB partition
> in about 45 minutes.
>
> Note that you will need to subtract 1024 bytes from this offset when
> setting up the virtual device.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
>
>
> begin 664 e2finder.c
> M(V1E9FEN92!?1DE,15]/1D93151?0DE44R`V-`HC:6YC;'5D92`\<W1D:6\N
> M:#X*(VEN8VQU9&4@/'-T9&QI8BYH/@HC:6YC;'5D92`\<W1R:6YG+F@^"B-I
> M;F-L=61E(#QE<G)N;RYH/@HC:6YC;'5D92`\8W1Y<&4N:#X*(VEN8VQU9&4@
> M/&QI;G5X+V9S+F@^"B-I;F-L=61E(#QL:6YU>"]E>'0R7V9S+F@^"@HC9&5F
> M:6YE('-P8B`H<VEZ96]F*&)U9BDO-3$R*0H*:6YT(&UA:6XH:6YT(&%R9V,L
> M(&-H87(@*F%R9W9;72D@>PH@("`@;&]N9R!B;&MC;W5N=#L*("`@(&EN="!S
> M96-T;W(L(&YS+"!P+"!O:SL*("`@('-T871I8R!C:&%R(&)U9ELT,#DV73L*
> M("`@($9)3$4@*FEN9CL*("`@(&-H87(@*F-M9"P@*FQA8F5L.PH@("`@<W1R
> M=6-T(&5X=#)?<W5P97)?8FQO8VL@*G-B7W!T<CL*"B`@("!I9B@H8VUD(#T@
> M<W1R<F-H<BAA<F=V6S!=+"`G+R<I*2`A/2!.54Q,*2`@*RMC;60["B`@("!E
> M;'-E("!C;60@/2!A<F=V6S!=.PH*("`@(&EF*&%R9V,@/"`R*2!["@EF<')I
> M;G1F*'-T9&5R<BP@(E5S86=E.B`E<R!D979I8V5<;B(L(&-M9"D["@ER971U
> M<FX@,3L*("`@('T*("`@(&EF*"AI;F8@/2!F;W!E;BAA<F=V6S%=+"`B<B(I
> M*2`]/2!.54Q,*2!["@EP97)R;W(H87)G=ELQ72D["@ER971U<FX@,3L*("`@
> M('T*"B`@("!P=71S*")">71E(&]F9G-E="`@<V5C=&]R("@U,3)"*2(I.PH@
> M("`@<'5T<R@B+2TM+2TM+2TM+2TM("`M+2TM+2TM+2(I.PH@("`@8FQK8V]U
> M;G0@/2`P.PH@("`@=VAI;&4H*&YS(#T@9G)E860H8G5F+"`U,3(L('-P8BP@
> M:6YF*2D@/B`P*2!["@EF;W(H<V5C=&]R(#T@,#L@<V5C=&]R(#P@;G,[("LK
> M('-E8W1O<BD@>PH)("`@('-B7W!T<B`]("AS=')U8W0@97AT,E]S=7!E<E]B
> M;&]C:R`J*2AB=68K-3$R*G-E8W1O<BD["@D@("`@:68H<V)?<'1R+3YS7VUA
> M9VEC(#T](#!X968U,RD@>PH)"6QA8F5L(#T@<V)?<'1R+3YS7W9O;'5M95]N
> M86UE.PH)"6]K(#T@,#L*"0EF;W(H<"`](#`[('`@/"!S:7IE;V8H<V)?<'1R
> M+3YS7W9O;'5M95]N86UE*3L@*RMP*2!["@D)("`@(&EF*&QA8F5L6W!=(#T]
> M("=<,"<I('LK*V]K.R`@8G)E86L[?0H)"2`@("!I9B@A*&ES87-C:6DH;&%B
> M96Q;<%TI*2D@(&)R96%K.PH)"2`@("!I9B@A*&ES9W)A<&@H;&%B96Q;<%TI
> M('Q\(&ES8FQA;FLH;&%B96Q;<%TI*2D@(&)R96%K.PH)"7T*"0EI9B@H=6YS
> M:6=N960I*'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ92D@/B`R*2`@8V]N=&EN
> M=64["@D):68H;VL@?'P@<#X]."D@>PH)"2`@("!P<FEN=&8H(B4C,#$R;'@@
> M*"4X;&0I+"!L86)E;#U<(B4N,39S7"(L(&)S/25D:UQN(BP*"0D)("`@-3$R
> M*BAB;&MC;W5N="MS96-T;W(I+`H)"0D@("`H8FQK8V]U;G0K<V5C=&]R*2P*
> M"0D)("`@;&%B96PL"@D)"2`@(#$\/'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ
> M92D["@D)("`@(&9F;'5S:"AS=&1O=70I.PH)"7T*"2`@("!]"@E]"@EB;&MC
> M;W5N="`K/2!N<SL*("`@('T*("`@(&EF*&9E;V8H:6YF*2D@>PH)9G!R:6YT
> M9BAS=&1E<G(L(")%3T8@;VX@)7-<;B(L(&%R9W9;,5TI.PH)<F5T=7)N(#`[
> M"B`@("!]"B`@("!E;'-E(&EF*&9E<G)O<BAI;F8I*2`@<&5R<F]R*&%R9W9;
> 5,5TI.PH@("`@<F5T=7)N(#$["GT*
> `
> end
Hey - first of all, THANKS for sharing your C program! I had written mine; though it processes under an hour (just like yours), it VERY LIKELY has bugs and I won't trust it at all. So, would rather use yours.
I get this error when I try to compile it. Cursory googling tells me umode_t is deprecated. Any quick workaround for this?
$ gcc -o e2finder e2finder.c
In file included from e2finder.c:8:0:
/usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 10:39 -0700 |
| Message-ID | <15869324.2180.1334597948632.JavaMail.geo-discussion-forums@pbckz3> |
| In reply to | #2652 |
On Monday, April 16, 2012 7:20:30 PM UTC+5:30, Robert Nichols wrote:
> On 04/16/2012 04:39 AM, Harry wrote:
> > On Monday, April 16, 2012 1:44:31 AM UTC+5:30, Robert Nichols wrote:
> [SNIP]
> >> As a last resort you could do a brute force
> >> search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF)
> >> at offset 56 (0x48) in a sector, making that a possible superblock, then
> >> use dmsetup to define a virtual device that begins 1024 bytes prior to that
> >> sector and see what e2fsck has to say about that (use the "-n" option so
> >> that it will open the device read-only). Sounds like it might take a long
> >> time, but probably no more than you've already spent.
> >
> >
> > I think, you meant "offset 56 (0x38)".
>
> Indeed! Sorry about that.
>
> > I have launched the script listed below. It doesn't do the virtual device mapping *yet*; for now, it just looks for the signature. I will add the device mapper later.
> >
> > After 43 minutes of running, I printed the progress (kill -10) and got this:
> > Trying sector 948135 of 146997248 .645001 %
> > ETA: 230 hours ( 9.58 days)
>
> Yipe! I've attached a C program that looks for a sector with the EF53
> magic number plus a valid blocksize and a label string that is either
> empty or contains valid ASCII characters. It searched a 160GB partition
> in about 45 minutes.
>
> Note that you will need to subtract 1024 bytes from this offset when
> setting up the virtual device.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
>
>
> begin 664 e2finder.c
> M(V1E9FEN92!?1DE,15]/1D93151?0DE44R`V-`HC:6YC;'5D92`\<W1D:6\N
> M:#X*(VEN8VQU9&4@/'-T9&QI8BYH/@HC:6YC;'5D92`\<W1R:6YG+F@^"B-I
> M;F-L=61E(#QE<G)N;RYH/@HC:6YC;'5D92`\8W1Y<&4N:#X*(VEN8VQU9&4@
> M/&QI;G5X+V9S+F@^"B-I;F-L=61E(#QL:6YU>"]E>'0R7V9S+F@^"@HC9&5F
> M:6YE('-P8B`H<VEZ96]F*&)U9BDO-3$R*0H*:6YT(&UA:6XH:6YT(&%R9V,L
> M(&-H87(@*F%R9W9;72D@>PH@("`@;&]N9R!B;&MC;W5N=#L*("`@(&EN="!S
> M96-T;W(L(&YS+"!P+"!O:SL*("`@('-T871I8R!C:&%R(&)U9ELT,#DV73L*
> M("`@($9)3$4@*FEN9CL*("`@(&-H87(@*F-M9"P@*FQA8F5L.PH@("`@<W1R
> M=6-T(&5X=#)?<W5P97)?8FQO8VL@*G-B7W!T<CL*"B`@("!I9B@H8VUD(#T@
> M<W1R<F-H<BAA<F=V6S!=+"`G+R<I*2`A/2!.54Q,*2`@*RMC;60["B`@("!E
> M;'-E("!C;60@/2!A<F=V6S!=.PH*("`@(&EF*&%R9V,@/"`R*2!["@EF<')I
> M;G1F*'-T9&5R<BP@(E5S86=E.B`E<R!D979I8V5<;B(L(&-M9"D["@ER971U
> M<FX@,3L*("`@('T*("`@(&EF*"AI;F8@/2!F;W!E;BAA<F=V6S%=+"`B<B(I
> M*2`]/2!.54Q,*2!["@EP97)R;W(H87)G=ELQ72D["@ER971U<FX@,3L*("`@
> M('T*"B`@("!P=71S*")">71E(&]F9G-E="`@<V5C=&]R("@U,3)"*2(I.PH@
> M("`@<'5T<R@B+2TM+2TM+2TM+2TM("`M+2TM+2TM+2(I.PH@("`@8FQK8V]U
> M;G0@/2`P.PH@("`@=VAI;&4H*&YS(#T@9G)E860H8G5F+"`U,3(L('-P8BP@
> M:6YF*2D@/B`P*2!["@EF;W(H<V5C=&]R(#T@,#L@<V5C=&]R(#P@;G,[("LK
> M('-E8W1O<BD@>PH)("`@('-B7W!T<B`]("AS=')U8W0@97AT,E]S=7!E<E]B
> M;&]C:R`J*2AB=68K-3$R*G-E8W1O<BD["@D@("`@:68H<V)?<'1R+3YS7VUA
> M9VEC(#T](#!X968U,RD@>PH)"6QA8F5L(#T@<V)?<'1R+3YS7W9O;'5M95]N
> M86UE.PH)"6]K(#T@,#L*"0EF;W(H<"`](#`[('`@/"!S:7IE;V8H<V)?<'1R
> M+3YS7W9O;'5M95]N86UE*3L@*RMP*2!["@D)("`@(&EF*&QA8F5L6W!=(#T]
> M("=<,"<I('LK*V]K.R`@8G)E86L[?0H)"2`@("!I9B@A*&ES87-C:6DH;&%B
> M96Q;<%TI*2D@(&)R96%K.PH)"2`@("!I9B@A*&ES9W)A<&@H;&%B96Q;<%TI
> M('Q\(&ES8FQA;FLH;&%B96Q;<%TI*2D@(&)R96%K.PH)"7T*"0EI9B@H=6YS
> M:6=N960I*'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ92D@/B`R*2`@8V]N=&EN
> M=64["@D):68H;VL@?'P@<#X]."D@>PH)"2`@("!P<FEN=&8H(B4C,#$R;'@@
> M*"4X;&0I+"!L86)E;#U<(B4N,39S7"(L(&)S/25D:UQN(BP*"0D)("`@-3$R
> M*BAB;&MC;W5N="MS96-T;W(I+`H)"0D@("`H8FQK8V]U;G0K<V5C=&]R*2P*
> M"0D)("`@;&%B96PL"@D)"2`@(#$\/'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ
> M92D["@D)("`@(&9F;'5S:"AS=&1O=70I.PH)"7T*"2`@("!]"@E]"@EB;&MC
> M;W5N="`K/2!N<SL*("`@('T*("`@(&EF*&9E;V8H:6YF*2D@>PH)9G!R:6YT
> M9BAS=&1E<G(L(")%3T8@;VX@)7-<;B(L(&%R9W9;,5TI.PH)<F5T=7)N(#`[
> M"B`@("!]"B`@("!E;'-E(&EF*&9E<G)O<BAI;F8I*2`@<&5R<F]R*&%R9W9;
> 5,5TI.PH@("`@<F5T=7)N(#$["GT*
> `
> end
Bob,
I had to add this line before include <stdio.h> to get the program to compile:
#define umode_t mode_t
Because mode_t itself is defined as 'unsigned <something>', I took the quick liberty of doing the above without a sufficiently deeper thought on all its ramifications.
There were 1601 entries printed. I extracted the base 10 number (from the parentheses), subtracted 2 (sectors) from it, and used the resulting number in device mapping code as follows:
# This just extracts the sector that has the e2 fs signature.
# Actual subtraction will be done later below, in the script.
$ cat e2finder.log | sed -r 's/\(|\)|,//g' | field 2 > tmp
$ cat tmp
8521728
...
98174976
---------------------------------
#!/bin/bash
set -u
if [ -b /dev/mapper/foo ]; then
dmsetup remove foo
fi
bogusMax=100
cat tmp | while read x; do
# superblock starts 2 sectors earlier
(( x = x - 2 ))
echo "Trying superblock at sector $x ..."
if dmsetup create foo --table "0 $bogusMax linear /dev/sdb2 $x"; then
if e2fsck -n /dev/mapper/foo &>/dev/null; then
echo "Found superblock at sector $x ."
else
echo "FAILED to find superblock at sector $x ."
fi
dmsetup remove foo
else
echo "FAILED to dmsetup at sector $x"
fi
done
---------------------------------
Unfortunately, every single superblock offset failed!
Trying superblock at sector 8521726 ...
FAILED to find superblock at sector 8521726 .
...
Trying superblock at sector 98174974 ...
FAILED to find superblock at sector 98174974 .
Do I still have hope?!
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 11:08 -0700 |
| Message-ID | <14586514.2133.1334599711450.JavaMail.geo-discussion-forums@pblb1> |
| In reply to | #2655 |
On Monday, April 16, 2012 11:09:08 PM UTC+5:30, Harry wrote:
> On Monday, April 16, 2012 7:20:30 PM UTC+5:30, Robert Nichols wrote:
> > On 04/16/2012 04:39 AM, Harry wrote:
> > > On Monday, April 16, 2012 1:44:31 AM UTC+5:30, Robert Nichols wrote:
> > [SNIP]
> > >> As a last resort you could do a brute force
> > >> search for a 16-bit integer 0xEF53 (little-endian, the byte order is 53 EF)
> > >> at offset 56 (0x48) in a sector, making that a possible superblock, then
> > >> use dmsetup to define a virtual device that begins 1024 bytes prior to that
> > >> sector and see what e2fsck has to say about that (use the "-n" option so
> > >> that it will open the device read-only). Sounds like it might take a long
> > >> time, but probably no more than you've already spent.
> > >
> > >
> > > I think, you meant "offset 56 (0x38)".
> >
> > Indeed! Sorry about that.
> >
> > > I have launched the script listed below. It doesn't do the virtual device mapping *yet*; for now, it just looks for the signature. I will add the device mapper later.
> > >
> > > After 43 minutes of running, I printed the progress (kill -10) and got this:
> > > Trying sector 948135 of 146997248 .645001 %
> > > ETA: 230 hours ( 9.58 days)
> >
> > Yipe! I've attached a C program that looks for a sector with the EF53
> > magic number plus a valid blocksize and a label string that is either
> > empty or contains valid ASCII characters. It searched a 160GB partition
> > in about 45 minutes.
> >
> > Note that you will need to subtract 1024 bytes from this offset when
> > setting up the virtual device.
> >
> > --
> > Bob Nichols AT comcast.net I am "RNichols42"
> >
> >
> > begin 664 e2finder.c
> > M(V1E9FEN92!?1DE,15]/1D93151?0DE44R`V-`HC:6YC;'5D92`\<W1D:6\N
> > M:#X*(VEN8VQU9&4@/'-T9&QI8BYH/@HC:6YC;'5D92`\<W1R:6YG+F@^"B-I
> > M;F-L=61E(#QE<G)N;RYH/@HC:6YC;'5D92`\8W1Y<&4N:#X*(VEN8VQU9&4@
> > M/&QI;G5X+V9S+F@^"B-I;F-L=61E(#QL:6YU>"]E>'0R7V9S+F@^"@HC9&5F
> > M:6YE('-P8B`H<VEZ96]F*&)U9BDO-3$R*0H*:6YT(&UA:6XH:6YT(&%R9V,L
> > M(&-H87(@*F%R9W9;72D@>PH@("`@;&]N9R!B;&MC;W5N=#L*("`@(&EN="!S
> > M96-T;W(L(&YS+"!P+"!O:SL*("`@('-T871I8R!C:&%R(&)U9ELT,#DV73L*
> > M("`@($9)3$4@*FEN9CL*("`@(&-H87(@*F-M9"P@*FQA8F5L.PH@("`@<W1R
> > M=6-T(&5X=#)?<W5P97)?8FQO8VL@*G-B7W!T<CL*"B`@("!I9B@H8VUD(#T@
> > M<W1R<F-H<BAA<F=V6S!=+"`G+R<I*2`A/2!.54Q,*2`@*RMC;60["B`@("!E
> > M;'-E("!C;60@/2!A<F=V6S!=.PH*("`@(&EF*&%R9V,@/"`R*2!["@EF<')I
> > M;G1F*'-T9&5R<BP@(E5S86=E.B`E<R!D979I8V5<;B(L(&-M9"D["@ER971U
> > M<FX@,3L*("`@('T*("`@(&EF*"AI;F8@/2!F;W!E;BAA<F=V6S%=+"`B<B(I
> > M*2`]/2!.54Q,*2!["@EP97)R;W(H87)G=ELQ72D["@ER971U<FX@,3L*("`@
> > M('T*"B`@("!P=71S*")">71E(&]F9G-E="`@<V5C=&]R("@U,3)"*2(I.PH@
> > M("`@<'5T<R@B+2TM+2TM+2TM+2TM("`M+2TM+2TM+2(I.PH@("`@8FQK8V]U
> > M;G0@/2`P.PH@("`@=VAI;&4H*&YS(#T@9G)E860H8G5F+"`U,3(L('-P8BP@
> > M:6YF*2D@/B`P*2!["@EF;W(H<V5C=&]R(#T@,#L@<V5C=&]R(#P@;G,[("LK
> > M('-E8W1O<BD@>PH)("`@('-B7W!T<B`]("AS=')U8W0@97AT,E]S=7!E<E]B
> > M;&]C:R`J*2AB=68K-3$R*G-E8W1O<BD["@D@("`@:68H<V)?<'1R+3YS7VUA
> > M9VEC(#T](#!X968U,RD@>PH)"6QA8F5L(#T@<V)?<'1R+3YS7W9O;'5M95]N
> > M86UE.PH)"6]K(#T@,#L*"0EF;W(H<"`](#`[('`@/"!S:7IE;V8H<V)?<'1R
> > M+3YS7W9O;'5M95]N86UE*3L@*RMP*2!["@D)("`@(&EF*&QA8F5L6W!=(#T]
> > M("=<,"<I('LK*V]K.R`@8G)E86L[?0H)"2`@("!I9B@A*&ES87-C:6DH;&%B
> > M96Q;<%TI*2D@(&)R96%K.PH)"2`@("!I9B@A*&ES9W)A<&@H;&%B96Q;<%TI
> > M('Q\(&ES8FQA;FLH;&%B96Q;<%TI*2D@(&)R96%K.PH)"7T*"0EI9B@H=6YS
> > M:6=N960I*'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ92D@/B`R*2`@8V]N=&EN
> > M=64["@D):68H;VL@?'P@<#X]."D@>PH)"2`@("!P<FEN=&8H(B4C,#$R;'@@
> > M*"4X;&0I+"!L86)E;#U<(B4N,39S7"(L(&)S/25D:UQN(BP*"0D)("`@-3$R
> > M*BAB;&MC;W5N="MS96-T;W(I+`H)"0D@("`H8FQK8V]U;G0K<V5C=&]R*2P*
> > M"0D)("`@;&%B96PL"@D)"2`@(#$\/'-B7W!T<BT^<U]L;V=?8FQO8VM?<VEZ
> > M92D["@D)("`@(&9F;'5S:"AS=&1O=70I.PH)"7T*"2`@("!]"@E]"@EB;&MC
> > M;W5N="`K/2!N<SL*("`@('T*("`@(&EF*&9E;V8H:6YF*2D@>PH)9G!R:6YT
> > M9BAS=&1E<G(L(")%3T8@;VX@)7-<;B(L(&%R9W9;,5TI.PH)<F5T=7)N(#`[
> > M"B`@("!]"B`@("!E;'-E(&EF*&9E<G)O<BAI;F8I*2`@<&5R<F]R*&%R9W9;
> > 5,5TI.PH@("`@<F5T=7)N(#$["GT*
> > `
> > end
>
> Bob,
>
> I had to add this line before include <stdio.h> to get the program to compile:
> #define umode_t mode_t
>
> Because mode_t itself is defined as 'unsigned <something>', I took the quick liberty of doing the above without a sufficiently deeper thought on all its ramifications.
>
> There were 1601 entries printed. I extracted the base 10 number (from the parentheses), subtracted 2 (sectors) from it, and used the resulting number in device mapping code as follows:
>
>
> # This just extracts the sector that has the e2 fs signature.
> # Actual subtraction will be done later below, in the script.
>
> $ cat e2finder.log | sed -r 's/\(|\)|,//g' | field 2 > tmp
> $ cat tmp
> 8521728
> ...
> 98174976
>
>
> ---------------------------------
> #!/bin/bash
> set -u
>
> if [ -b /dev/mapper/foo ]; then
> dmsetup remove foo
> fi
>
> bogusMax=100
> cat tmp | while read x; do
> # superblock starts 2 sectors earlier
> (( x = x - 2 ))
>
> echo "Trying superblock at sector $x ..."
> if dmsetup create foo --table "0 $bogusMax linear /dev/sdb2 $x"; then
> if e2fsck -n /dev/mapper/foo &>/dev/null; then
> echo "Found superblock at sector $x ."
> else
> echo "FAILED to find superblock at sector $x ."
> fi
> dmsetup remove foo
> else
> echo "FAILED to dmsetup at sector $x"
> fi
> done
> ---------------------------------
>
>
> Unfortunately, every single superblock offset failed!
>
>
> Trying superblock at sector 8521726 ...
> FAILED to find superblock at sector 8521726 .
> ...
> Trying superblock at sector 98174974 ...
> FAILED to find superblock at sector 98174974 .
>
>
> Do I still have hope?!
If I allow e2fsck to prints its error output, this is what I get for each value of the sector:
Trying superblock at sector 8521726 ...
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Group descriptors look bad... trying backup blocks...
e2fsck: Invalid argument when using the backup blocks
e2fsck: going back to original superblock
Error reading block 3062704254 (Invalid argument). Ignore error? no
Superblock has an invalid journal (inode 8).
Clear? no
e2fsck: Illegal inode number while checking ext3 journal for /dev/mapper/foo
FAILED to find superblock at sector 8521726 .
<repeated similarly for each value superblock sector>
[toc] | [prev] | [next] | [standalone]
| From | Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-16 15:58 -0500 |
| Message-ID | <jmi14v$3fj$1@omega-3a.local> |
| In reply to | #2655 |
On 04/16/2012 12:39 PM, Harry wrote:
>
> I had to add this line before include<stdio.h> to get the program to compile:
> #define umode_t mode_t
>
> Because mode_t itself is defined as 'unsigned<something>', I took the quick liberty of doing the above without a sufficiently deeper thought on all its ramifications.
>
> There were 1601 entries printed. I extracted the base 10 number (from the parentheses), subtracted 2 (sectors) from it, and used the resulting number in device mapping code as follows:
>
>
> # This just extracts the sector that has the e2 fs signature.
> # Actual subtraction will be done later below, in the script.
>
> $ cat e2finder.log | sed -r 's/\(|\)|,//g' | field 2> tmp
> $ cat tmp
> 8521728
> ...
> 98174976
>
>
> ---------------------------------
> #!/bin/bash
> set -u
>
> if [ -b /dev/mapper/foo ]; then
> dmsetup remove foo
> fi
>
> bogusMax=100
> cat tmp | while read x; do
> # superblock starts 2 sectors earlier
> (( x = x - 2 ))
>
> echo "Trying superblock at sector $x ..."
> if dmsetup create foo --table "0 $bogusMax linear /dev/sdb2 $x"; then
> if e2fsck -n /dev/mapper/foo&>/dev/null; then
> echo "Found superblock at sector $x ."
> else
> echo "FAILED to find superblock at sector $x ."
> fi
> dmsetup remove foo
> else
> echo "FAILED to dmsetup at sector $x"
> fi
> done
> ---------------------------------
>
>
> Unfortunately, every single superblock offset failed!
>
>
> Trying superblock at sector 8521726 ...
> FAILED to find superblock at sector 8521726 .
> ...
> Trying superblock at sector 98174974 ...
> FAILED to find superblock at sector 98174974 .
First, for this program it doesn't matter how you define umode_t since
the program never uses the one macro where that name appears. Anything
that keeps the compiler happy should be fine.
I ran the program on an LVM device where I had some known file systems
and was able to do a successful e2fsck. But, ...
1. You need to make the "num_sectors" arg to dmsetup at least large enough
to contain the file system or the fsck will surely fail.
2. It is not sufficient to begin the virtual device 2 sectors before the
candidate superblock. Remember that an alternate superblock at
offset XXX still expects the file system to begin at its real starting
point, not just 2 blocks before this alternate superblock. Consider:
0x0000100400 ( 2050), label="SL6-var", bs=4k # Real SB
0x0008100000 ( 264192), label="SL6-var", bs=4k # 1st alternate
0x0018100000 ( 788480), label="SL6-var", bs=4k # 2nd alternate
All of these expect the file system to begin at sector offset 2048,
and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
the alternate SBs.
WARNING: I get a ton of group descriptor checksum errors and block bitmap
differences whenever I try to use an alternate super block, and
this also happens for a regular file system where I have not
been playing dmsetup games. Seems dangerous, but I ran e2fsck
with the "-y" option to let it fix everything, and the file
system still checked OK from the primary SB. Be careful, and
run e2fsck with the "-n" option until you're reasonably sure
you've got things set up right.
Here's what I used to set up the mapper:
Find=2050; dmsetup create foo --table \
"0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
where that "159260346" is the total number of 1K blocks in the partition,
as reported by "fdisk -l".
I hope this helps.
--
Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 23:02 -0700 |
| Message-ID | <12263514.182.1334642548574.JavaMail.geo-discussion-forums@pbag4> |
| In reply to | #2660 |
On Tuesday, April 17, 2012 2:28:07 AM UTC+5:30, Robert Nichols wrote:
> On 04/16/2012 12:39 PM, Harry wrote:
>
> >
> > I had to add this line before include<stdio.h> to get the program to compile:
> > #define umode_t mode_t
> >
> > Because mode_t itself is defined as 'unsigned<something>', I took the quick liberty of doing the above without a sufficiently deeper thought on all its ramifications.
> >
> > There were 1601 entries printed. I extracted the base 10 number (from the parentheses), subtracted 2 (sectors) from it, and used the resulting number in device mapping code as follows:
> >
> >
> > # This just extracts the sector that has the e2 fs signature.
> > # Actual subtraction will be done later below, in the script.
> >
> > $ cat e2finder.log | sed -r 's/\(|\)|,//g' | field 2> tmp
> > $ cat tmp
> > 8521728
> > ...
> > 98174976
> >
> >
> > ---------------------------------
> > #!/bin/bash
> > set -u
> >
> > if [ -b /dev/mapper/foo ]; then
> > dmsetup remove foo
> > fi
> >
> > bogusMax=100
> > cat tmp | while read x; do
> > # superblock starts 2 sectors earlier
> > (( x = x - 2 ))
> >
> > echo "Trying superblock at sector $x ..."
> > if dmsetup create foo --table "0 $bogusMax linear /dev/sdb2 $x"; then
> > if e2fsck -n /dev/mapper/foo&>/dev/null; then
> > echo "Found superblock at sector $x ."
> > else
> > echo "FAILED to find superblock at sector $x ."
> > fi
> > dmsetup remove foo
> > else
> > echo "FAILED to dmsetup at sector $x"
> > fi
> > done
> > ---------------------------------
> >
> >
> > Unfortunately, every single superblock offset failed!
> >
> >
> > Trying superblock at sector 8521726 ...
> > FAILED to find superblock at sector 8521726 .
> > ...
> > Trying superblock at sector 98174974 ...
> > FAILED to find superblock at sector 98174974 .
>
> First, for this program it doesn't matter how you define umode_t since
> the program never uses the one macro where that name appears. Anything
> that keeps the compiler happy should be fine.
>
> I ran the program on an LVM device where I had some known file systems
> and was able to do a successful e2fsck. But, ...
>
> 1. You need to make the "num_sectors" arg to dmsetup at least large enough
> to contain the file system or the fsck will surely fail.
Ok.
> 2. It is not sufficient to begin the virtual device 2 sectors before the
> candidate superblock. Remember that an alternate superblock at
> offset XXX still expects the file system to begin at its real starting
> point, not just 2 blocks before this alternate superblock. Consider:
>
> 0x0000100400 ( 2050), label="SL6-var", bs=4k # Real SB
> 0x0008100000 ( 264192), label="SL6-var", bs=4k # 1st alternate
> 0x0018100000 ( 788480), label="SL6-var", bs=4k # 2nd alternate
>
> All of these expect the file system to begin at sector offset 2048,
> and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
> the alternate SBs.
>
> WARNING: I get a ton of group descriptor checksum errors and block bitmap
> differences whenever I try to use an alternate super block, and
> this also happens for a regular file system where I have not
> been playing dmsetup games. Seems dangerous, but I ran e2fsck
> with the "-y" option to let it fix everything, and the file
> system still checked OK from the primary SB. Be careful, and
> run e2fsck with the "-n" option until you're reasonably sure
> you've got things set up right.
>
> Here's what I used to set up the mapper:
>
> Find=2050; dmsetup create foo --table \
> "0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
>
> where that "159260346" is the total number of 1K blocks in the partition,
> as reported by "fdisk -l".
Bob, would you please confirm or clarify the following:
1. My fdisk -l shows this:
$ fdisk -l
...
Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 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/sdb1 * 2048 1026047 512000 83 Linux
/dev/sdb2 1026048 156301311 77637632 8e Linux LVM
Question: Given this, I should be issuing a `e2finder /dev/sdb2`, isn't it? Based on what I understand about LVMs, /dev/sdb2 is like a device or a disk - only logical instead of physical. Would you please confirm this (or deny, with a sentence or two of explanation)?
2. Now, when I do issue `e2finder /dev/sdb2`, the list starts out as follows:
$ ./e2finder /dev/sdb2
Byte offset sector (512B)
------------ --------
0x0004100000 ( 8521728), label="", bs=4k
0x0014100000 ( 9046016), label="", bs=4k
...
Given this list and given your example just above, would the value of 'Find' for me be: 8521728?
3. In your example, does 'Find' progressively take on values 2050, 264192, 788480... or, does it remain fixed at 2050?
If it's the former, then I wonder what would be the use of printing 2nd and subsequent entries?
And if it's the latter, then why in setting up the device mapping table would you use a varying 'num_sectors' -- namely, '$((159260346*2-(Find-2) ))' -- instead of a fixed value that is 'some, fixed transformation' of the Blocks value reported by fdisk? In other words, based on this statement of yours above,
"Remember that an alternate superblock at offset XXX still
expects the file system to begin at its real starting point,
not just 2 blocks before this alternate superblock."
(which I understand and appreciate, btw), why should the dmsetup invocation be parameterized on 'Find'?
4. You say above,
"All of these expect the file system to begin at sector offset 2048,
and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
the alternate SBs."
Is the concept here that only the first entry printed is *always* the Real, and any and all subsequent ones just 'alternates' or backups of the first one? Would you please confirm this?
Further, in your example, what is the correlation between the -b argument values of 32768, 98304, ... and the corresponding SBs? The reason I ask this is: The man page of e2fsck says that '-b 32768' may be specified when the blocksize is 4k. Mine looks to be 4k, indeed. But then, shouldn't I always use 32768 instead of various numbers? Also, e2fsck suggests using 32768 only when you're relying in its own notion of things to carry out the repair. But, here, we are using a custom program (e2finder) and ought to be using the number *it* is printing out. Even in our example, I fail to find any correlation between e2finder numbers and those that you specify in e2fsck -b.
Would /greatly/ appreciate if you could clarify these few points of confusion for me.
[toc] | [prev] | [next] | [standalone]
| From | Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-17 10:58 -0500 |
| Message-ID | <jmk3vk$msn$1@omega-3a.local> |
| In reply to | #2664 |
On 04/17/2012 01:02 AM, Harry wrote:
> On Tuesday, April 17, 2012 2:28:07 AM UTC+5:30, Robert Nichols wrote:
...
>> I ran the program on an LVM device where I had some known file systems
>> and was able to do a successful e2fsck. But, ...
>>
>> 1. You need to make the "num_sectors" arg to dmsetup at least large enough
>> to contain the file system or the fsck will surely fail.
>
> Ok.
>
>> 2. It is not sufficient to begin the virtual device 2 sectors before the
>> candidate superblock. Remember that an alternate superblock at
>> offset XXX still expects the file system to begin at its real starting
>> point, not just 2 blocks before this alternate superblock. Consider:
>>
>> 0x0000100400 ( 2050), label="SL6-var", bs=4k # Real SB
>> 0x0008100000 ( 264192), label="SL6-var", bs=4k # 1st alternate
>> 0x0018100000 ( 788480), label="SL6-var", bs=4k # 2nd alternate
>>
>> All of these expect the file system to begin at sector offset 2048,
>> and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
>> the alternate SBs.
>>
>> WARNING: I get a ton of group descriptor checksum errors and block bitmap
>> differences whenever I try to use an alternate super block, and
>> this also happens for a regular file system where I have not
>> been playing dmsetup games. Seems dangerous, but I ran e2fsck
>> with the "-y" option to let it fix everything, and the file
>> system still checked OK from the primary SB. Be careful, and
>> run e2fsck with the "-n" option until you're reasonably sure
>> you've got things set up right.
>>
>> Here's what I used to set up the mapper:
>>
>> Find=2050; dmsetup create foo --table \
>> "0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
>>
>> where that "159260346" is the total number of 1K blocks in the partition,
>> as reported by "fdisk -l".
>
>
> Bob, would you please confirm or clarify the following:
>
> 1. My fdisk -l shows this:
>
> $ fdisk -l
> ...
> Disk /dev/sdb: 80.0 GB, 80026361856 bytes
> 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
> Units = sectors of 1 * 512 = 512 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/sdb1 * 2048 1026047 512000 83 Linux
> /dev/sdb2 1026048 156301311 77637632 8e Linux LVM
>
> Question: Given this, I should be issuing a `e2finder /dev/sdb2`, isn't it?
> Based on what I understand about LVMs, /dev/sdb2 is like a device or a disk -
> only logical instead of physical. Would you please confirm this (or deny, with a
> sentence or two of explanation)?
Yes, you should be running e2finder on /dev/sdb2.
At this point you aren't yet into LVMs, just an ordinary disk that has been
divided into two physical partitions. The ID on the second partition indicates
that the space therein is managed by the Logical Volume Manager. The LV
manager would, if things were working correctly, identify data structures
within that partition and set up virtual devices to access the space.
> 2. Now, when I do issue `e2finder /dev/sdb2`, the list starts out as follows:
>
> $ ./e2finder /dev/sdb2
> Byte offset sector (512B)
> ------------ --------
> 0x0004100000 ( 8521728), label="", bs=4k
> 0x0014100000 ( 9046016), label="", bs=4k
> ...
>
> Given this list and given your example just above, would the value of 'Find'
> for me be: 8521728?
Yes, that command line:
dmsetup create foo --table \
"0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
does the necessary arithmetic so that you can just plug in the sector offset
for the primary superblock.
> 3. In your example, does 'Find' progressively take on values 2050, 264192,
> 788480... or, does it remain fixed at 2050?
For all cases the file system actually starts at sector 2048 with the
primary superblock at sector 2050.
> If it's the former, then I wonder what would be the use of printing 2nd and
> subsequent entries?
Either you've got "former" and "latter" backwards, or I'm completely
confused by what you are asking.
Consider what you would see if the primary superblock were damaged. There
would be a number of alternate superblocks that you would have to identify
by looking at the repeated low-order hex digits of the byte offset, make an
educated guess about where the primary superblock would have been, and then
plug that sector offset in for "Find=xxxx".
The key is to find several potential superblocks where the low-order 6 hex
digits of the byte offset repeat, except that the first one has 0x400 added.
If you can find that pattern, that very likely identifies the first
superblock. If you don't find one with that 0x400 offset, then perhaps
that primary superblock got overwritten, and you'll have to calculate the
likely location for that primary.
> And if it's the latter, then why in setting up the device mapping table
> would you use a varying 'num_sectors' -- namely, '$((159260346*2-(Find-2) ))' --
> instead of a fixed value that is 'some, fixed transformation' of the Blocks
> value reported by fdisk? In other words, based on this statement of yours above,
>
> "Remember that an alternate superblock at offset XXX still
> expects the file system to begin at its real starting point,
> not just 2 blocks before this alternate superblock."
>
> (which I understand and appreciate, btw), why should the dmsetup invocation
> beparameterized on 'Find'?
Since I don't know the correct size, and the only constraint is that the
size must be at least large enough to contain the file system, I just
calculate the largest possible size, i.e., the number of sectors between
the starting point and the physical end of the partition.
> 4. You say above,
>
> "All of these expect the file system to begin at sector offset 2048,
> and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
> the alternate SBs."
>
> Is the concept here that only the first entry printed is *always* the Real,
> and any and all subsequent ones just 'alternates' or backups of the first
> one? Would you please confirm this?
The first entry might be the real primary superblock, but is could be just
a copy of the superblock that got written to some random location for
reasons unknown. I've got disk partitions that have been used for several
test installations, and there are copies of what look like valid superblocks
scattered all over.
> Further, in your example, what is the correlation between the -b argument
> values of 32768, 98304, ... and the corresponding SBs? The reason I ask this
> is: The man page of e2fsck says that '-b 32768' may be specified when the
> blocksize is 4k. Mine looks to be 4k, indeed. But then, shouldn't I always
> use 32768 instead of various numbers? Also, e2fsck suggests using 32768 only
> when you're relying in its own notion of things to carry out the repair. But,
> here, we are using a custom program (e2finder) and ought to be using the
> number *it* is printing out. Even in our example, I fail to find any
> correlation between e2finder numbers and those that you specify in e2fsck
> -b.
Recognize that the argument to "-b" represents 4k-sized blocks. So,
0x0000100400 # Real SB
- 0x400 # byte offset of real SB
------------
0x0000100000 # actual start of file system
0x0008100000 # 1st alternate
-0x0000100000 # start of file system
------------
0x0008000000 # byte offset of 1st alternate
Divide that number by the block size (4k = 0x1000) and you get
0x8000, or 32768 decimal.
For the 2nd alternate at 0x0018100000, you get a byte offset of 0x18000000,
or 98304 blocks of 4k.
--
Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-18 21:53 -0700 |
| Message-ID | <30044415.1505.1334811217783.JavaMail.geo-discussion-forums@pbvk8> |
| In reply to | #2670 |
On Tuesday, April 17, 2012 9:28:44 PM UTC+5:30, Robert Nichols wrote:
> On 04/17/2012 01:02 AM, Harry wrote:
> > On Tuesday, April 17, 2012 2:28:07 AM UTC+5:30, Robert Nichols wrote:
> ...
> >> I ran the program on an LVM device where I had some known file systems
> >> and was able to do a successful e2fsck. But, ...
> >>
> >> 1. You need to make the "num_sectors" arg to dmsetup at least large enough
> >> to contain the file system or the fsck will surely fail.
> >
> > Ok.
> >
> >> 2. It is not sufficient to begin the virtual device 2 sectors before the
> >> candidate superblock. Remember that an alternate superblock at
> >> offset XXX still expects the file system to begin at its real starting
> >> point, not just 2 blocks before this alternate superblock. Consider:
> >>
> >> 0x0000100400 ( 2050), label="SL6-var", bs=4k # Real SB
> >> 0x0008100000 ( 264192), label="SL6-var", bs=4k # 1st alternate
> >> 0x0018100000 ( 788480), label="SL6-var", bs=4k # 2nd alternate
> >>
> >> All of these expect the file system to begin at sector offset 2048,
> >> and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
> >> the alternate SBs.
> >>
> >> WARNING: I get a ton of group descriptor checksum errors and block bitmap
> >> differences whenever I try to use an alternate super block, and
> >> this also happens for a regular file system where I have not
> >> been playing dmsetup games. Seems dangerous, but I ran e2fsck
> >> with the "-y" option to let it fix everything, and the file
> >> system still checked OK from the primary SB. Be careful, and
> >> run e2fsck with the "-n" option until you're reasonably sure
> >> you've got things set up right.
> >>
> >> Here's what I used to set up the mapper:
> >>
> >> Find=2050; dmsetup create foo --table \
> >> "0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
> >>
> >> where that "159260346" is the total number of 1K blocks in the partition,
> >> as reported by "fdisk -l".
> >
> >
> > Bob, would you please confirm or clarify the following:
> >
> > 1. My fdisk -l shows this:
> >
> > $ fdisk -l
> > ...
> > Disk /dev/sdb: 80.0 GB, 80026361856 bytes
> > 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
> > Units = sectors of 1 * 512 = 512 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/sdb1 * 2048 1026047 512000 83 Linux
> > /dev/sdb2 1026048 156301311 77637632 8e Linux LVM
> >
> > Question: Given this, I should be issuing a `e2finder /dev/sdb2`, isn't it?
> > Based on what I understand about LVMs, /dev/sdb2 is like a device or a disk -
> > only logical instead of physical. Would you please confirm this (or deny, with a
> > sentence or two of explanation)?
>
> Yes, you should be running e2finder on /dev/sdb2.
>
> At this point you aren't yet into LVMs, just an ordinary disk that has been
> divided into two physical partitions. The ID on the second partition indicates
> that the space therein is managed by the Logical Volume Manager. The LV
> manager would, if things were working correctly, identify data structures
> within that partition and set up virtual devices to access the space.
>
> > 2. Now, when I do issue `e2finder /dev/sdb2`, the list starts out as follows:
> >
> > $ ./e2finder /dev/sdb2
> > Byte offset sector (512B)
> > ------------ --------
> > 0x0004100000 ( 8521728), label="", bs=4k
> > 0x0014100000 ( 9046016), label="", bs=4k
> > ...
> >
> > Given this list and given your example just above, would the value of 'Find'
> > for me be: 8521728?
>
> Yes, that command line:
>
> dmsetup create foo --table \
> "0 $((159260346*2-(Find-2) )) linear /dev/sda12 $((Find-2))"
>
> does the necessary arithmetic so that you can just plug in the sector offset
> for the primary superblock.
>
> > 3. In your example, does 'Find' progressively take on values 2050, 264192,
> > 788480... or, does it remain fixed at 2050?
>
> For all cases the file system actually starts at sector 2048 with the
> primary superblock at sector 2050.
>
> > If it's the former, then I wonder what would be the use of printing 2nd and
> > subsequent entries?
>
> Either you've got "former" and "latter" backwards, or I'm completely
> confused by what you are asking.
>
> Consider what you would see if the primary superblock were damaged. There
> would be a number of alternate superblocks that you would have to identify
> by looking at the repeated low-order hex digits of the byte offset, make an
> educated guess about where the primary superblock would have been, and then
> plug that sector offset in for "Find=xxxx".
>
> The key is to find several potential superblocks where the low-order 6 hex
> digits of the byte offset repeat, except that the first one has 0x400 added.
> If you can find that pattern, that very likely identifies the first
> superblock. If you don't find one with that 0x400 offset, then perhaps
> that primary superblock got overwritten, and you'll have to calculate the
> likely location for that primary.
>
> > And if it's the latter, then why in setting up the device mapping table
> > would you use a varying 'num_sectors' -- namely, '$((159260346*2-(Find-2) ))' --
> > instead of a fixed value that is 'some, fixed transformation' of the Blocks
> > value reported by fdisk? In other words, based on this statement of yours above,
> >
> > "Remember that an alternate superblock at offset XXX still
> > expects the file system to begin at its real starting point,
> > not just 2 blocks before this alternate superblock."
> >
> > (which I understand and appreciate, btw), why should the dmsetup invocation
> > beparameterized on 'Find'?
>
> Since I don't know the correct size, and the only constraint is that the
> size must be at least large enough to contain the file system, I just
> calculate the largest possible size, i.e., the number of sectors between
> the starting point and the physical end of the partition.
>
> > 4. You say above,
> >
> > "All of these expect the file system to begin at sector offset 2048,
> > and would need you to run "e2fsck -b 32768" or "e2fsck -b 98304" for
> > the alternate SBs."
> >
> > Is the concept here that only the first entry printed is *always* the Real,
> > and any and all subsequent ones just 'alternates' or backups of the first
> > one? Would you please confirm this?
>
> The first entry might be the real primary superblock, but is could be just
> a copy of the superblock that got written to some random location for
> reasons unknown. I've got disk partitions that have been used for several
> test installations, and there are copies of what look like valid superblocks
> scattered all over.
>
> > Further, in your example, what is the correlation between the -b argument
> > values of 32768, 98304, ... and the corresponding SBs? The reason I ask this
> > is: The man page of e2fsck says that '-b 32768' may be specified when the
> > blocksize is 4k. Mine looks to be 4k, indeed. But then, shouldn't I always
> > use 32768 instead of various numbers? Also, e2fsck suggests using 32768 only
> > when you're relying in its own notion of things to carry out the repair. But,
> > here, we are using a custom program (e2finder) and ought to be using the
> > number *it* is printing out. Even in our example, I fail to find any
> > correlation between e2finder numbers and those that you specify in e2fsck
> > -b.
>
> Recognize that the argument to "-b" represents 4k-sized blocks. So,
>
> 0x0000100400 # Real SB
> - 0x400 # byte offset of real SB
> ------------
> 0x0000100000 # actual start of file system
>
> 0x0008100000 # 1st alternate
> -0x0000100000 # start of file system
> ------------
> 0x0008000000 # byte offset of 1st alternate
>
> Divide that number by the block size (4k = 0x1000) and you get
> 0x8000, or 32768 decimal.
>
> For the 2nd alternate at 0x0018100000, you get a byte offset of 0x18000000,
> or 98304 blocks of 4k.
>
> --
> Bob Nichols AT comcast.net I am "RNichols42"
Bob, I understood the 'gist' of what you said above, but not every detail. It is probably because I'm still quite tense. A revisit to your post later may perhaps find me in a happier and more receptive state than I am now to understand all that detail.
So, what I did was, I simply pasted your parameterized dmsetup comand relying on the strength of fact that it would cause no persistent changes. In a nutshell, it did not work. I got these messages.
Trying superblock at sector 8521728 ...
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block when using the backup blocks
e2fsck: going back to original superblock
Error reading block 3062704254 (Invalid argument). Ignore error? no
Superblock has an invalid journal (inode 8).
Clear? no
e2fsck: Illegal inode number while checking ext3 journal for /dev/mapper/foo
FAILED to find superblock at sector 8521726 .
Trying superblock at sector 9046016 ...
...
Meanwhile, frustrated and desperate, I kept googling and managed to run into this article:
http://www.microdevsys.com/WordPress/2011/09/19/linux-lvm-recovering-a-lost-volume/
Good news and Bad news:
1. The good news is that I *was* able to get the various LVM commands to succeed. I think, vgcfgrestore, may have been the key thing. I don't pretend that I understand everything about it or why it worked, but, yes, it did work. Here's what I did:
a) I noticed that in the image of the partition, the string /dev/sda2 was written. Even though the LVM backup file said
device = "/dev/sda2" # Hint only
, I decided to be a little superstitious and switched the data cables in my system once again so that the messed up disk once again became /dev/sda.
$ fdisk -l
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 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/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 156301311 77637632 8e Linux LVM
b) Restored the /etc/lvm directory.
$ mv /etc/lvm.off /etc/lvm
$ ls -l /etc/lvm/backup/
total 4
-rw-------. 1 root root 1456 Apr 19 09:16 vg_XYZ
c) I then issued lvm vgcfgrestore and -- wow, unlike for the author of the above article -- the command worked for me!
$ lvm vgcfgrestore vg_XYZ
Restored volume group vg_XYZ
$ lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_XYZ" using metadata type lvm2
$ lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_XYZ" using metadata type lvm2
$ lvm pvscan
PV /dev/sda2 VG vg_XYZ lvm2 [74.03 GiB / 0 free]
Total: 1 [74.03 GiB] / in use: 1 [74.03 GiB] / in no VG: 0 [0 ]
$ lvm vgchange -a y vg_XYZ
2 logical volume(s) in volume group "vg_XYZ" now active
$ lvm pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 vg_XYZ lvm2 a-- 74.03g 0
$ lvm vgs
VG #PV #LV #SN Attr VSize VFree
vg_XYZ 1 2 0 wz--n- 74.03g 0
$ lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_root vg_XYZ -wi-a- 70.09g
lv_swap vg_XYZ -wi-a- 3.94g
$ mount /dev/vg_XYZ/lv_root /mnt/x/
mount: you must specify the filesystem type
$ mount -vvvvvv /dev/vg_XYZ/lv_root /mnt/x
mount: fstab path: "/etc/fstab"
mount: mtab path: "/etc/mtab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: UID: 0
mount: eUID: 0
mount: spec: "/dev/mapper/vg_XYZ-lv_root"
mount: node: "/mnt/x"
mount: types: "(null)"
mount: opts: "(null)"
mount: you didn't specify a filesystem type for /dev/mapper/vg_XYZ-lv_root
I will try all types mentioned in /etc/filesystems or /proc/filesystems
Trying ext4
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "ext4", mountflags: -1058209792, data: (null)
Trying ext3
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "ext3", mountflags: -1058209792, data: (null)
Trying ext2
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "ext2", mountflags: -1058209792, data: (null)
Trying iso9660
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "iso9660", mountflags: -1058209792, data: (null)
Trying vfat
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "vfat", mountflags: -1058209792, data: (null)
Trying hfs
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "hfs", mountflags: -1058209792, data: (null)
Trying hfsplus
mount: mount(2) syscall: source: "/dev/mapper/vg_XYZ-lv_root", target: "/mnt/x", filesystemtype: "hfsplus", mountflags: -1058209792, data: (null)
mount: you must specify the filesystem type
2. The bad news is that, as you can see above, I don't know what to do now to get the mount to succeed. Because the article-author's situation isn't exactly the same as mine, and also because I don't understand either his or my situation fully, I don't feel safe in issuing any more commands (pvcreate, vgextend, pvmove, pvreduce, pvremove) that he mentions after the 'mount failure' point in his article.
So, would greatly appreciate if you or someone could kindly tell me what to do *now* to get the partitions to mount (esp, the lv_root partition), so that I can back it up the first thing. Once a backup is made, I can play with this LVM stuff and learn and explore it to my heart's content, read all the posts at a slower and more relaxed pace.
Many, many thanks to all those who have taken interest in this thread, have stood by my side all this time, and have been very patient with my newbie questions.
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-19 16:45 +0000 |
| Message-ID | <jmpffu$v57$1@dont-email.me> |
| In reply to | #2679 |
Harry wrote: > > /dev/sda1 * 2048 1026047 512000 83 Linux You will want to run fsck on this partition separately. You've already been able to get it to mount if I recall. It used to be /boot so it might not be of interest to you. Easily rebuilt. > $ lvm vgs > VG #PV #LV #SN Attr VSize VFree > vg_XYZ 1 2 0 wz--n- 74.03g 0 > > $ lvm lvs > LV VG Attr LSize Origin Snap% Move Log Copy% Convert > lv_root vg_XYZ -wi-a- 70.09g > lv_swap vg_XYZ -wi-a- 3.94g > ... > So, would greatly appreciate if you or someone could kindly tell me > what to do *now* to get the partitions to mount The easy one first - Based on the name "lv_swap" don't bother with that one. It will contain paged out virtual memory pages in a format that is not useful once the system has shut down. For "lv_root" do you remember it's format. I'm in th emiddle of similar conversations on group and off and I don't remember which one used ext3 and which one used ext4. With the volume group still active so "vgdisplay -v" shows its logical volumes and/or so lvs shows them as above do - fsck -t ext3 /dev/vg_XYZ/lv_root or maybe fsck -o full -t ext3 /dev/vg_XYZ/lv_root It will tell you how much data is intact. Might be all of it. After fsck runs clean (might take several passes) you should be able to mount it by specifying its format - mount -t ext3 /dev/vg_XYZ/lv_root /mnt/root Then you'll be able to see files with names you expect and/or files under /mnt/root/lost+found who names are based on the inode numbers. With a small number of files in lost+found it's practical to start guessing. With a large number not so much.
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-19 18:34 -0700 |
| Message-ID | <11159000.192.1334885643540.JavaMail.geo-discussion-forums@pbcgs4> |
| In reply to | #2683 |
On Thursday, April 19, 2012 10:15:50 PM UTC+5:30, Doug Freyburger wrote: > Harry wrote: > > > > /dev/sda1 * 2048 1026047 512000 83 Linux > > You will want to run fsck on this partition separately. You've already > been able to get it to mount if I recall. It used to be /boot so it > might not be of interest to you. Easily rebuilt. I completely did not realize that! (Ran the check, it is clean.) Thanks for reminding. > For "lv_root" do you remember it's format. I'm in th emiddle of similar > conversations on group and off and I don't remember which one used ext3 > and which one used ext4. With the volume group still active so > "vgdisplay -v" shows its logical volumes and/or so lvs shows them as > above do - > > fsck -t ext3 /dev/vg_XYZ/lv_root It is ext4. I noticed that fsck called e2fsck internally and didn't require the -t ext4 argument. I tried both with and without the argument, same result: clean. > or maybe > > fsck -o full -t ext3 /dev/vg_XYZ/lv_root > > It will tell you how much data is intact. Might be all of it. After > fsck runs clean (might take several passes) you should be able to mount > it by specifying its format - I'm using the fsck that comes packaged with util-linux-2.20.1-2.2.fc16.i686 on Fedora 16. It doesn't have the -o option. > mount -t ext3 /dev/vg_XYZ/lv_root /mnt/root > Then you'll be able to see files with names you expect and/or files > under /mnt/root/lost+found who names are based on the inode numbers. > With a small number of files in lost+found it's practical to start > guessing. With a large number not so much. Didn't see any under /mnt/lost+found - Thank God! I'm assuming this means all files under lv_root got recovered successfully. Thanks, Doug.
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-20 17:19 +0000 |
| Message-ID | <jms5ri$ebl$1@dont-email.me> |
| In reply to | #2685 |
Harry wrote: > Doug Freyburger wrote: >> Harry wrote: >> > >> > /dev/sda1 * 2048 1026047 512000 83 Linux >> >>It used to be /boot so it >> might not be of interest to you. Easily rebuilt. > > Thanks for reminding. Automatically built data. >> or maybe >> fsck -o full -t ext3 /dev/vg_XYZ/lv_root > > I'm using the fsck that comes packaged with util-linux-2.20.1-2.2.fc16.i686 on Fedora 16. It doesn't have the -o option. It is from one of the many other systems I work on then. Probably the VXFS version. >> mount -t ext3 /dev/vg_XYZ/lv_root /mnt/root > > Didn't see any under /mnt/lost+found - Thank God! > I'm assuming this means all files under lv_root got recovered successfully. Yes that is what it means. Recovery project complete. Backup project begins.
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-21 20:37 -0700 |
| Message-ID | <17585240.301.1335065868039.JavaMail.geo-discussion-forums@pbckz3> |
| In reply to | #2687 |
On Friday, April 20, 2012 10:49:46 PM UTC+5:30, Doug Freyburger wrote: > Harry wrote: > > Doug Freyburger wrote: > >> Harry wrote: > >> > > >> > /dev/sda1 * 2048 1026047 512000 83 Linux > >> > >>It used to be /boot so it > >> might not be of interest to you. Easily rebuilt. > > > > Thanks for reminding. > > Automatically built data. Didn't understand. > >> or maybe > >> fsck -o full -t ext3 /dev/vg_XYZ/lv_root > > > > I'm using the fsck that comes packaged with util-linux-2.20.1-2.2.fc16.i686 on Fedora 16. It doesn't have the -o option. > > It is from one of the many other systems I work on then. Probably the > VXFS version. Ok, will just ignore it then. > >> mount -t ext3 /dev/vg_XYZ/lv_root /mnt/root > > > > Didn't see any under /mnt/lost+found - Thank God! > > I'm assuming this means all files under lv_root got recovered successfully. > > Yes that is what it means. Recovery project complete. Backup project > begins. I'll post another question shortly to invite some tips and best practices on the organization of partitions and their backup.
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-25 16:01 +0000 |
| Message-ID | <jn975m$umn$1@dont-email.me> |
| In reply to | #2688 |
Harry wrote: > Doug Freyburger wrote: >> Harry wrote: >> > Doug Freyburger wrote: >> >> Harry wrote: > >> >> > /dev/sda1 * 2048 1026047 512000 83 Linux > >> >>It used to be /boot so it >> >> might not be of interest to you. Easily rebuilt. > >> > Thanks for reminding. > >> Automatically built data. > > Didn't understand. Checking back to see if this point ended up clear. You wanted to recover user data from that drive. Partition sda1 contains /boot that does not contain any user data. That's why I said to ignore it for your purposes. The mount point /boot contains new and old versions of the kernel and other boot support data. Its contents are automatically generated at system build time and later when kernel upgrades/patches are applied. It's very interesting when your purpose is recovering a system to bootable status. Since your purpose was not to recover the system to bootable status you could ignore it. A matter of context, what you wanted to do. Given all of the other discussion I suspect its contents are intact and you would have been able to render the system bootable at some point using its contents. You have a different boot disk so that was not your goal.
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-28 16:32 -0700 |
| Message-ID | <30090069.673.1335655972526.JavaMail.geo-discussion-forums@pbgg7> |
| In reply to | #2699 |
On Wednesday, April 25, 2012 9:31:58 PM UTC+5:30, Doug Freyburger wrote: > Harry wrote: > > Doug Freyburger wrote: > >> Harry wrote: > >> > Doug Freyburger wrote: > >> >> Harry wrote: > > > >> >> > /dev/sda1 * 2048 1026047 512000 83 Linux > > > >> >>It used to be /boot so it > >> >> might not be of interest to you. Easily rebuilt. > > > >> > Thanks for reminding. > > > >> Automatically built data. > > > > Didn't understand. > > Checking back to see if this point ended up clear. You wanted to > recover user data from that drive. Partition sda1 contains /boot that > does not contain any user data. That's why I said to ignore it for your > purposes. Yes, I had understood this part fine. > The mount point /boot contains new and old versions of the kernel and > other boot support data. Its contents are automatically generated at > system build time and later when kernel upgrades/patches are applied. > It's very interesting when your purpose is recovering a system to > bootable status. Since your purpose was not to recover the system to > bootable status you could ignore it. A matter of context, what you > wanted to do. In your last post, I was not sure what you meant by 'data' in "Automatically built data". Now, I understand. > Given all of the other discussion I suspect its contents are intact and > you would have been able to render the system bootable at some point > using its contents. You have a different boot disk so that was not your > goal. Yes, that's correct. Thanks a ton, Doug, for being patient with my questions!
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-16 19:15 +0000 |
| Message-ID | <jmhr52$d2$1@dont-email.me> |
| In reply to | #2632 |
Robert Nichols wrote: > Harry wrote: >> $ pvck -vv /dev/sdb2 > >> Found label on /dev/sdb2, sector 1, type=LVM2 001 >> Found text metadata area: offset=4096, size=1044480 >> Found LVM2 metadata record at offset=1006080, size=42496, >> offset2=0 size2=0 >> Found LVM2 metadata record at offset=991232, size=14848, offset2=0 >> size2=0 > > That is all perfectly normal. It's hard to understand why it's not working. > Try setting aside the /etc/lvm directory (rename it to /etc/xxlvm) to force > the system to work only with the physical devices and not rely on previously > cached data. Then see what 'pvscan', 'vgscan', and 'lvscan' can find. The > vgscan should repopulate the /etc/lvm directory with good data. If it was the beginning of /dev/sdb2 that was overwritten not the beginning of the disk then the first LVM label was trashed. It's a huge if but maybe that's what happened. I see in the man page for the Red Har version of "pvck" that it supports "--labelsector sector". Above is a list of those sectors. They should act something like the alternative super blocks discussed earlier when we were thinking about an ext4 filesystem. I don't see that switch in the man page for any of the other related commands. Sigh. Have you tried "lvscan" in the hopes that it uses those alternate labels?
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.os.linux.setup
csiph-web