PDA

View Full Version : Could not mount disks after Fedora 15 installation...


atipico
7th July 2011, 02:53 AM
Please, I`d like to know what happens when with the disks the we include in the installation process of Fedora 15. Obviously, the HD we choose to be the system is entirely formated and reconfigured. But what about the others? What does happen to them? I`m asking this because I have included two brand new disks of 2 TB, one of them with 900.000 files and the other empty, both of them formated with ext4, and completely functional on Fedora 14. However, after the upgrade, in the very first Fedora 15 boot, these disks disapeared from "places", and could not be mounted even via terminal. Opening the Gnome Disk Utility, I found out they had been changed to VLM (instead of ext4) and that they also lost their original lable. I am starting to be concerned because all the data there was important to me. I thank any professional help that I could receive remotely, even if I have to pay for it. Thank you very much.

stoat
7th July 2011, 03:27 AM
But what about the others? What does happen to them? If you chose the partition option "Use all space", then Fedora will be installed in LVM physical volumes that fill all selected devices. But I don't really know if that is what happened. Take a moment to post something that shows the partition layout.su
fdisk -l

atipico
7th July 2011, 03:34 AM
Thank you for the reply. My guess is that the Fedora 15 installation program has overwritten the original filesystem of both 2 TB disks but that all the data is still there.

# 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: 0x000c7ca1

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 156301311 77637632 8e Linux LVM

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 0x34cd78a8

Device Boot Start End Blocks Id System
/dev/sdc1 2048 3907028991 1953513472 8e Linux LVM

Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 0x34cd78a8

Device Boot Start End Blocks Id System
/dev/sdd1 2048 3907028991 1953513472 8e Linux LVM

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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: 0x000a972c

Device Boot Start End Blocks Id System
/dev/sdb1 2048 1953523711 976760832 8e Linux LVM

Disk /dev/mapper/vg_atipico-lv_swap: 8422 MB, 8422162432 bytes
255 heads, 63 sectors/track, 1023 cylinders, total 16449536 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

Disk /dev/mapper/vg_atipico-lv_swap doesn't contain a valid partition table

Disk /dev/mapper/vg_atipico-lv_root: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders, total 104857600 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

Disk /dev/mapper/vg_atipico-lv_root doesn't contain a valid partition table

Disk /dev/sde: 1021 MB, 1021313024 bytes
32 heads, 61 sectors/track, 1021 cylinders, total 1994752 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

Disk /dev/mapper/vg_atipico-lv_home: 4018.1 GB, 4018143232000 bytes
255 heads, 63 sectors/track, 488511 cylinders, total 7847936000 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

Disk /dev/mapper/vg_atipico-lv_home doesn't contain a valid partition table

stoat
7th July 2011, 03:53 AM
I see an 80 GB drive with what looks like a Fedora boot partition and an LVM PV. Then two 2 TB drives and a 1 TB drive that are all completely filled by LVM PVs. The fifth device (/dev/sde) might be a pen drive or something else small like that. I don't see any ext4 partitions that you said existed before.

I don't use LVM, but maybe these terminal commands will help you or someone figure out what is in all those things...pvdisplay
vgdisplay
lvdisplayThere are people here who know and use LVM. Maybe one of them will come by here and be able to help you determine what has happened.

atipico
7th July 2011, 04:14 AM
Thank you for the reply. Well, but both 2 TB disks were formated with ext4 for I have done it myself. Here we go.

root@PartedMagic:~# pvdisplay
Found duplicate PV xOhQK5Bcf38lNAysN4zf2jAX1A2LKK0I: using /dev/sdd1 not /dev/sdc1
Couldn't find device with uuid xJ8v2Y-hJFB-SX0V-oiEO-f16T-fzO8-gfb13U.
--- Physical volume ---
PV Name /dev/sda2
VG Name vg_atipico
PV Size 74,04 GiB / not usable 10,00 MiB
Allocatable yes (but full)
PE Size 32,00 MiB
Total PE 2369
Free PE 0
Allocated PE 2369
PV UUID 3Ohsvj-Jtss-Wk2i-5S2P-2u0Q-JWfc-S5vve8

--- Physical volume ---
PV Name /dev/sdd1
VG Name vg_atipico
PV Size 1,82 TiB / not usable 16,00 MiB
Allocatable yes (but full)
PE Size 32,00 MiB
Total PE 59616
Free PE 0
Allocated PE 59616
PV UUID xOhQK5-Bcf3-8lNA-ysN4-zf2j-AX1A-2LKK0I

--- Physical volume ---
PV Name unknown device
VG Name vg_atipico
PV Size 1,82 TiB / not usable 16,00 MiB
Allocatable yes (but full)
PE Size 32,00 MiB
Total PE 59616
Free PE 0
Allocated PE 59616
PV UUID xJ8v2Y-hJFB-SX0V-oiEO-f16T-fzO8-gfb13U


