[GT-I9505] CF-Auto-Root - Chainfire

[GT-I9505] CF-Auto-Root - xda-developers

Chainfire CF-Root
SGS4 GT-I9505 I9505
Root.

I9505 Samsung galaxy s4 I9505 Pre-Rooted Stock ROMs Odin/CWM

[ROMS] WORLD PREMIERE: I9505 Pre-Rooted Stock ROMs Odin/CWM [DEODEXED XXUBMF8 Online] - xda-developers
Firmware / rom I9505 sgs4

Main benefits of using this method are:

- FULLY ROOTED
- No need for Insecure Kernels.
- Complete, Odin flashable Packages.
- Can be used on Non-Rooted devices.
- Binary Flash Counter will NOT increase
- System status will stay NORMAL/OFFICIAL.
- Only 1 file and you have a complete firmware including Root permission.
- Fully working KIES & OTA updates (FYI: root will be lost after software update)

Using LVM In Rescue Mode repair lvm file system

System Recovery Week: Using LVM In Rescue Mode - Fedora Daily Package

System Recovery Week: Using LVM In Rescue Mode

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

Logical Volume Management (LVM) is a powerful storage system layer which abstracts the logical view of storage from the actual physical layout. It is automatically configured in the default Fedora storage configuration. LVM enables you to grow and shrink volumes, add storage from new devices to existing volumes, and migrate volumes between storage devices, all without taking the system offline. In fact, the system-config-lvm package provides a convenient way to perform all of these operations using a graphical interface.

However, you can't (yet) shrink a filesystem while it is mounted. This isn't a limitation of LVM itself, but of most filesystems, including ext3. To shrink a partition that is always mounted when the system is running -- such as the root filesystem -- it's necessary to boot from another medium, which is where rescue mode comes in (see yesterday's article). It may also be necessary to use rescue mode to recover from some particularly nasty corruption or misconfiguration issues.

To do LVM and filesystem-resizing work within the Fedora rescue mode, boot the rescue mode from disc as usual, but select Skip when the system offers to mount your hard-disk partitions. Unfortunately, this will mean that your volume groups will not be detected or activated, so you will need to do that manually.

The commands normally used for logical volume management such as vgdisplay, pvcreate, and lvreduce are actually symbolic links to a single executable named lvm. These symbolic links are not available in rescue mode, so you must explicitly use the lvm command followed by the operation you wish to perform: if you wish to do a vgscan, for example, enter the command lvm vgscan.

Therefore, to discover and activate all volume groups, you must execute these commands:

sh-3.2# lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
sh-3.2# lvm vgchange -ay
2 logical volume(s) in volume group "VolGroup00" now active

You can display information about the logical volumes using lvm lvs (or lvm lvdisplay for a more verbose display):

sh-3.2# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
LogVol00 VolGroup00 -wi-a- 28.66G
LogVol01 VolGroup00 -wi-a- 992.00M

Note that the LV and VG names are not very descriptive -- which is why it's a good idea to override the default names during system installation. In this case, we know the approximate size of the LV containing the root filesystem, so we can determine that it is LogVol00 in VolGroup00.

Armed with this information, you can now check (fsck) the filesystem, shrink the filesystem within that logical volume, and then shrink the LV. Because of the potential for rounding errors, it's best to shrink the filesystem to a size slightly smaller than the new LV size, resize the LV, and then grow the filesystem to fully fill the LV:

sh-3.2# e2fsck -f /dev/VolGroup00/LogVol00
e2fsck 1.40.2 (12-Jul-2007)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking refernce counts
Pass 5: Checking group summary information
/dev/VolGroup00/LogVol00: 122967/7514560 files (0.9% non-contiguous), 1113272/7512064 blocks

sh-3.2# resize2fs /dev/VolGroup00/LogVol00 19G
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 4980736 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 4980736 blocks long.

