rescue data from unbootable Fedora

moshekim79 · #1 4th April 2011, 07:01 AM

Adding several 2TB HDDs somehow crashed SATA controller on motherboard.
Fedora will no longer boot.

I connected HDD (with Fedora OS) to another computer.
Fedora gets past GRUB, but hangs before loading the splash screen.
Is something wrong with GRUB settings?
Previously, I had dual boot at GRUB (Fedora and WindowsXP).

What is the easiest way to get Fedora to boot properly on another system?
I need access to those files.

Any help is appreciated.

lightman47 · #2 4th April 2011, 03:20 PM

I'm fairly new at all this, but it sounds like it doesn't like the video card. To verify, you might try booting into runlevel 3 and see if you get to login. In grub.conf, append a blank and a"3" (no quotes) to the end of the 'kernel' line. If you're unable to get that far, start pressing the down-arrow after the P.O.S.T. and before GRUB - you can then "e"dit the above onto the line from there, then "b"oot. If you get to login, is likely a video issue.

scott32746 · #3 4th April 2011, 03:30 PM

Hello,

I think you are going to have troubles changing hardware

But your boot problem maybe by moving the harddrive you have change the boot info.
you can try
From rescue mode
type grub
From GRUB prompt ran
find /grub/stage1 or find /boot/grub/stage1
grub root (hd0,0)
grub setup (hd0)
exit grub prompt
reboot

scott32746 · #4 4th April 2011, 07:53 PM

something to try is when it's booting push F2 I think this removes splash screen,
then you maybe able to see where it is hanging

moshekim79 · #5 4th April 2011, 08:28 PM

'root device not found, sleeping forever'

i have another laptop running fedora.
is there anyway to transfer data from hdd (non-bootable fedora) to my laptop?
i'll figure the boot thing later, i just need to get my data out.

thanks in advance.

scott32746 · #6 4th April 2011, 08:52 PM

Sleep forever is a grub problem.
Was this drive part of a raid or LVM.

There is a USB device you could use to connect the drive to the laptop.

Looks like grub recreated the stage1, I would try to run the grub commands again.

something else you could try is adding SATA controller card to the OLD system and connect to that. still going to need to update GRUB.

moshekim79 · #7 4th April 2011, 10:08 PM

hdd was part of LVM.
darnit, i'll go get an extra SATA controller card this weekend, and retry grub commands.

in the meantime, i'll put it into a USB device, and see if it will automatically mount.

---------- Post added at 05:08 PM ---------- Previous post was at 05:08 PM ----------

hdd was part of LVM.
darnit, i'll go get an extra SATA controller card this weekend, and retry grub commands.

in the meantime, i'll put it into a USB device, and see if it will automatically mount.

hefeweizen · #8 4th April 2011, 10:30 PM

Repairing the system is a bit different from recovering data, so this might not be germane.

boot knoppix or other live CD
vgscan
vgchange -ay <vg>
mount <lv> <dir>

With the above, you can copy files to other media or another system, but you're still faced with rebuilding or reinstalling the system.

moshekim79 · #9 5th April 2011, 12:17 PM

Quote:

Originally Posted by hefeweizen

Repairing the system is a bit different from recovering data, so this might not be germane.

boot knoppix or other live CD
vgscan
vgchange -ay <vg>
mount <lv> <dir>

With the above, you can copy files to other media or another system, but you're still faced with rebuilding or reinstalling the system.

Inserted USB hard drive (to recover data files)
Booted knoppix liveCD
in terminal, here is output for 'vgscan'

Code:

root@Microknoppix:/home/knoppix# vgscan
  Reading all physical volumes.  This may take a while...
  No volume groups found

In the 'File Manager' GUI, only the boot partition (sdb1) is showing. how can I access and transfer the data partition? is it irrecoverable?

hefeweizen · #10 5th April 2011, 07:19 PM

lvm is configurable for what drives to scan. I would expect /dev/sd* to be included and you indicate that the USB drive is coming in as /dev/sdb. Please post "fdisk -l /dev/sdb"; I would expect a /dev/sdb2 and for that to be the lvm volume.

moshekim79 · #11 5th April 2011, 08:26 PM

Quote:

Originally Posted by hefeweizen

lvm is configurable for what drives to scan. I would expect /dev/sd* to be included and you indicate that the USB drive is coming in as /dev/sdb. Please post "fdisk -l /dev/sdb"; I would expect a /dev/sdb2 and for that to be the lvm volume.

yes you are right! here's the output:

Code:

root@Microknoppix:/home/knoppix# fdisk -l /dev/sdb

Disk /dev/sdb: 1000.2 GB, 1000203804160 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ab3f2

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          26      204800   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdb2              26      121601   976555201   8e  Linux LVM

attempting to mount, but there are problems...

Code:

root@Microknoppix:/mnt/sdb2# mount /dev/sdb2 /mnt/sdb2      
mount: you must specify the filesystem type
root@Microknoppix:/mnt/sdb2# mount -t ext4 /dev/sdb2 /mnt/sdb2
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
root@Microknoppix:/mnt/sdb2# dmesg | tail
[  207.809683] tg3 0000:08:00.0: eth0: Flow control is on for TX and on for RX
[  207.809847] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  218.456679] eth0: no IPv6 routers present
[  267.116531] EXT3-fs: barriers not enabled
[  267.587816] kjournald starting.  Commit interval 5 seconds
[  267.588271] EXT3-fs (sdb1): using internal journal
[  267.588280] EXT3-fs (sdb1): mounted filesystem with writeback data mode
[ 1478.299078] EXT4-fs (sdb2): VFS: Can't find ext4 filesystem
[ 1544.803554] CE: hpet increased min_delta_ns to 20113 nsec
[ 1558.876956] CE: hpet increased min_delta_ns to 30169 nsec

---------- Post added at 03:24 PM ---------- Previous post was at 02:35 PM ----------

checking filesystem (ext4) in sdb2

Code:

root@Microknoppix:~# fsck.ext4 -n /dev/sdb2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb2

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>

not sure if it's okay to try their recommendation. (ie: e2fsck -b 1893 /dev/sdb2)
any ideas?

---------- Post added at 03:26 PM ---------- Previous post was at 03:24 PM ----------

Code:

root@Microknoppix:~# e2fsck -b 8193 /dev/sdb2
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb2

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>

scott32746 · #12 5th April 2011, 08:30 PM

I do not think you can just mount a LVM
give this site a try
http://www.brandonhutchinson.com/Mou...VM_volume.html

hefeweizen · #13 5th April 2011, 08:55 PM

sdb2 is not an en ext4 filesystem. vgscan should be picking up the name of the VG which /dev/sdb2 belongs to. post the results of vgscan -v and pvscan -v.

moshekim79 · #14 7th April 2011, 04:01 AM

Code:

root@Microknoppix:/home/knoppix# vgscan -v
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
  Reading all physical volumes.  This may take a while...
    Finding all volume groups
  No volume groups found
root@Microknoppix:/home/knoppix# pvscan -v
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
    Walking through all physical volumes
  No matching physical volumes found

is this a problem?

hefeweizen · #15 7th April 2011, 04:20 AM

After the fdisk results for /dev/sdb2 I would expect the vgscan or pvscan to discover it. However, this isn't happening. There's a slight chance that lvm.conf is not scanning it, but let me also ask if /dev/sdb2 is the sole volume in the volume group?

In trying to recover your data, I believe you've reconfigured some hardware; could you describe those changes?