root@PartedMagic:~# vgdisplay
Found duplicate PV xOhQK5Bcf38lNAysN4zf2jAX1A2LKK0I: using /dev/sdd1 not /dev/sdc1
Couldn't find device with uuid xJ8v2Y-hJFB-SX0V-oiEO-f16T-fzO8-gfb13U.
--- Volume group ---
VG Name vg_atipico
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 0
Max PV 0
Cur PV 3
Act PV 2
VG Size 3,71 TiB
PE Size 32,00 MiB
Total PE 121601
Alloc PE / Size 121601 / 3,71 TiB
Free PE / Size 0 / 0
VG UUID 57WN99-y5GN-hzTs-mDys-DWEO-QlGm-zS6S56


root@PartedMagic:~# lvdisplay
Found duplicate PV xOhQK5Bcf38lNAysN4zf2jAX1A2LKK0I: using /dev/sdd1 not /dev/sdc1
Couldn't find device with uuid xJ8v2Y-hJFB-SX0V-oiEO-f16T-fzO8-gfb13U.
--- Logical volume ---
LV Name /dev/vg_atipico/lv_swap
VG Name vg_atipico
LV UUID ViybkM-uVSp-1fww-EriZ-sXdR-F2y5-9d2rHx
LV Write Access read/write
LV Status NOT available
LV Size 7,84 GiB
Current LE 251
Segments 1
Allocation inherit
Read ahead sectors auto

--- Logical volume ---
LV Name /dev/vg_atipico/lv_home
VG Name vg_atipico
LV UUID IEzy2X-TvjS-2VWb-KRgR-aWDp-Syy2-4XQ3Ko
LV Write Access read/write
LV Status NOT available
LV Size 3,65 TiB
Current LE 119750
Segments 3
Allocation inherit
Read ahead sectors auto

--- Logical volume ---
LV Name /dev/vg_atipico/lv_root
VG Name vg_atipico
LV UUID Jnan02-j7N0-zaJp-wovp-yV3p-GDSz-TlpcSb
LV Write Access read/write
LV Status NOT available
LV Size 50,00 GiB
Current LE 1600
Segments 1
Allocation inherit
Read ahead sectors auto
root@PartedMagic:~# lvdisplay
Found duplicate PV xOhQK5Bcf38lNAysN4zf2jAX1A2LKK0I: using /dev/sdd1 not /dev/sdc1
Couldn't find device with uuid xJ8v2Y-hJFB-SX0V-oiEO-f16T-fzO8-gfb13U.
--- Logical volume ---
LV Name /dev/vg_atipico/lv_swap
VG Name vg_atipico
LV UUID ViybkM-uVSp-1fww-EriZ-sXdR-F2y5-9d2rHx
LV Write Access read/write
LV Status NOT available
LV Size 7,84 GiB
Current LE 251
Segments 1
Allocation inherit
Read ahead sectors auto

--- Logical volume ---
LV Name /dev/vg_atipico/lv_home
VG Name vg_atipico
LV UUID IEzy2X-TvjS-2VWb-KRgR-aWDp-Syy2-4XQ3Ko
LV Write Access read/write
LV Status NOT available
LV Size 3,65 TiB
Current LE 119750
Segments 3
Allocation inherit
Read ahead sectors auto

--- Logical volume ---
LV Name /dev/vg_atipico/lv_root
VG Name vg_atipico
LV UUID Jnan02-j7N0-zaJp-wovp-yV3p-GDSz-TlpcSb
LV Write Access read/write
LV Status NOT available
LV Size 50,00 GiB
Current LE 1600
Segments 1
Allocation inherit
Read ahead sectors auto

michaaa62
7th July 2011, 08:33 AM
You could try to use gpart http://pkgs.org/fedora-15/fedora-i386/gpart-0.1h-14.fc15.i686.rpm.html for recovering lost partitions. It is looking for traces of all kind of file-systems ignoring the partition table, but it really is slow, Note please it is gpart not gparted!

Or try to recover your files with testdisk, this might sound faster, but still will be painful, because of the size of the discs. And i never tested it on LVMs, but i do hope you did not use encryption for each of your installations.

atipico
7th July 2011, 12:42 PM
Thanks for your reply, Michaaa;

I'll search for gpart to see how it can help me in this situation. Every time I used it however it was to build partitions. I never used it for recovery purposes. Please, why does you said the process take so long? I have 900.000 files in this disk. Will it be ended in a situation of thousands of files with crazy names and without the folder organization? If so, I'm a dead man.

It's now clear that Fedora 15 installation program overwrote the partition table to VLM. As the disks were formated in ext4 and all the data were saved to under this filesystem, I am experiencing this hell.

Right now I am in the PartedMagic ambient, using "Gohst 2 Linux" to clone the HD (the time I write this is 51% and, as it took 7 hours and 40 minutes to get here, I expect the same to get to the end).

I was thinking about following this steps as soon as I get the clone ready tough: http://www.cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html

Thanks.

michaaa62
7th July 2011, 02:19 PM
It is NOT gparted, which you might have used to create partitions, it is 'gpart' a command line tool which checks the whole of your disks for traces of file systems it knows and then tries to guess a partition table. You should have a clear picture of your former setup to compare it with the guess of gpart.
Expect gpart not to be any faster than your cloning process, but slower!
I would think trying to recover the files with testdisk might be quicker to perform.

