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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-12 10:55 -0700 |
| Message-ID | <2d1e15ef-3c28-4565-84cc-90a85e41cadb@vy9g2000pbc.googlegroups.com> |
| In reply to | #2595 |
On Apr 12, 10:43 pm, Richard Kettlewell <r...@greenend.org.uk> wrote: > Doug Freyburger <dfrey...@yahoo.com> writes: > > Harry wrote: > >> ================= > >> Details of what I did: > >> ================= > > >> Using the `dd` command, I was hoping that I would be able to copy over > >> the first 446 bytes from Disk B (250GB) to Disk A (80GB), in order to > >> make Disk A bootable just like Disk B. I issued the command: > > >> dd if=/dev/sdb of=/dev/sda bs=446 count=1 > > >> But when I could not boot up from `sda`, I rebooted from `sdb` to see > >> what was going on. To my horror, `sda` was being reported to have a > >> bad superblock, now. > > > Okay, let's step back and think about what you did compared to what you > > have been trying to do since. > > > What you did - Take the partition table of disk sdb and write it to the > > partition table of disk sda. > > That's not correct. 446 is precisely the value you use to avoid > modifying the partition table of the target. Since the partition table > quoted is consistent with an 80GB disk and not a 250GB disk, it's a safe > bet that the partition table on the target wasn't modified. > > --http://www.greenend.org.uk/rjk/ I read from a Wikipedia entry on disk partitioning that the first 446 bytes of the MBR is 'pure code' -- i.e. no data. Which is why I ventured in the first place to boldly attempt -- without a backup of the target MBR -- the copying of the 446-byte MBR code from the former (250 GB) sdb to the former (80G) sda. But something went wrong, and I still don't understand it. Right now, my priority is to get my data back. Immediately after this is done, I'd also like to what the heck I did.
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-12 18:07 +0000 |
| Message-ID | <jm75l1$q5n$1@dont-email.me> |
| In reply to | #2595 |
Richard Kettlewell wrote: > Doug Freyburger <dfreybur@yahoo.com> writes: >> Harry wrote: > >>> dd if=/dev/sdb of=/dev/sda bs=446 count=1 > >> What you did - Take the partition table of disk sdb and write it to the >> partition table of disk sda. > > That's not correct. 446 is precisely the value you use to avoid > modifying the partition table of the target. Since the partition table > quoted is consistent with an 80GB disk and not a 250GB disk, it's a safe > bet that the partition table on the target wasn't modified. I wonder if "dd" has an underlying block size or if it starts with an uninitialized block. I suspect it did not read the first sector, changethe first 446 bytes in the buffer, then write the first sector back out again. I fear it wrote 512 byes of data (maybe more in 512 bye increments) where the first 446 bytes were good and the rest was nonsense. It would explain the missing partition data. I'll reread the thread then glance at that forum.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2012-04-12 19:20 +0100 |
| Message-ID | <87bomw7qy1.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #2599 |
Doug Freyburger <dfreybur@yahoo.com> writes: > I wonder if "dd" has an underlying block size or if it starts with an > uninitialized block. > > I suspect it did not read the first sector, changethe first 446 bytes > in the buffer, then write the first sector back out again. I fear it > wrote 512 byes of data (maybe more in 512 bye increments) where the > first 446 bytes were good and the rest was nonsense. It would explain > the missing partition data. > > I'll reread the thread then glance at that forum. The partition table is fine. You're chasing a red herring. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2012-04-12 19:11 +0000 |
| Message-ID | <PNFhr.60774$M%7.5669@newsfe10.iad> |
| In reply to | #2602 |
On 2012-04-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > Doug Freyburger <dfreybur@yahoo.com> writes: >> I wonder if "dd" has an underlying block size or if it starts with an >> uninitialized block. >> >> I suspect it did not read the first sector, changethe first 446 bytes >> in the buffer, then write the first sector back out again. I fear it >> wrote 512 byes of data (maybe more in 512 bye increments) where the >> first 446 bytes were good and the rest was nonsense. It would explain >> the missing partition data. >> >> I'll reread the thread then glance at that forum. > > The partition table is fine. You're chasing a red herring. You know that how? which piece of data that he reports do you base this on? and How does your theory explain the other symptoms. Ie, if he is chasing a red herring, what the real trail he should be following? >
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2012-04-12 20:39 +0100 |
| Message-ID | <87k41k20za.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #2610 |
unruh <unruh@invalid.ca> writes: > Richard Kettlewell <rjk@greenend.org.uk> wrote: >> The partition table is fine. You're chasing a red herring. > You know that how? which piece of data that he reports do you base > this on? The consistency between the physical disk, the partition table and the lvm backup data. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-13 16:50 +0000 |
| Message-ID | <jm9lhh$mjr$1@dont-email.me> |
| In reply to | #2614 |
Richard Kettlewell wrote: > unruh <unruh@invalid.ca> writes: >> Richard Kettlewell <rjk@greenend.org.uk> wrote: > >>> The partition table is fine. You're chasing a red herring. > >> You know that how? which piece of data that he reports do you base >> this on? > > The consistency between the physical disk, the partition table and the > lvm backup data. The problem is if only the boot portion of the MBR were written to, then why won't the volume group on the second partition activate? It remains the most like suspect based in the "vgimport -vvv" he posted but where our our guarantees? According to the "fdisk -l" output there is a 250 MB parition in Linux format marked bootable. Clearly /boot. It does not fsck nor does it mount as /mnt/boot. if only the boot code of the MBR were written that partition would fsck and mount. According to the "vgimport -vvv" output posted here and the "pvscan" output posted on the forum there is a 79 GB partition in Linux LVM format that "should" contain the volume group vg_XYZ. Neither vgimport nor vgscan works. Both of these results tell me that the partition table probably was trashed. We started with a base assumption that the partition table was valid and worked based on that premise. No progress was made using tools suggested by the partition table contents. To me that says the partition table is in fact bad. But how much else was written to? Doing "fsck /dev/sdb1" did not show a filesystem there. Either more was overwritten than the partition table or there was no filesystem there on the original. I go back to my suggstion of looking for contents. Does fdisk work on loopback files? I've never tried that. I would rather do dd to a new device. Put a single partiton for the whole drive. Look for a filesystem with fsck (done) and a volume group with vgscan. If it finds one look at the size - A partition tha'ts too big will show data smaller than the whole drive. Narrow down the size by halfing. A failure means the half was too small, success means on target or too big. The problem with the method is what if there was a swap partition at the beginning. Then we don't know where to start other than the beginning. Make a partition 1 cyclinder then the rest in the second one. Try that. Keep cycling 1 more cylider at a time. Way too much work unless that could be automated. Can PartitionMagic do something like that?
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-13 21:24 -0700 |
| Message-ID | <e5f364e8-ecb3-4651-86e9-f0ac9f97eb33@a8g2000pbe.googlegroups.com> |
| In reply to | #2623 |
On Apr 13, 9:50 pm, Doug Freyburger <dfrey...@yahoo.com> wrote:
> Richard Kettlewell wrote:
> > unruh <un...@invalid.ca> writes:
> >> Richard Kettlewell <r...@greenend.org.uk> wrote:
>
> >>> The partition table is fine. You're chasing a red herring.
>
> >> You know that how? which piece of data that he reports do you base
> >> this on?
>
> > The consistency between the physical disk, the partition table and the
> > lvm backup data.
>
> The problem is if only the boot portion of the MBR were written to, then
> why won't the volume group on the second partition activate? It remains
> the most like suspect based in the "vgimport -vvv" he posted but where
> our our guarantees?
>
> According to the "fdisk -l" output there is a 250 MB parition in Linux
> format marked bootable. Clearly /boot. It does not fsck nor does it
> mount as /mnt/boot. if only the boot code of the MBR were written that
> partition would fsck and mount.
No, actually, I /can/ mount the boot partition sdb1.
$ fdisk -l
<snip>
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
$ mount /dev/sdb1 /mnt/x
$ ls /mnt/x
config-3.2.5-3.fc16.i686.PAE
initramfs-3.2.9-1.fc16.i686.PAE.img
config-3.2.9-1.fc16.i686.PAE
initramfs-3.2.9-2.fc16.i686.PAE.img
config-3.2.9-2.fc16.i686.PAE initrd-
plymouth.img
config.mk-compat-wireless-3.3-rc1-2-3.2.5-3.fc16.i686.PAE lost+found
config.mk-compat-wireless-3.3-rc1-2-3.2.9-1.fc16.i686.PAE
System.map-3.2.5-3.fc16.i686.PAE
config.mk-compat-wireless-3.3-rc1-2-3.2.9-2.fc16.i686.PAE
System.map-3.2.9-1.fc16.i686.PAE
efi
System.map-3.2.9-2.fc16.i686.PAE
grub
vmlinuz-3.2.5-3.fc16.i686.PAE
grub2
vmlinuz-3.2.9-1.fc16.i686.PAE
initramfs-3.2.5-3.fc16.i686.PAE.img
vmlinuz-3.2.9-2.fc16.i686.PAE
$ df -h /mnt/x
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 485M 85M 376M 19% /mnt/x
> According to the "vgimport -vvv" output posted here and the "pvscan"
> output posted on the forum there is a 79 GB partition in Linux LVM
> format that "should" contain the volume group vg_XYZ. Neither vgimport
> nor vgscan works.
>
> Both of these results tell me that the partition table probably was
> trashed. We started with a base assumption that the partition table was
> valid and worked based on that premise. No progress was made using
> tools suggested by the partition table contents. To me that says the
> partition table is in fact bad. But how much else was written to?
>
> Doing "fsck /dev/sdb1" did not show a filesystem there. Either more was
> overwritten than the partition table or there was no filesystem there on
> the original.
Here's what fsck is showing for sdb1.
$ umount /mnt/x
$ fsck -n /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.41.14 (22-Dec-2010)
/dev/sdb1: clean, 248/128016 files, 102228/512000 blocks
> I go back to my suggstion of looking for contents. Does fdisk work on
> loopback files? I've never tried that. I would rather do dd to a new
> device. Put a single partiton for the whole drive. Look for a
> filesystem with fsck (done) and a volume group with vgscan. If it finds
> one look at the size - A partition tha'ts too big will show data smaller
> than the whole drive. Narrow down the size by halfing. A failure means
> the half was too small, success means on target or too big.
Richard, I'd like to try what you're suggesting... but, I'm afraid,
I'm not following you. Would you elaborate just a little bit more. I
have a cloned image of the bad sdb. Now what do I do with this image
using dd? So far, I am able to fdisk bad.img as follows:
$ losetup /dev/loop1 bad.img
$ # If /dev/loop1 is not specified on the next line,
$ # then fdisk can't see it.
$ fdisk -l /dev/loop1
Disk /dev/loop1: 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/loop1p1 * 2048 1026047 512000 83 Linux
/dev/loop1p2 1026048 156301311 77637632 8e Linux LVM
vgscan reports no volumes.
$ vgscan
Reading all physical volumes. This may take a while...
No volume groups found
Now, what to do next?
> The problem with the method is what if there was a swap partition at the
> beginning. Then we don't know where to start other than the beginning.
> Make a partition 1 cyclinder then the rest in the second one. Try that.
> Keep cycling 1 more cylider at a time. Way too much work unless that
> could be automated. Can PartitionMagic do something like that?
From the volume group backup file which I have shared over
superuser.com, it seems there is indeed a swap partition in the
beginning. However, as I said above, I'm not fully understanding the
method you're suggesting. Could you spell out the steps along with
names of the programs to use in those steps and possibly some other
details, as I'm not a partitioning expert at all?
[toc] | [prev] | [next] | [standalone]
| From | Doug Freyburger <dfreybur@yahoo.com> |
|---|---|
| Date | 2012-04-16 19:04 +0000 |
| Message-ID | <jmhqfi$rji$1@dont-email.me> |
| In reply to | #2626 |
Harry wrote: > Doug Freyburger <dfrey...@yahoo.com> wrote: > >> According to the "fdisk -l" output there is a 250 MB parition in Linux >> format marked bootable. Clearly /boot. It does not fsck nor does it >> mount as /mnt/boot. if only the boot code of the MBR were written that >> partition would fsck and mount. > > No, actually, I /can/ mount the boot partition sdb1. > ... > $ ls /mnt/x > config-3.2.5-3.fc16.i686.PAE > initramfs-3.2.9-1.fc16.i686.PAE.img > config-3.2.9-1.fc16.i686.PAE > initramfs-3.2.9-2.fc16.i686.PAE.img > config-3.2.9-2.fc16.i686.PAE initrd- > plymouth.img > config.mk-compat-wireless-3.3-rc1-2-3.2.5-3.fc16.i686.PAE lost+found > config.mk-compat-wireless-3.3-rc1-2-3.2.9-1.fc16.i686.PAE > System.map-3.2.5-3.fc16.i686.PAE > config.mk-compat-wireless-3.3-rc1-2-3.2.9-2.fc16.i686.PAE > System.map-3.2.9-1.fc16.i686.PAE > efi > System.map-3.2.9-2.fc16.i686.PAE > grub > vmlinuz-3.2.5-3.fc16.i686.PAE > grub2 > vmlinuz-3.2.9-1.fc16.i686.PAE > initramfs-3.2.5-3.fc16.i686.PAE.img > vmlinuz-3.2.9-2.fc16.i686.PAE That's clearly a /boot mount point. Conclusive evidence the partition table was not trashed. No way did a "dd" copy all 250 MB. >> According to the "vgimport -vvv" output posted here and the "pvscan" >> output posted on the forum there is a 79 GB partition in Linux LVM >> format that "should" contain the volume group vg_XYZ. Neither vgimport >> nor vgscan works. > I > have a cloned image of the bad sdb. Now what do I do with this image > using dd? So far, I am able to fdisk bad.img as follows: > > $ losetup /dev/loop1 bad.img > > $ # If /dev/loop1 is not specified on the next line, > $ # then fdisk can't see it. > $ fdisk -l /dev/loop1 > > Disk /dev/loop1: 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/loop1p1 * 2048 1026047 512000 83 Linux Definitely /boot > /dev/loop1p2 1026048 156301311 77637632 8e Linux LVM And therefore this has to be what I would normally call VolGroup00 on he many Red Hat systems I have built. In your posts you have called in vg_XYZ. > vgscan reports no volumes. > > $ vgscan > Reading all physical volumes. This may take a while... > No volume groups found > > Now, what to do next? That's the puzzle we have gotten to. It's nowhere near where you did the dd. Is there any chance the dd actually had the partition in its of clause? "of=/dev/sdb2". If so that trashed the configuration blocks of the volume group not the MBR and partition table. So I move on to the next speculation. If you are positive it was "of=/dev/sdb" with no number none of the rest applies. That is consistent with the results - It won't boot because there's no / because there's no vg_XYZ because the volume group table had the first 442 bytes overwritten. Volume groups do have configuration data and it can be recovered. Maybe. When you started the thread you wer elooking for alternate superblocks. Volume groups do have tables that work sort of like that. I had hoped that "vgscan" would look for alternate copies. I take it there was not a second drive in vg_XYZ? Alternate copies go on every drive. Not sure what other tools to use if there was a single disk. I build commercial systems with mirrored boot for reasons like this. Or at least bootable kickstart images on DVD-ROM. So at this point I've run to the end of my rope. Tools like PartitionMagic look into partitions. You need a tool like VolumeGroupMagic. If there is such a tool. If there is I want one to add to my war chest marked "Just because you're paranoid doesn't mean they are out to get you".
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-16 21:44 -0700 |
| Message-ID | <5903549.2603.1334637891638.JavaMail.geo-discussion-forums@pbcjp1> |
| In reply to | #2658 |
On Tuesday, April 17, 2012 12:34:18 AM UTC+5:30, Doug Freyburger wrote:
> Harry wrote:
> > Doug Freyburger <dfrey...@yahoo.com> wrote:
> >
> >> According to the "fdisk -l" output there is a 250 MB parition in Linux
> >> format marked bootable. Clearly /boot. It does not fsck nor does it
> >> mount as /mnt/boot. if only the boot code of the MBR were written that
> >> partition would fsck and mount.
> >
> > No, actually, I /can/ mount the boot partition sdb1.
> > ...
> > $ ls /mnt/x
> > config-3.2.5-3.fc16.i686.PAE
> > initramfs-3.2.9-1.fc16.i686.PAE.img
> > config-3.2.9-1.fc16.i686.PAE
> > initramfs-3.2.9-2.fc16.i686.PAE.img
> > config-3.2.9-2.fc16.i686.PAE initrd-
> > plymouth.img
> > config.mk-compat-wireless-3.3-rc1-2-3.2.5-3.fc16.i686.PAE lost+found
> > config.mk-compat-wireless-3.3-rc1-2-3.2.9-1.fc16.i686.PAE
> > System.map-3.2.5-3.fc16.i686.PAE
> > config.mk-compat-wireless-3.3-rc1-2-3.2.9-2.fc16.i686.PAE
> > System.map-3.2.9-1.fc16.i686.PAE
> > efi
> > System.map-3.2.9-2.fc16.i686.PAE
> > grub
> > vmlinuz-3.2.5-3.fc16.i686.PAE
> > grub2
> > vmlinuz-3.2.9-1.fc16.i686.PAE
> > initramfs-3.2.5-3.fc16.i686.PAE.img
> > vmlinuz-3.2.9-2.fc16.i686.PAE
>
> That's clearly a /boot mount point. Conclusive evidence the partition
> table was not trashed. No way did a "dd" copy all 250 MB.
>
> >> According to the "vgimport -vvv" output posted here and the "pvscan"
> >> output posted on the forum there is a 79 GB partition in Linux LVM
> >> format that "should" contain the volume group vg_XYZ. Neither vgimport
> >> nor vgscan works.
>
> > I
> > have a cloned image of the bad sdb. Now what do I do with this image
> > using dd? So far, I am able to fdisk bad.img as follows:
> >
> > $ losetup /dev/loop1 bad.img
> >
> > $ # If /dev/loop1 is not specified on the next line,
> > $ # then fdisk can't see it.
> > $ fdisk -l /dev/loop1
> >
> > Disk /dev/loop1: 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/loop1p1 * 2048 1026047 512000 83 Linux
>
> Definitely /boot
>
> > /dev/loop1p2 1026048 156301311 77637632 8e Linux LVM
>
> And therefore this has to be what I would normally call VolGroup00 on he
> many Red Hat systems I have built. In your posts you have called in
> vg_XYZ.
Well, the XYZ is placeholder for my, real 3-letter hostname. I thought, I would use XYZ instead of the actual hostname to keep the interaction as objective as possible. I don't mind revealing it if it would help in solve this problem, nothing secretive/personal about it.
For the same reason, though my shell prompt is also customized (via PS1) (it's actually a 2-line prompt!), I've been choosing to use only the plain, vanilla '$ ' in all my interactions so far.
> > vgscan reports no volumes.
> >
> > $ vgscan
> > Reading all physical volumes. This may take a while...
> > No volume groups found
> >
> > Now, what to do next?
>
> That's the puzzle we have gotten to. It's nowhere near where you did
> the dd. Is there any chance the dd actually had the partition in its of
> clause? "of=/dev/sdb2". If so that trashed the configuration blocks of
> the volume group not the MBR and partition table. So I move on to the
> next speculation. If you are positive it was "of=/dev/sdb" with no
> number none of the rest applies.
I am absolutely positive that I issued the
$ dd if=/dev/sdb of=/dev/sda bs=446 count=1
command. (Recap Note: What is sdb now, was sda earlier... at the time the dd command was issued.)
I was well aware of the dangers of playing with 'dd', and so was extra, extra careful in constructing it before issuing it. Though I didn't (and still don't deeply) understand partitioning and LVM, esp the way all you folks do, when issuing the dd command I knew at least things like device vs partition, if= vs of=, bs, count, skip, 446-byte MBR code, etc. As I said earlier, I was so confident of what I was doing that I didn't think it necessary to backup the disk!
Even during Fedora 16 install, when I came to this step
http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Assign_Storage_Devices-x86.html
, I remember VERY clearly:
1. leaving this (currently messed up 80G) disk in the Data Storage Devices listbox; and
2. including the new 250 G disk in the Install Target Devices listbox.
Then, a few steps later, at http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/s1-diskpartitioning-x86.html, I remember VERY clearly /not/ having the 80G disk selected for formatting.
Could any of this have possibly messed up my disk? Probably not.
Later, I did incorrectly and unsuccessfully try various e2* commands to repair the LVM partition mistaking it for an ext4 fs. Only this part I don't remember fully well; I think, I did use the '-n' option in these commands which would have left the disk intact. Also, because I was simply copy-pasting commands from the Net without really understanding them (relying on the assurance of '-n') and because I tried various permutations of device/partition and offset numbers, I didn't really note down what all I was doing. Thus, except for these various e2* command sequences that I don't fully recall now, I'm absolutely sure of everything else.
> That is consistent with the results - It won't boot because there's no /
> because there's no vg_XYZ because the volume group table had the first
> 442 bytes overwritten.
>
> Volume groups do have configuration data and it can be recovered.
> Maybe. When you started the thread you wer elooking for alternate
> superblocks. Volume groups do have tables that work sort of like that.
> I had hoped that "vgscan" would look for alternate copies.
>
> I take it there was not a second drive in vg_XYZ? Alternate copies go
> on every drive. Not sure what other tools to use if there was a single
> disk. I build commercial systems with mirrored boot for reasons like
> this. Or at least bootable kickstart images on DVD-ROM. So at this
> point I've run to the end of my rope.
>
> Tools like PartitionMagic look into partitions. You need a tool like
> VolumeGroupMagic. If there is such a tool. If there is I want one to
> add to my war chest marked "Just because you're paranoid doesn't mean
> they are out to get you".
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2012-04-17 17:18 +0000 |
| Message-ID | <PBhjr.8014$JR1.2687@newsfe06.iad> |
| In reply to | #2663 |
On 2012-04-17, Harry <simonsharry@gmail.com> wrote: > On Tuesday, April 17, 2012 12:34:18 AM UTC+5:30, Doug Freyburger wrote: >> Harry wrote: >> > Doug Freyburger <dfrey...@yahoo.com> wrote: >> > >> >> According to the "fdisk -l" output there is a 250 MB parition in Linux >> >> format marked bootable. Clearly /boot. It does not fsck nor does it >> >> mount as /mnt/boot. if only the boot code of the MBR were written that >> >> partition would fsck and mount. >> > >> > No, actually, I /can/ mount the boot partition sdb1. So what. Partition 1 starts in the same place even if the table was overwritten. >> > ... >> > $ ls /mnt/x >> > config-3.2.5-3.fc16.i686.PAE >> > initramfs-3.2.9-1.fc16.i686.PAE.img >> > config-3.2.9-1.fc16.i686.PAE >> > initramfs-3.2.9-2.fc16.i686.PAE.img >> > config-3.2.9-2.fc16.i686.PAE initrd- >> > plymouth.img >> > config.mk-compat-wireless-3.3-rc1-2-3.2.5-3.fc16.i686.PAE lost+found >> > config.mk-compat-wireless-3.3-rc1-2-3.2.9-1.fc16.i686.PAE >> > System.map-3.2.5-3.fc16.i686.PAE >> > config.mk-compat-wireless-3.3-rc1-2-3.2.9-2.fc16.i686.PAE >> > System.map-3.2.9-1.fc16.i686.PAE >> > efi >> > System.map-3.2.9-2.fc16.i686.PAE >> > grub >> > vmlinuz-3.2.5-3.fc16.i686.PAE >> > grub2 >> > vmlinuz-3.2.9-1.fc16.i686.PAE >> > initramfs-3.2.5-3.fc16.i686.PAE.img >> > vmlinuz-3.2.9-2.fc16.i686.PAE >> >> That's clearly a /boot mount point. Conclusive evidence the partition >> table was not trashed. No way did a "dd" copy all 250 MB. Hardly. Why would it need to have copied all 250MB? >> >> >> According to the "vgimport -vvv" output posted here and the "pvscan" >> >> output posted on the forum there is a 79 GB partition in Linux LVM >> >> format that "should" contain the volume group vg_XYZ. Neither vgimport >> >> nor vgscan works. >> >> > I >> > have a cloned image of the bad sdb. Now what do I do with this image >> > using dd? So far, I am able to fdisk bad.img as follows: >> > >> > $ losetup /dev/loop1 bad.img >> > >> > $ # If /dev/loop1 is not specified on the next line, >> > $ # then fdisk can't see it. >> > $ fdisk -l /dev/loop1 >> > >> > Disk /dev/loop1: 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/loop1p1 * 2048 1026047 512000 83 Linux >> >> Definitely /boot >> >> > /dev/loop1p2 1026048 156301311 77637632 8e Linux LVM >> >> And therefore this has to be what I would normally call VolGroup00 on he >> many Red Hat systems I have built. In your posts you have called in >> vg_XYZ. > > Well, the XYZ is placeholder for my, real 3-letter hostname. I thought, I would use XYZ instead of the actual hostname to keep the interaction as objective as possible. I don't mind revealing it if it would help in solve this problem, nothing secretive/personal about it. > > For the same reason, though my shell prompt is also customized (via PS1) (it's actually a 2-line prompt!), I've been choosing to use only the plain, vanilla '$ ' in all my interactions so far. > >> > vgscan reports no volumes. >> > >> > $ vgscan >> > Reading all physical volumes. This may take a while... >> > No volume groups found >> > >> > Now, what to do next? >> >> That's the puzzle we have gotten to. It's nowhere near where you did >> the dd. Is there any chance the dd actually had the partition in its of >> clause? "of=/dev/sdb2". If so that trashed the configuration blocks of >> the volume group not the MBR and partition table. So I move on to the >> next speculation. If you are positive it was "of=/dev/sdb" with no >> number none of the rest applies. > > I am absolutely positive that I issued the > > $ dd if=/dev/sdb of=/dev/sda bs=446 count=1 And of what value is your "absolutely positive"? People have a wonderful ability to remember what should have happened, rather than what did happen. > > command. (Recap Note: What is sdb now, was sda earlier... at the time the dd command was issued.) > > I was well aware of the dangers of playing with 'dd', and so was extra, extra careful in constructing it before issuing it. Though I didn't (and still don't deeply) understand partitioning and LVM, esp the way all you folks do, when issuing the dd command I knew at least things like device vs partition, if= vs of=, bs, count, skip, 446-byte MBR code, etc. As I said earlier, I was so confident of what I was doing that I didn't think it necessary to backup the disk! > > Even during Fedora 16 install, when I came to this step > http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Assign_Storage_Devices-x86.html > , I remember VERY clearly: > 1. leaving this (currently messed up 80G) disk in the Data Storage Devices listbox; and > 2. including the new 250 G disk in the Install Target Devices listbox. > > Then, a few steps later, at http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/s1-diskpartitioning-x86.html, I remember VERY clearly /not/ having the 80G disk selected for formatting. > > Could any of this have possibly messed up my disk? Probably not. > > Later, I did incorrectly and unsuccessfully try various e2* commands to repair the LVM partition mistaking it for an ext4 fs. Only this part I don't remember fully well; I think, I did use the '-n' option in these commands which would have left the disk intact. Also, because I was simply copy-pasting commands from the Net without really understanding them (relying on the assurance of '-n') and because I tried various permutations of device/partition and offset numbers, I didn't really note down what all I was doing. Thus, except for these various e2* command sequences that I don't fully recall now, I'm absolutely sure of everything else. > And so you could well have totally messed it up. >> That is consistent with the results - It won't boot because there's no / >> because there's no vg_XYZ because the volume group table had the first >> 442 bytes overwritten. >> >> Volume groups do have configuration data and it can be recovered. >> Maybe. When you started the thread you wer elooking for alternate >> superblocks. Volume groups do have tables that work sort of like that. >> I had hoped that "vgscan" would look for alternate copies. >> >> I take it there was not a second drive in vg_XYZ? Alternate copies go >> on every drive. Not sure what other tools to use if there was a single >> disk. I build commercial systems with mirrored boot for reasons like >> this. Or at least bootable kickstart images on DVD-ROM. So at this >> point I've run to the end of my rope. >> >> Tools like PartitionMagic look into partitions. You need a tool like >> VolumeGroupMagic. If there is such a tool. If there is I want one to >> add to my war chest marked "Just because you're paranoid doesn't mean >> they are out to get you".
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-17 18:41 -0700 |
| Message-ID | <2141365.24.1334713269217.JavaMail.geo-discussion-forums@pbaf6> |
| In reply to | #2672 |
On Tuesday, April 17, 2012 10:48:39 PM UTC+5:30, unruh wrote: > And of what value is your "absolutely positive"? People have a wonderful > ability to remember what should have happened, rather than what did > happen. > > And so you could well have totally messed it up. Can you just shut the fsck -y up?
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2012-04-12 19:09 +0000 |
| Message-ID | <JLFhr.60762$M%7.57793@newsfe10.iad> |
| In reply to | #2595 |
On 2012-04-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > Doug Freyburger <dfreybur@yahoo.com> writes: >> Harry wrote: > >>> ================= >>> Details of what I did: >>> ================= >>> >>> Using the `dd` command, I was hoping that I would be able to copy over >>> the first 446 bytes from Disk B (250GB) to Disk A (80GB), in order to >>> make Disk A bootable just like Disk B. I issued the command: >>> >>> dd if=/dev/sdb of=/dev/sda bs=446 count=1 >>> >>> But when I could not boot up from `sda`, I rebooted from `sdb` to see >>> what was going on. To my horror, `sda` was being reported to have a >>> bad superblock, now. >> >> Okay, let's step back and think about what you did compared to what you >> have been trying to do since. >> >> What you did - Take the partition table of disk sdb and write it to the >> partition table of disk sda. > > That's not correct. 446 is precisely the value you use to avoid > modifying the partition table of the target. Since the partition table > quoted is consistent with an 80GB disk and not a 250GB disk, it's a safe > bet that the partition table on the target wasn't modified. You may be right. On the other hand, the evidence is otherwise. He cannot read the data on the disk, which he should be able to if the partition table is unmodified. >
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-12 10:46 -0700 |
| Message-ID | <7d0cf778-5964-4205-9442-a0f3430564a5@v7g2000pbs.googlegroups.com> |
| In reply to | #2590 |
On Apr 12, 8:59 pm, Doug Freyburger <dfrey...@yahoo.com> wrote: > Harry wrote: > > If you got it wrong your saving grace is so far all you have written to > is the partition table. All of the data in the former partitions is > still there. So start using "fdisk /dev/sda" and start guessing at how > many partitions there used to be and what sizes they used to be. Hint - > Start by guessing one partition on the whole disk. Then one partition > on half of it. Then one partition on 3/4ths of it or whatever. Do a > binary descent. Eventually you'll know the exact size and location of > the first partition. > > If there's a second partition it will start one cylinder after the > first. Initial guess is the rest of the drive. Lather rinse repeat > until you have it figured out. Doug, is there any way to avoid having to reboot after each edit of the partition table? The messed up disk is sitting as sdb (or, a secondary disk) in my current system, which means I am not booting from it. For example, given the fact that right now sdb is unmountable, can I repeatedly try the mount command (or, any LVM- equivalent of mount) to check whether or not my edits to the partition table were correct. I have included a copy of a backup of the LVM setup here: http://superuser.com/questions/411697/lvm-volume-with-corrupt-mbr-how-to-mount-and-recover-data-from-it
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2012-04-12 19:13 +0000 |
| Message-ID | <rPFhr.45264$cd7.17772@newsfe06.iad> |
| In reply to | #2596 |
On 2012-04-12, Harry <simonsharry@gmail.com> wrote: > On Apr 12, 8:59?pm, Doug Freyburger <dfrey...@yahoo.com> wrote: >> Harry wrote: >> >> If you got it wrong your saving grace is so far all you have written to >> is the partition table. ?All of the data in the former partitions is >> still there. ?So start using "fdisk /dev/sda" and start guessing at how >> many partitions there used to be and what sizes they used to be. ?Hint - >> Start by guessing one partition on the whole disk. ?Then one partition >> on half of it. ?Then one partition on 3/4ths of it or whatever. ?Do a >> binary descent. ?Eventually you'll know the exact size and location of >> the first partition. >> >> If there's a second partition it will start one cylinder after the >> first. ?Initial guess is the rest of the drive. ?Lather rinse repeat >> until you have it figured out. > > Doug, is there any way to avoid having to reboot after each edit of > the partition table? The messed up disk is sitting as sdb (or, a The messed up disk should be nowhere around your computer. It should be unplugged and stored in a closet. You should be working ONLY with a clone of it, which you claim to have. > secondary disk) in my current system, which means I am not booting > from it. For example, given the fact that right now sdb is > unmountable, can I repeatedly try the mount command (or, any LVM- > equivalent of mount) to check whether or not my edits to the partition > table were correct. I have included a copy of a backup of the LVM > setup here: > > http://superuser.com/questions/411697/lvm-volume-with-corrupt-mbr-how-to-mount-and-recover-data-from-it >
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-12 12:21 -0700 |
| Message-ID | <a243830e-cb19-45a8-b2f8-5d6ce45ff2b9@gh10g2000pbc.googlegroups.com> |
| In reply to | #2612 |
On Apr 13, 12:13 am, unruh <un...@invalid.ca> wrote:
> On 2012-04-12, Harry <simonsha...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 12, 8:59?pm, Doug Freyburger <dfrey...@yahoo.com> wrote:
> >> Harry wrote:
>
> >> If you got it wrong your saving grace is so far all you have written to
> >> is the partition table. ?All of the data in the former partitions is
> >> still there. ?So start using "fdisk /dev/sda" and start guessing at how
> >> many partitions there used to be and what sizes they used to be. ?Hint -
> >> Start by guessing one partition on the whole disk. ?Then one partition
> >> on half of it. ?Then one partition on 3/4ths of it or whatever. ?Do a
> >> binary descent. ?Eventually you'll know the exact size and location of
> >> the first partition.
>
> >> If there's a second partition it will start one cylinder after the
> >> first. ?Initial guess is the rest of the drive. ?Lather rinse repeat
> >> until you have it figured out.
>
> > Doug, is there any way to avoid having to reboot after each edit of
> > the partition table? The messed up disk is sitting as sdb (or, a
>
> The messed up disk should be nowhere around your computer. It should be
> unplugged and stored in a closet. You should be working ONLY with a
> clone of it, which you claim to have.
>
>
>
>
>
>
>
> > secondary disk) in my current system, which means I am not booting
> > from it. For example, given the fact that right now sdb is
> > unmountable, can I repeatedly try the mount command (or, any LVM-
> > equivalent of mount) to check whether or not my edits to the partition
> > table were correct. I have included a copy of a backup of the LVM
> > setup here:
>
> > http://superuser.com/questions/411697/lvm-volume-with-corrupt-mbr-how...
I have an image of the messed up disk (the former sda), which I
created thus:
dd if=/dev/sda of=/path/to/messedup.imsg
Isn't this sufficient, unruh? If something goes wrong, I can always
copy the image back, isn't it?
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2012-04-12 20:12 +0000 |
| Message-ID | <mGGhr.21084$dq4.2652@newsfe23.iad> |
| In reply to | #2613 |
On 2012-04-12, Harry <simonsharry@gmail.com> wrote: > On Apr 13, 12:13?am, unruh <un...@invalid.ca> wrote: >> On 2012-04-12, Harry <simonsha...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >> > On Apr 12, 8:59?pm, Doug Freyburger <dfrey...@yahoo.com> wrote: >> >> Harry wrote: >> >> >> If you got it wrong your saving grace is so far all you have written to >> >> is the partition table. ?All of the data in the former partitions is >> >> still there. ?So start using "fdisk /dev/sda" and start guessing at how >> >> many partitions there used to be and what sizes they used to be. ?Hint - >> >> Start by guessing one partition on the whole disk. ?Then one partition >> >> on half of it. ?Then one partition on 3/4ths of it or whatever. ?Do a >> >> binary descent. ?Eventually you'll know the exact size and location of >> >> the first partition. >> >> >> If there's a second partition it will start one cylinder after the >> >> first. ?Initial guess is the rest of the drive. ?Lather rinse repeat >> >> until you have it figured out. >> >> > Doug, is there any way to avoid having to reboot after each edit of >> > the partition table? The messed up disk is sitting as sdb (or, a >> >> The messed up disk should be nowhere around your computer. It should be >> unplugged and stored in a closet. You should be working ONLY with a >> clone of it, which you claim to have. >> >> >> >> >> >> >> >> > secondary disk) in my current system, which means I am not booting >> > from it. ?For example, given the fact that right now sdb is >> > unmountable, can I repeatedly try the mount command (or, any LVM- >> > equivalent of mount) to check whether or not my edits to the partition >> > table were correct. I have included a copy of a backup of the LVM >> > setup here: >> >> > ?http://superuser.com/questions/411697/lvm-volume-with-corrupt-mbr-how... > > I have an image of the messed up disk (the former sda), which I > created thus: > dd if=/dev/sda of=/path/to/messedup.imsg > > Isn't this sufficient, unruh? If something goes wrong, I can always > copy the image back, isn't it? Perhaps, but I would far rather play with a copy than the original.
[toc] | [prev] | [next] | [standalone]
| From | g.fink@gmx.net (Gernot Fink) |
|---|---|
| Date | 2012-04-12 18:20 +0000 |
| Message-ID | <9uokmgFp30U1@mid.individual.net> |
| In reply to | #2581 |
In article <81fb3fa8-62ab-43be-9974-9cdb0df10197@h4g2000pbe.googlegroups.com>, Harry <simonsharry@gmail.com> writes: > dd if=/dev/sdb of=/dev/sda bs=446 count=1 this should not shred the partitontable, but it looks like it did. Check or repair the Partitiontabele as first step. If you find nothing or a bad table use testdisk to scan for partitions. After this use dumpe2fs to find alternate superblocks. http://www.cyberciti.biz/faq/linux-find-alternative-superblocks/ As next step make a initial boot with supergrubdisk. -- MFG Gernot
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-04-12 21:35 +0100 |
| Message-ID | <jm7eak$h47$1@news.albasani.net> |
| In reply to | #2581 |
Harry wrote: > Hello, > I posted my question to superuser.com (http://superuser.com/questions/ > 410796/unable-to-repair-an-ext4-filesystem-with-bad-superblock) but > haven't got any response yet. > > In summary, not realizing what I was doing, I overwrote the first 446 > bytes of MBR via the DD command. Would greatly, *GREATLY* appreciate > if someone could help me salvage my disk! > I bet you would. My cursory response is that you have probably - if it wasnt backed up, fucked it right royally and completely. If it mounts at all, and you camn gete data off it, back it up and satrt again. If it doesn't mount...well. Good luck. IF you know the format of the superblock you MIGHT try patching that in.. so if you have another identical drive you COULD rip that off the one for the other. Id dd the raw disk off first as is and save that somewhere on something else as a possible backup Then you might try a repartiton on it with ..fdisk? to restore the data structures bit that tends to wipe directories as well? Or does it? Not sure. Buta repartition would at least establishing the sort of formats you need for a spuerblock and then rolling the backed up disk all except that block back would maybe fix it. Moral: don't go down one way streets unless you know exactly where they lead. > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Harry <simonsharry@gmail.com> |
|---|---|
| Date | 2012-04-19 06:43 -0700 |
| Message-ID | <8829037.2106.1334843028094.JavaMail.geo-discussion-forums@pbcqs8> |
| In reply to | #2581 |
On Thursday, April 12, 2012 3:59:52 PM UTC+5:30, Harry wrote:
> Hello,
> I posted my question to superuser.com (http://superuser.com/questions/
> 410796/unable-to-repair-an-ext4-filesystem-with-bad-superblock) but
> haven't got any response yet.
>
> In summary, not realizing what I was doing, I overwrote the first 446
> bytes of MBR via the DD command. Would greatly, *GREATLY* appreciate
> if someone could help me salvage my disk!
>
>
> =================
> Details of what I did:
> =================
>
> Using the `dd` command, I was hoping that I would be able to copy over
> the first 446 bytes from Disk B (250GB) to Disk A (80GB), in order to
> make Disk A bootable just like Disk B. I issued the command:
>
> dd if=/dev/sdb of=/dev/sda bs=446 count=1
>
> But when I could not boot up from `sda`, I rebooted from `sdb` to see
> what was going on. To my horror, `sda` was being reported to have a
> bad superblock, now.
>
> Worse, I was **unable** to repair it via the backup superblocks stored
> on the ext4 filesystem. This is what I did. I first got the backup
> superblock addresses, like so:
>
> [root@localhost liveuser]# mke2fs -n /dev/sda
> mke2fs 1.41.14 (22-Dec-2010)
> /dev/sda is entire device, not just one partition!
> Proceed anyway? (y,n) y
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe width=0 blocks
> 4890624 inodes, 19537686 blocks
> 976884 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=0
> 597 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks:
> 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
> 2654208,
> 4096000, 7962624, 11239424
>
> Then, I used `e2fsck -b SUPERBLOCK /dev/sda`, with each of the
> `SUPERBLOCK` values listed above, like so:
>
> [root@localhost liveuser]# e2fsck -b 32768 /dev/sda
> e2fsck 1.41.14 (22-Dec-2010)
> e2fsck: Bad magic number in super-block while trying to open /dev/sda
>
> The superblock could not be read or does not describe a correct ext2
> filesystem. If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the
> superblock
> is corrupt, and you might try running e2fsck with an alternate
> superblock:
> e2fsck -b 8193 <device>
>
> I tried every single value, but each gave the above message!
>
> **Is there anything that I could do NOW to salvage my precious disk?**
> This is an 80G disk with 2 partitions. The `/dev/sda1` partition is
> clean and is mountable; it is the `/dev/sda2` partition that is
> failing to work with commands like `mount`, `debugfs`, `dumpe2fs`,
> etc.
>
> Running `mke2fs -n` for the individual partitions gave me this (notice
> how the **First Data Block** and **Maximum filesystem blocks** both
> show **0** as their value):
>
> [root@localhost liveuser]# mke2fs -n /dev/sda1
> mke2fs 1.41.14 (22-Dec-2010)
> Filesystem label=
> OS type: Linux
> Block size=1024 (log=0)
> Fragment size=1024 (log=0)
> Stride=0 blocks, Stripe width=0 blocks
> 128016 inodes, 512000 blocks
> 25600 blocks (5.00%) reserved for the super user
> First data block=1
> Maximum filesystem blocks=67633152
> 63 block groups
> 8192 blocks per group, 8192 fragments per group
> 2032 inodes per group
> Superblock backups stored on blocks:
> 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
>
> [root@localhost liveuser]# mke2fs -n /dev/sda2
> mke2fs 1.41.14 (22-Dec-2010)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe width=0 blocks
> 4857856 inodes, 19409408 blocks
> 970470 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=0
> 593 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks:
> 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
> 2654208,
> 4096000, 7962624, 11239424
>
> I still don't know what was wrong in my `dd` command that corrupted my
> ext4 superblock. You cannot imagine how happy I will be if someone
> could help me recover my disk back... since, except fo this bad
> superblock, all the data is just sitting right there!
>
> PLEASE HELP, my soul is crying as I write this :-((
>
> PS: If I can get a response faster/better from another forum on the
> Net, please do point me to it.
After about 70 posts in this thread by some very helpful and knowledgeable members of this forum, I managed to run into this article:
http://www.microdevsys.com/WordPress/2011/09/19/linux-lvm-recovering-a-lost-volume/
Though the specifics of my situation and the causes leading to it were different from the author's, I did manage to notice the 'vgcfgrestore' command that had been missing all along in all the various suggestions made. I decided to give it a try - and lo and behold - it worked!
While I'm VERY happy now at the prospect of a full data recovery (assuming no data was lost due to e2fsck's fixes), I'd still like to seek some final help from you folks in reconstructing the 'crime scene': basically, deducing from the following sequence of steps of the solution as to what must have gotten corrupted and how and why. I have already told my story enough number times in this thread and on superuser.com, but does it corroborate with these additional data points of the solution?
================
Solution:
================
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) I then 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 an `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 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
d) At this point, I decide to repair the filesystem relying on the strength of my backed up image of the messed up disk. In other words, even if my e2fsck'ing were to wreak further havoc on the disk, I could always return to Step (c) above.
$ e2fsck /dev/mapper/vg_XYZ-lv_root
I had to say 'y' to so many tons and tons of
Directories count wrong for group #<NNN>
prompts that I had almost given up hope.
e) Verification if the partition was clean.
$ e2fsck /dev/mapper/vg_XYZ-lv_root
e2fsck 1.41.14 (22-Dec-2010)
/dev/mapper/vg_XYZ-lv_root: clean, 912765/4595712 files, 14271569/18374656 blocks
f) Mounting.
$ mount /dev/mapper/vg_XYZ-lv_root /mnt/x
$ ls -l /mnt/x
total 144
dr-xr-xr-x. 2 root root 4096 Apr 8 09:39 bin
drwxr-xr-x. 2 root root 4096 Oct 25 18:30 boot
drwxr-xr-x. 2 root root 4096 Mar 3 2011 cgroup
drwxr-xr-x. 2 root root 4096 Oct 25 18:30 dev
drwxr-xr-x. 189 root root 12288 Apr 10 12:44 etc
drwxr-xr-x. 8 root root 4096 Jan 5 10:11 home
dr-xr-xr-x. 23 root root 12288 Mar 14 03:23 lib
drwx------. 2 root root 16384 Oct 25 18:30 lost+found
drwxr-xr-x. 2 root root 4096 Jul 29 2011 media
drwxr-xr-x. 3 root root 4096 Jul 29 2011 mnt
drwxr-xr-x. 5 root root 4096 Jan 30 22:00 opt
drwxr-xr-x. 2 root root 4096 Oct 25 18:30 proc
dr-xr-x---. 25 root root 4096 Apr 10 12:43 root
drwxr-xr-x. 36 root root 4096 Nov 20 09:09 run
dr-xr-xr-x. 2 root root 12288 Mar 13 06:32 sbin
drwxr-xr-x. 2 root root 4096 Dec 31 08:29 selinux
drwxr-xr-x. 2 root root 4096 Jul 29 2011 srv
drwxr-xr-x. 2 root root 4096 Oct 25 18:30 sys
drwxrwxrwt. 49 root root 28672 Apr 10 12:44 tmp
drwxr-xr-x. 12 root root 4096 Nov 20 07:18 usr
drwxr-xr-x. 22 root root 4096 Jan 4 10:15 var
[toc] | [prev] | [next] | [standalone]
| From | Bob <SEE_SIGNATURE@localhost.localdomain.invalid> |
|---|---|
| Date | 2012-04-19 11:29 -0500 |
| Message-ID | <jmpeht03063@news3.newsguy.com> |
| In reply to | #2681 |
On 04/19/2012 08:43 AM, Harry wrote: [SNIP] > d) At this point, I decide to repair the filesystem relying on the strength of my backed up image of the messed up disk. In other words, even if my e2fsck'ing were to wreak further havoc on the disk, I could always return to Step (c) above. > > $ e2fsck /dev/mapper/vg_XYZ-lv_root > > I had to say 'y' to so many tons and tons of > > Directories count wrong for group #<NNN> > > prompts that I had almost given up hope. > > e) Verification if the partition was clean. > > $ e2fsck /dev/mapper/vg_XYZ-lv_root > e2fsck 1.41.14 (22-Dec-2010) > /dev/mapper/vg_XYZ-lv_root: clean, 912765/4595712 files, 14271569/18374656 blocks > > f) Mounting. > > $ mount /dev/mapper/vg_XYZ-lv_root /mnt/x > > $ ls -l /mnt/x > total 144 > dr-xr-xr-x. 2 root root 4096 Apr 8 09:39 bin > drwxr-xr-x. 2 root root 4096 Oct 25 18:30 boot > drwxr-xr-x. 2 root root 4096 Mar 3 2011 cgroup > drwxr-xr-x. 2 root root 4096 Oct 25 18:30 dev > drwxr-xr-x. 189 root root 12288 Apr 10 12:44 etc > drwxr-xr-x. 8 root root 4096 Jan 5 10:11 home > dr-xr-xr-x. 23 root root 12288 Mar 14 03:23 lib > drwx------. 2 root root 16384 Oct 25 18:30 lost+found > drwxr-xr-x. 2 root root 4096 Jul 29 2011 media > drwxr-xr-x. 3 root root 4096 Jul 29 2011 mnt > drwxr-xr-x. 5 root root 4096 Jan 30 22:00 opt > drwxr-xr-x. 2 root root 4096 Oct 25 18:30 proc > dr-xr-x---. 25 root root 4096 Apr 10 12:43 root > drwxr-xr-x. 36 root root 4096 Nov 20 09:09 run > dr-xr-xr-x. 2 root root 12288 Mar 13 06:32 sbin > drwxr-xr-x. 2 root root 4096 Dec 31 08:29 selinux > drwxr-xr-x. 2 root root 4096 Jul 29 2011 srv > drwxr-xr-x. 2 root root 4096 Oct 25 18:30 sys > drwxrwxrwt. 49 root root 28672 Apr 10 12:44 tmp > drwxr-xr-x. 12 root root 4096 Nov 20 07:18 usr > drwxr-xr-x. 22 root root 4096 Jan 4 10:15 var Looks like you finally got there. Good going! I still have no clue about what might have happened to cause that mess. Next step will be to see if the files you want to save are all intact. -- Bob Nichols AT comcast.net I am "RNichols42"
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.os.linux.setup
csiph-web