sh-3.2# lvm lvresize VolGroup00/LogVol00 --size 20G
WARNING: Reducing active logical volume to 20.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
Reducing logical volume LogVol00 to 20.00 GB
Logical volume LogVol00 successfully resized

sh-3.2# resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 5242880 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 5242880 blocks long.

Note that the operations following the first resize2fs do not need to be performed in rescue mode -- you can reboot the system at that point and continue after the system has booted normally. Earlier versions of the Fedora rescue mode may not set up the symbolic link /dev/VolumeGroup/LogicalVolume, so you may need to refer to/dev/mapper/VolumeGroup-LogicalVolume (e.g., use /dev/mapper/VolGroup00-LogVol00 in place of /dev/VolGroup00/LogVol00).

[How-To] Recover repair fix LVM Partition On Damaged HDD

[How-To] Recover LVM Partition On Damaged HDD ~ Web Upd8: Ubuntu / Linux blog

[HOW-TO] RECOVER LVM PARTITION ON DAMAGED HDD

The following post was send by WebUpd8 reader rkv and it's a mix of story / how-to recover the LVM partition on a damaged HDD. Read on!

Scenario:

80GB SATA HDD, Bad Sectors, 4 Primary Partitions, boot, root, swap and a 60GB Volume Group can boot into the OS (very slow), LVM not recognized.


Solution:

I connected the hard-disk to another Linux box as a secondary drive, took a while to boot indicating bad HDD. After 20 mins (yeah 20 mins), box booted into single user mode, login as root.

I then ran the following commands:

dmesg

found lots of bad blocks errors.

fdisk -l

took a couple of minutes for the output but showed all the partitions.

vgdisplay

didn't recognize any volume groups.

Now i realized that the HDD is failing, as all the above commands are taking a lot of time, so I thought taking a physical dump using dd will help a lot. I could take the raw dump of the entire /dev/sdb4 (the lvm partition) but i just needed data from the home folder i.e. 45 GB / 60 GB so I decided to try some more.

Nnow i tried to recover the lvm metadata for the volume group ( Thanks Purna! )

lvgchange -ay

After 30 mins, i got no message, but fdisk -l shows a lot of mapper devices. vgdisplay gave me all the logical volumes in the physical volume.

Thanks for good labeling, i can see HOMEVOLUME, USRVOLUME, VARVOLUME, TMPVOLUME so now i know that i need to recover the HOMEVOLUME partition. So quickly I tried to mount the /dev/LVMVOLUME/HOMEVOLUME device but after couple of minutes, I got bad FS type error. I even tried specifying the partition type -- ext3 but with no luck.

I then thought its time for "the best command in linux": dd.

dd /dev/LVMVOLUME/HOMEVOLUME /mnt/homelvm.iso

But it failed, gave some bad block error. Target file was 0 kb!

On further research, i found some switches for dd, to ignore bad blocks and move on:

dd /dev/LVMVOLUME/HOMEVOLUME /mnt/homelvm.iso bs=64k conv=noerror,sync

You might be wondering why i specified block size as 64k, the reason is, if dd encounters a bad block, it will skip, so the block size defines how much to skip, so 64k ensures dd copies as much data as possible but will take lot of time to complete, as opposed to specifying higher block size, which will be fast but recovery wont be that successful.

Anyways so I left it overnight and in the morning i have my 47 GB iso file.

So enthusiastically i tried to mount it:

mount /mnt/homelvm.iso /opt -o loop

But didn't work, gave me unknown file system error.

So then i tired the command:

fsck.ext3 /mnt/homelvm.iso

It started checking the disk for errors, and found lots of them, i had to type yes for all the questions. I should have specified the "assume yes and move on" switch, but didn't want to cancel and take chances so after the file system check completed, i tried to mount the iso image again and VOILA, it returned the prompt quietly (I love Linux when it does this!)

All the files needed were intact, I checked few files, they were okay, there might be some corrupt files, but will find out only when I open them.

Hope this article helps!


Also check out how I fixed the "Couldn't mount because of unsupported optional features (2000200)" error.