atipico
7th July 2011, 04:27 PM
Thank you, Michaaa. It's gpart that I am studying right now, while I still wait for the end of the clone process (more 4 hours according to my calculations). I'd rather try all the superblock backups to see if I can recover the partition table (http://www.cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html), before anything else. If you have any information that can help me with this, it'll be greatly appreciated. By the way, I did not see anywhere that gpart works with Ext4. Once again, thanks.

michaaa62
7th July 2011, 06:50 PM
Still i would first give testdisk a chance, because it might as well find lost partitions. Right now i am giving it a try on a faily fresh install of FC15 encrypted under LVM and testdisk still finds the old partitioning scheme they used to put this Win7 on this maschine.
Right, this is what might be useful about gpart: http://louwrentius.blogspot.com/2009/12/recovering-lost-partition-using-gpart.html
http://en.wikipedia.org/wiki/Gpart
http://www.linux.com/archive/feed/57748
There might be some success with ext4, because it is an extension of ext3, which itself extends ext2's functionality.

atipico
7th July 2011, 08:32 PM
Thanks, Michaaa. If my calculations are right, I'd need 16 hours to have the 2TB HD completely scaned with gpart... It's quite a while. Indeed, this guy's tips can save my day (or half of it).

---------- Post added at 03:32 PM ---------- Previous post was at 02:03 PM ----------

16 hours later, the 2TB disk is cloned, thanks to PartedMagic CD and Ghost 4Linux which was the software that made the disk clone. If I was to make the same via dd, according to my calculations, It'd take days.

fdisk -l

Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 0x34cd78a8

Device Boot Start End Blocks Id System
/dev/sdd1 2048 3907028991 1953513472 8e Linux LVM

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 0x34cd78a8

Now the real battle starts.

michaaa62
7th July 2011, 10:24 PM
Good luck! :thumb:

This may be the wrong moment, but may i suggest luckybackup for your daily backup routine. It is a nice GUI for rsync, it makes incremental backups this way only transferring data, that has changed. But one step after the other.

atipico
7th July 2011, 10:41 PM
Michaaa, please, this is where I am right now:

testdisk /dev/sdd

TestDisk 6.12, Data Recovery Utility, May 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdd - 2000 GB / 1863 GiB - CHS 243202 255 63
Analyse cylinder 4450/243201: 01%

Linux LVM 0 32 33 243201 78 13 3907026944
Linux 0 65 2 488511 172 45 7847936000
Linux 0 1 1 243200 254 61 3907024000 [Duo]
Linux 196 49 46 457 70 61 4194304 [C-STATE]

Stop

- - -

If the name at the right is the disk's lable, so the one named [Duo] is the one I am looking for. However, the search is still in 1% and, if my calculations are right, it will long 6 hours to finish. Could I stop the test now if I wanted? If so, can you tell me what I should do From here?

I found this guide here: http://members.iinet.net.au/~herman546/p21.html#Recovering_a_Lost_Partition_With_

But I am not shure if I quite understood what I have to do now.

Thank you.

---------- Post added at 05:41 PM ---------- Previous post was at 05:30 PM ----------

Good luck! :thumb:

This may be the wrong moment, but may i suggest luckybackup for your daily backup routine. It is a nice GUI for rsync, it makes incremental backups this way only transferring data, that has changed. But one step after the other.

You could not be more right. Nut you see: this 2 TB disk was being prepared to be the master disk for the backup. My miserable mistake was to trust Fedora 15 to include it in the installation process. From now on, I'll disconnect the disks from the system when installing Fedora.

Thanks.

michaaa62
7th July 2011, 10:45 PM
Well you have the image, haven't you?
Just be safe the image is fine, then try to repair things with just correcting the partition table, but i must admit, this could lead to desaster and you will have to write the image back to the disc. Are you prepared???

Lucky Me is now off with the dogs ;)

atipico
8th July 2011, 01:24 AM
I did't save an image, I made a disk clone.

---------- Post added at 08:24 PM ---------- Previous post was at 06:03 PM ----------

I am not sure but, I think I can use this data I got from testdisk:

Disk /dev/sdd - 2000 GB / 1863 GiB - CHS 243201 255 63
Partition Start End Size in sectors
>P Linux 0 1 1 243200 254 61 3907024000 [Duo]

To use the command "mount", can't I ?

Thanks.

michaaa62
8th July 2011, 09:17 AM
In testdisk did you use the 'p' to list the files and folders?

If it is the partition with all the data you should choose it to use the partition, set the letter in front of it to 'L' and you have to set the letters for the other partitions to 'D' by clicking left or right arrow buttons.
That is the moment of truth, where you loose the data on the other partitions. Is the drive easily attachable by USB or do you have to reboot? Wil your Fedora still start up without this drive?

atipico
8th July 2011, 10:45 AM
That's the "jump of the cat"! I'll try this and tell the result.

Tecax Instagram Photos - Maki Instagram Photos - Domodossola Travel Photos on Instagram