similar to: EXT3 Superblock Recovery

Hi, originally I posted this to linux-raid@vger.kernel.org, but I guess there are chances that someone in here might comment on it as well. TIA. * Neil Brown <neilb@cse.unsw.edu.au> [2003-03-20 10:58]: > On Thursday March 20, lists@schlich.org wrote: > > > > And when I try to mount the array: > > --8<-- > > EXT3-fs error (device md(9,1)):

Hi list, i want to use cryptoloop functionality to encrypt a Filesystem. Here my setup. [root at kingcoco root]# uname -a Linux kingcoco 2.4.21-20.EL.c0 #1 Thu Sep 9 02:07:03 EDT 2004 i686 i686 i386 GNU/Linux [root at kingcoco root]# mount -V mount: mount-2.11y is this setup ok, or have i to update my userspace-tools. thx for the feedback... __________________________________ Do you

Hi, I have a legacy AES excrypted file system with a 256 key size. RHEL kernel is cryptoloop enabled but the losetup package is not. It needs additional patch. Does anybody have a patched losetup rpm I could use? Thank you! A. Georgiev

I am unable to mount an ext3 filesystem on RHEL AS 2.1. This is not the boot or root filesystem. When I try to mount the file system, I get the following error: mount: wrong fs type, bad option, bad superblock on /dev/sdj1, or too many mounted file systems When I try to run e2fsck -vvfy /dev/sdj1 I get the following error: Group descriptors look bad... trying backup blocks...

Hi all, i'm new in the list so i'm sorry if this i'm posting is off-topic or it was already answered before. I'm having this problem; i've got an ext3 8GB partition and it doesn't mount, the cause of this: a user (yes me!) running fsck.ext3 with the filesystem mounted, ups! (snif, forgive me!!, totally newbie and mad) errors while booting: EXT3_fs error (device hda4):

Hello all, I just installed a new beta kernel from Dzickus over at redhat. Rebooting causes this, no matter what kernel I boot from: EXT3-fs error: device dm-0: ext3_check_descriptors: Block bitmap for group 5008 not in group (block 167772160)! EXT3-fs: group dexcriptors corrupted! Mount: error mounting /dev/root on /sysroot as ext3: Invalid argument Setuproot: /moving /dev failed: no such

On Sep 17, 2012, at 9:13 AM, Tomas Minac <minac.tomas at gmail.com> wrote: > Hi Andy, > > thank you for your respond, > > On 09/06/12 21:32, Andrew Trick wrote: >> >> On Sep 4, 2012, at 9:05 AM, Tomas Minac <minac.tomas at gmail.com> wrote: >> >>> >>> Hello, >>> >>> I am member of research team on our Faculty

Hi, I am using kernel 2.6.15.4. On my system, I first created a partition with EXT3 and put some data on it. Later, I deleted the partition, and re-created another partition with the same starting block number and a higher ending block number. I intended to format it with another filesystem, but surprisingly (or maybe just to me), the superblock of the partition had not changed. I could still

On Sep 4, 2012, at 9:05 AM, Tomas Minac <minac.tomas at gmail.com> wrote: > > Hello, > > I am member of research team on our Faculty of Information Technology (university VUT in Brno Czech Republic). We use LLVM for many projects and actually we want to create system, which will be able compile and profile aplication for VLIW processors in few iterations. > We want to load

Last time I asked here about superblocks (which we were using in the first version of ThreadSanitizer instrumentation) Tobias Grosser has suggested to use RegionInfo: did you have a look at the RegionInfo pass? It currently detects some kind of refinded SESE regions. I use them in Polly and as far as I know the Intel OpenCL SDK also uses them in some way. It is not SEME, but it may

BTRFS file systems will be corrupted on 6.02 (mainstream) and some previous versions. DYNAMIC_DEBUG makes the core larger than the allowed. Even before its introduction, building Syslinux with DEBUG_PORT enabled would probably corrupt BTRFS images (IIRC) *if* ldlinux.sys surpasses the maximum allowed size. Besides, the installer isn't safe at all... The check could be easily made there to

It recently occurred to me, as I was partitioning a RAID with fdisk, that when I built the system, I was presented with a graphical utility that "magically" created the partitions. Now, using fdisk, I was reminded of being given superblocks. Although I haven't used data recovery techniques using superblocks, is there a way to retrieve the superblock numbers the OS has assigned

Hi Andy, thank you for your respond, On 09/06/12 21:32, Andrew Trick wrote: > > On Sep 4, 2012, at 9:05 AM, Tomas Minac <minac.tomas at gmail.com > <mailto:minac.tomas at gmail.com>> wrote: > >> >> Hello, >> >> I am member of research team on our Faculty of Information Technology >> (university VUT in Brno Czech Republic). We use LLVM for

Hello, I am member of research team on our Faculty of Information Technology (university VUT in Brno Czech Republic). We use LLVM for many projects and actually we want to create system, which will be able compile and profile aplication for VLIW processors in few iterations. We want to load profile information in 'opt' part of LLVM and use it for create superblocks. Note, when

MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators; the MIPS backend also marks conditional branches as terminators. The MachineBasicBlock then has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB. So it seems to me that an MBB is a kind of superblock, single entrance and multiple side

I've been trying to use fsck to recover a corrupted filesystem. It appears the original superblock is corrupted too, as it has an inode count of 0. When I start fsck with -b 32760, it uses the alternate superblock and proceeds. However, it restarts from the beginning a couple of times and after the second restart it doesn't use the alternate superblock, stopping instead as it can't

Hi again, I have the following scenario: I've got a partition which has exactly 14659312 blocks: $ fdisk -l /dev/hda Disk /dev/hda: 28.5 GB, 28520497152 bytes 255 heads, 63 sectors/track, 3467 cylinders Units = Zylinder of 16065 * 512 = 8225280 bytes Ger?t Boot Start End Blocks Id System (...) /dev/hda4 1643 3467 14659312+ 83 Linux (...)

__CHECK_ENDIAN__ isn't on by default presumably because it triggers too many sparse warnings for correct code. But virtio is now clean of these warnings, and we want to keep it this way - enable this for sparse builds. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- It seems that there should be a better way to do it, but this works too. drivers/block/Makefile | 1

When I originally posted my question under ( C-c C-c does not kill data editor), I thought that it was a problem with ESS rather than R. However, I have tried to do the same from a command line R (R 1.8.1 (2003-11-21). on a debian testing i386 machine) and I got the same problem. Specifically I cannot kill the DataEntryWindow by issuing C-c (control c). However, unless I issue the C-c command the

(depends on Advance Storage Configuration patch) This patch adds the option of requesting, at install time, that swap LVs be encrypted. The modifications include: * Introduction of the ovirt_swap_encrypt install parameter * Inclusion of all required packages * Inclusion of required kernel modules * Introduction of /etc/ovirt-crypttab to hold encrypted swap configuration (Couldn't use