ersion do you use?
it is already difficult to say why this strange key appeared -- you have
already run several build-fs runs -- although it may be related to remount
(I remember we used to have some problems before) or to fsck --build-fs.
unmount you fs please and run 'fsck --check' on the unmounted fs -- check
that all is right there now.
which kernel version do you use?
--
Vitaly
. Is
> there any way to restore the filesytem to the previous mountable but
> corrupted state (which would be infinitely more useful)? I imagine
> either finding the root node again or somehow growing the filesystem (as
> I have since found enough space to grow it)
>
> Any help would be useful.
>
> alf
>
>
--
Vitaly
On Tuesday 14 March 2006 22:35, Alain Knaff wrote:
> Vitaly Fertman wrote:
> > Hi Alain,
> >
> > the fixed reiserfsprogs version is attched, it contains
> > some bugfixes, please run it and report about the result.
> >
> > Thank you.
>
> Actually
ally have a larger partition.
>
> P.P.S.:
> The reiserfs-partition was used last with a 2.6.15-1 kernel,
> and fsckreiserfs (see above) was run with a 2.6.14 kernel from Kanotix.
> The reiserfsprogs version was 3.6.19-1. Output of debugreiserfs was the
> following:
--
Vitaly
+found pass) #
> Looking for lost directories:
> lost+found.c 116 _look_for_lost
> not directory found
> Aborted
>
>
> What can we do to retrieve our files?
this seems to be fixed already.
sending the fixed reiserfsprogs version in the next email.
--
Vitaly
> {direntry_create_vi+480}
> {create_virtual_node+817}
> Mar 4 22:32:38 free kernel:{ip_check_balance+839}
> {balance_leaf+10822}
> Mar 4 22:32:38 free kernel:{fix_nodes+547}
> {reiserfs_paste_into_item+301}
> Mar 4 22:32:38 free kernel:
> {reiserfs_add_entry+781}
> {autoremove_wake_function+0}
> Mar 4 22:32:38 free kernel:{reiserfs_rename+489}
> {bh_lru_install+217}
> Mar 4 22:32:38 free kernel:{activate_page+154}
> {wake_up_bit+14}
> Mar 4 22:32:38 free kernel:{search_by_key+4205}
> {vfs_rename_other+196}
> Mar 4 22:32:38 free kernel:{vfs_rename+803}
> {sys_rename+377}
> Mar 4 22:32:38 free kernel:{system_call+126}
> Mar 4 22:32:38 free kernel: ReiserFS: sda1: warning: clm-2100: nesting info
> a different FS
>
>
>
> sincerely,
> zotyalpb
>
>
>
--
Vitaly
would you run:
debugreiserfs -p | bzip2 -c > bz2
and provide the result for downloading? I have an improved reiserfsprogs
version, although it is not a reslease yet, so I prefere to check how it
works on metadata first.
--
Vitaly
am I
correct that an fs grub source sits on, /, (hd0,0), other used fs are not
reiser4 ones?
which files do you have in (hd0,0)/boot/grub/?
--
Vitaly
Please
> note that any views or opinions presented in this e-mail are solely those
> of the author and do not necessarily represent those of ITT Industries, Inc.
> The recipient should check this e-mail and any attachments for the presence
> of viruses. ITT Industries accepts no liability for any damage caused by any
> virus transmitted by this e-mail.
>
>
--
Vitaly
On Thursday 19 January 2006 22:53, Bruce Guenter wrote:
> On Wed, Jan 18, 2006 at 09:34:49PM +0300, Vitaly Fertman wrote:
> > thank you for the report, the attached patch should fix
> > the broken mount options. please try it.
>
> It does indeed fix the problem. What othe
On Tuesday 17 January 2006 21:58, Hans Reiser wrote:
> The result is not expected, Vitaly please look into it.
>
> Hans
>
> Bruce Guenter wrote:
>
> >Hi.
> >
> >I've been running a few tests with reiserfs and tails, and have been
> >unable to
FS RECOVERY IS NOT POSSIBLE.
it looks like it is not reiser4 or probably the partition table got
corrupted or the fs was wiped out somehow. If you need our assistance,
visit www.namesys.com/support.html please.
> So this is (ahem) bad, huh? Am I screwed? Or is there any way to
> recover some of the files?
>
> Thanks for reading!
> Eric P.
>
>
--
Vitaly
cided to restore the
> backup to the original data disk.
>
> After restore, i ran decrypted the whole disk with
> homer ~ # losetup -e aes-256 /dev/loop0 /dev/hdb
>
> and tried to find any reiserfs related info with scan-reiserfs again.
> Result:
>
> homer ~ # ./scan-reiserfs /dev/loop0 1 151324236
> main: 485
> read failed
> errno: Success
>
> Has anyone an idea how to recover the data on that disk?
>
> Thanks in advance,
>
> Marcus
>
>
--
Vitaly
for a while
> now.
grub debugging is needed here, if libreiser4 reads the file correctly.
probably reiser4progs/demos/busy, the 'cp' command, can reveal the
problem too.
> Perhaps I can figure out what's causing this boot problem and fix
> it.
it would be probably better to check first that the problem is not
fixed yet.
--
Vitaly
nd
if he remembers what and how has been installed on a particular system;
> >Final decision will still be Namesys call, but hopefully this whole thread
> >gave
> >them some valuable input to make the best decision.
> >
> >Thanks,
> >
> >Philippe
> >
>
--
Vitaly
obvious, there are badblocks: badblocks.log.
check out www.namesys.com/bad-block-handling.html
> i still can read from damaged partition. when i run `strings /dev/hdc3`
> i get plently of text.
> the question is if there is a way to mount the partition.
> thanks in advance.
> ivan matviyuk.
>
>
--
Vitaly
es and
> > interestingly a web search gave me nothing about it. Or is reiserfstune
> > not to be used for adding bad blocks to the fs?
>
> reiserfstune is supposed to be use for that. You encountered reiserfstune bug.
> We are working on a fix.
>
>
>
--
Vitaly
dif
On Saturday 15 October 2005 16:19, Yiannis Mavroukakis wrote:
> Vitaly Fertman wrote:
>
> >On Friday 14 October 2005 16:07, Raymond A. Meijer wrote:
> >
> >
> >>On Friday 14 October 2005 15:07, Vitaly Fertman wrote:
> >>
> >
t finishes successfully, the problem is in your hardware.
As the same block number repeats and there is also a failed
block read, the problem is likely to be IO related.
it fsck fails on your metadata, I would like to have a look
at part6.bz2.
--
Vitaly
On Friday 14 October 2005 16:07, Raymond A. Meijer wrote:
> On Friday 14 October 2005 15:07, Vitaly Fertman wrote:
>
> [...]
>
> > ok, I will add it.
>
> Vitaly, is it possible to add labels to Reiser4 filesystems AFTER mkfs,
> or only during mkfs?
only on mkfs time for now.
--
Vitaly
t;
> But for me it's nice to have. This way my system behaves in a more consistent
> way.
> Maintainers I asked from my distribution suggested to ask my question at the
> source.
> What is your opinion then, reiserfs people?
ok, I will add it.
--
Vitaly
or you can enlarge the existent hdg1.
Note: some disk space will be added to the current partition, if there was a
reiserfs before, that fs metadata will be mixed with the current fs. to avoid
it, zero the added disk space first (dd if=/dev/zero ...)
--
Vitaly
lp and information!
>
>
> Lance
>
> Vitaly Fertman wrote:
>
> >On Wednesday 05 October 2005 01:46, Lance Reed wrote:
> >
> >
> >>Thanks for the info!
> >>
> >>I have tried this. I made the new 3.6.19 code.
> >>Ran a --rebuild-s
#
> Replaying journal..
> Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions
> replayed
> reiserfs_open_ondisk_bitmap: wrong either bitmaps number,
> count of blocks or blocksize, run with --rebuild-sb to fix it
> reiserfsck: Could not open bitmap
&
this
> file is for. Perhaps moving this a file to /tmp is a better way to go
> but there may be reasons not to do this, either.
>
>
> i downloaded the equivalent SRPM from fedora core 4 and it "just built"
> using their spec file so i didn't put much more effort into fixing the
> problem myself, but i thought you'd be interested to know about this.
yes, thank you, I will check it.
--
Vitaly
gt; Oct 3 20:25:30 livestore2 kernel: Code: f3 af 74 09 33 47 fc 83 ef 04
> 0f bc d0 29 df c1 e7 03 01 fa
> Oct 3 20:27:36 livestore2 sm-notify[3328]: Unable to notify
> 192.168.103.4, giving up
> Oct 3 20:27:36 livestore2 sm-notify[3328]: Unable to notify
> 192.168.103.3, giving up
>
> livestore2:~ #
> livestore2:~ # tail -f /var/log/messages
> Oct 3 20:25:30 livestore2 kernel: [filp_open+40/80] filp_open+0x28/0x50
> Oct 3 20:25:30 livestore2 kernel: [] filp_open+0x28/0x50
> Oct 3 20:25:30 livestore2 kernel: [sys_open+77/144] sys_open+0x4d/0x90
> Oct 3 20:25:30 livestore2 kernel: [] sys_open+0x4d/0x90
> Oct 3 20:25:30 livestore2 kernel: [sysenter_past_esp+82/121]
> sysenter_past_esp+0x52/0x79
> Oct 3 20:25:30 livestore2 kernel: []
> sysenter_past_esp+0x52/0x79
> Oct 3 20:25:30 livestore2 kernel:
> Oct 3 20:25:30 livestore2 kernel: Code: f3 af 74 09 33 47 fc 83 ef 04
> 0f bc d0 29 df c1 e7 03 01 fa
--
Vitaly
On Wednesday 28 September 2005 21:57, Fionn Behrens wrote:
> On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote:
>
> > remember that reiser4progs-1.0.4 supports both formats, in other words
> > having the format updated to the new one, you are able to use new
> > ke
On Wednesday 28 September 2005 19:28, Fionn Behrens wrote:
> On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote:
>
> > > 2.6.11 refused to boot the
> > > root partition, claiming that there were an inconsistency in the FS.
> >
> > the disk format got n
incorporation
> in the kernel) will be up for a not-so-nice surprise. And I did not see
> a warning anywhere on namesys.com as well!
>
> Now, would someone please tell me where I can find a reiser4 patch that
> works as stable and surprise-free as your code back then in the old ages
> of 2004 and that can be applied to 2.6.13?
> Please? Or would I have been better off using XFS from the beginning?
>
> Congratulations to all who read the whole story.
>
> Thanks to everyone who will answer any of my questions.
>
> best regards,
> Fionn
>
> P.S.: How do I switch back that annoying "corruption bit"?
> Run another "read-only" check?
--
Vitaly
of the correct SB is on 64K + 52 bytes offset.
if you need our assistance here please visit:
www.namesys.com/support.html
> Thanks for Your help
> Markus Hiereth
>
> Braunschweig, Germany
>
>
--
Thanks,
Vitaly Fertman
lication writers who
> >>> want to try to ride through or write automated "HA" recovery scripts
> >>> for systems with large numbers of occasionally flaky IO devices ;-)
> >>
> >>
> >>
> >> If you'd like to form a committee to
or User-Mode Linux) on a reiserfs filesystem, and
> then had a hardware failure bad enough that the fsck had to try to
> rebuild the b-tree, I take it?
loop device XOR encryption for your images is the simple solution
for reiserfs V3.
--
Thanks,
Vitaly Fertman
at
> I should expect?
it depends on the amount of data kept on the fs and average
file size, 3h-10h.
> I'm sorry if I rambled or left off any important information, but TIA
> for any help with these questions. I'd be happy to add any
> information requested.
>
--
Thanks,
Vitaly Fertman
On Wednesday 24 August 2005 01:30, Konstantin Münning wrote:
> Hi Vitaly!
>
> Thank you for the reiserfsck 3.9.20. It in fact had different results on
> that drive. I had it run in gdb (as I did with 3.6.19 to see what/where
> the trouble may be) and the result is:
>
> (**
an lower chances
to lose data.
> Can this be suspended (ctrl ^Z)?
yes, no problem.
--
Thanks,
Vitaly Fertman
ion start), make a raw backup of the
device (dd, dd_rescue) before rebuilding. then proceed with the
wanted blocksize (512-8K, probably the default is the correct one)
and rebuild the journal header if needed.
> I've
> been running this filesystem for two years with that block size, and
> am not ready to give up the data on it just yet :-).
> Thanks for any help with this problem, and also for the wonderul file
> system :-).
> Alphanos
>
>
--
Thanks,
Vitaly Fertman
On Monday 15 August 2005 18:11, Vanuxem Grégory wrote:
> Le lundi 15 aoШt 2005 Ю 17:48 +0400, Vitaly Fertman a Иcrit :
> > > > where have you installed libaal into? /usr/local?
> > > > does you /etc/ld.so.conf have the path you instatlled libaal into?
> > > >
ur computer to test it?
> That works only in a chrooted 32bits environment
> (I have a x86_64)
what distro?
--
Thanks,
Vitaly Fertman
1.0.5.tar.gz?
>
> Yes, sure
where have you installed libaal into? /usr/local?
does you /etc/ld.so.conf have the path you instatlled libaal into?
if not, add it and run /sbin/ldconfig.
--
Thanks,
Vitaly Fertman
tData, insertion was skipped
> vpf-10260: The file we are inserting the new item (557044 557073 0x1 IND
> (1), len 4, location 4092 entry count 0, fsck need 3, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (558483 558492 0x20001
> IND (1), len 96, location 4000 entry count 0, fsck need 1, format new)
> into has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (759159 759160 0x1 IND
> (1), len 3208, location 888 entry count 0, fsck need 1, format new) into
> has no StatData, insertion was skipped
> left 32022, 500 /sec
>
>
>
--
Thanks,
Vitaly Fertman
not
ready yet.
--
Thanks,
Vitaly Fertman
didn't try to abort and start again (yet) as it takes about 20
> hours to get so far (the device is big and not so fast) so I'm still
> hoping it may finish by itself...
there are some optimizations ready for the pass2.
if fsck fails to recover the fs, gets out of disk space, etc,
email me and I will send you the optimized reiserfsprogs version.
> So, is it worth investigating and if, what other info I could provide?
> If nobody is interested I will create a fresh FS on the drive and forget
> about it. I have my important data so that would be OK.
>
> Keep doing the great job!
> Konstantin
>
>
--
Thanks,
Vitaly Fertman
x batch size 900 blocks
> Max commit age 30
> Blocks reserved by journal: 0
> Fs state field: 0x0:
> sb_version: 2
> inode generation number: 0
> UUID: 10ae60ee-1abb-49d1-ae55-cf238626c0b5
> LABEL:
> Set flags in SB:
> ATTRIBUTES CLEAN
>
> Super block seems to be correct
>
>
>
> Something seems seriously wrong here.
> I'm happy to run any tests or try any patches, this system is mine to play
> with
> until the end of the month.
>
>
> Paul Slootman
>
>
--
Thanks,
Vitaly Fertman
become invalid for disk reiser4 being once mounted in the
> > kernel/reiser4 of version >= A.
> >
> > Is it okay?
> > Perhaps introducing a special sub-versions of reiser4/reiser4progs for
> > upgrading
> > the plugin table will improve the situation..
the reiser4progs obtained from
ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.4-1.tar.gz
contain the fix to handle the extended plugin table correctly.
--
Thanks,
Vitaly Fertman
AIL PROTECTED]:~/scratch> touch fifu
> [EMAIL PROTECTED]:~/scratch> rm *fu fi*
> rm: cannot remove `fifu': No such file or directory
>
> Your file either somehow got removed before rm got to it, or rm somehow
> got to it twice. Vitaly, can you look at the error handling b
On Tuesday 28 June 2005 01:07, David Masover wrote:
> Vitaly Fertman wrote:
> > On Friday 24 June 2005 23:46, Hans Reiser wrote:
> >
> >>David Masover wrote:
> >>
> >>
> >>
> >>>
> >>>I was able to recover from bad blocks,
I agree on that Ted.
> >
> >
> > Perhaps before moving to V4, reiser4progs-1.04 (the most recent I
> > think) could be made to compile with gcc4/fedora core 4 system, and
> > some of the warnings cleaned up. There are a fair lot of them - all
> > the same warnings
On Friday 24 June 2005 23:46, Hans Reiser wrote:
> David Masover wrote:
>
>
> >
> >
> > I was able to recover from bad blocks, though of course no Reiser that I
> > know of has had bad block relocation built in...
>
> there was a patch so
th transition here?
yes, the patch is being tested.
> Update the tools, do something light and off we go or will we
> need to mkfs?
>
> Spatsibo!
>
--
Thanks,
Vitaly Fertman
dge, the hard disk
> or cable (since i can do a full dd of the hard disk to /dev/null).
>
> Anyone interested in taking a look at it, or should i just write it off
> as stray gamma rays from Saturn and trash it? :-)
>
--
Thanks,
Vitaly Fertman
ck say?
we handle hardware problems under
www.namesys.com/support.html terms.
--
Thanks,
Vitaly Fertman
On Thursday 09 June 2005 12:01, Greg Burri wrote:
> Vitaly wrote:
>
> >>Hi !
> >>I have done "debugreiserfs -p" to collect metadata .. .I take me about
> >>15 hours but its ok.
> >>I have put the file here :
> >>ht
On Tuesday 07 June 2005 15:01, Adrian Ulrich wrote:
> Hi Vitaly,
>
> > there was a format change to work with encryption plugin in
> > -5 reiser4 patch. progs do not have its support yet. grub works
> > through the progs code so its the same problem, mkisofs is not
&
e (411211), item
> (0), unit (0). The whole subtree is skipped.
there was a format change to work with encryption plugin in
-5 reiser4 patch. progs do not have its support yet. grub works
through the progs code so its the same problem, mkisofs is not
relevant here.
--
Thanks,
Vitaly Fertman
> unknown GNU/Linux
>
> * I attached the Syslog output
> * I rand 'debugfs.reiserf -P $device' and can
> provide the output to namesys if they need it
> (9.3 MiB)
>
--
Thanks,
Vitaly Fertman
back
to its own place.
> system boots from a scsi disk, that has nothing to do with the LVM
> except booting and mounting it .
>
> What should I do before I pay you to work out a solution.
>
> thanx.
>
> kind regardes,
>
>
> Matthias.
>
>
>
--
Thanks,
Vitaly Fertman
> (Yes/No): no
> diablo:~#
would you try this patch for libaal-1.0.4?
--
Thanks,
Vitaly Fertman
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/21 13:15:23+03:00 [EMAIL PROTECTED]
# use BLKBLKGETSIZE & BLKGETSIZE6464 defines
#
# file.c:
#
gt; running fsck on it.
>
> How do you sugest I swap a hd in a LVM raid with already data on it ?
dd_rescue hd to a relable one & change lvm according to the change.
if you need our assistance please use our www.namesys.com/support.html
service.
--
Thanks,
Vitaly Fertman
blocks, you know that the number will not
change soon, in other words other blocks are relable.
first of all you even have not complete badblocks run, so you cannot
be sure you know the full bad block list.
and the second, if your hardware is dying you need to fix it before
running fsck on it.
--
Thanks,
Vitaly Fertman
12: reiserfsprogs: Typo in reiserfstune manpage
>
> Package: reiserfsprogs
> Version: 1:3.6.19-1
> Severity: minor
>
> The manpage describes reiserfstune as a "tunning" tool.
Thanks, fixed.
-- Vitaly Fertman
В сообщении от Пятница 27 Май 2005 19:07 Flavien Bridault
написал(a):
> Le vendredi 27 mai 2005 à 15:11 +0400, Vitaly a écrit :
> > В сообщении от Четверг 26 Май 2005 23:36 Flavien
> > Bridault написал(a):
> > > Hi people,
> > >
> > > I searched a
> Hi !
> I have done "debugreiserfs -p" to collect metadata .. .I take me about
> 15 hours but its ok.
> I have put the file here :
> http://www.euphorik.ch/boardel/debugreiserfs_metadata.bz2 (23Mo)
unfortunately I have failed to unpack metadata, they got corrupted
somehow, but I see at least th
e report. your patch creates different static variables
in each c file that includes the header. please try the attached patch.
-- Vitaly
= plugin/key/key_large/key_large.c 1.44 vs edited =
--- 1.44/plugin/key/key_large/key_large.c Mon Jan 17 16:17:03 2005
+++ edited/plugin/key/key_large
m I doing wrong (because I suppose that this problem can
> be solved but I don't know how)
> I have googled but no similar incident has been reported.
>
> Thank in advance
>
>
> M. A. Herrero.
>
>
>
--
Thanks,
Vitaly Fertman
e on
> on this matter.
>
> Thanks,
> Giovanni.
>
>
>
> --
>
>
> --
> --
>
> Check FT Websites ... http://www.futuretg.com - ftp://ftp.futuretg.com
> http://www.FTLinuxCourse.com
> http://www.FTLinuxCourse.com/Certification
> http://www.RPMParadaise.org
> http://www.YourPersonalOperatingSystem.com
>
> Mobile: +39 393 665 4239
> Lancelot is back!
--
Thanks,
Vitaly Fertman
.bz2
and provide them for downloading.
> (hpt374 is the driver for my sata-card)
> My partition was in good health but a day I don't know why I had this
> message when I was mounting /dev/sda1 ...
> I already try reiserfsck but without success :'( I don't know what can I
> do to repair that.
>
> Please help me,
> Thx
>
> Greg Burri
>
>
--
Thanks,
Vitaly Fertman
On Friday 29 April 2005 13:11, Chris Wakefield wrote:
> Hi Vitaly.
>
> Thanks for your reply.
>
> I tried every reasonable combo:
> apt-get source grub ... patched it with LATEST_PATCH ...that wouldn't compile
> with or without the patch,
> grub-0.95,
> grub
failed program was: | /* confdefs.h. */" ..
>
> This is happening only with reiser4 grub, as I'm able to compile kernels and
> who knows what else .. it's just this source only.
> Do I require a different source or do I have to compile reiser4 grub in a 32
> bit chroot environment?
what does the plain grub-0.96 without reiser4 patch say?
--
Thanks,
Vitaly Fertman
> reboot won't work, as the partition would not unmount.
only 4k blocksize seems to work now. fix is being prepared.
--
Thanks,
Vitaly Fertman
On Saturday 19 March 2005 21:03, Jindrich Makovicka wrote:
> Vitaly Fertman wrote:
> > On Friday 18 March 2005 21:59, Jindrich Makovicka wrote:
> >
> >>Vitaly Fertman wrote:
> >>
> >>>>so 1.0.3 & 1.0.4 bail out. Using fsck.reiser4 --build-sb f
On Friday 18 March 2005 21:59, Jindrich Makovicka wrote:
> Vitaly Fertman wrote:
> >>so 1.0.3 & 1.0.4 bail out. Using fsck.reiser4 --build-sb from
> >>reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable,
> >
> >
> > fsck.reiser4 --
eiser4utils:
>
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking for _LARGE_FILES value needed for large files... no
>
> I've included a log for just for libaal.
would you apply this patch instead of the previous one to libaal.
--
Thanks,
Vitaly Fertma
and it could only make a 2.8TB partition.
>
> Regards,
> Naveen Nathan
--
Thanks,
Vitaly Fertman
Hello,
what your configure tells about _FILE_OFFSET_BITS &
_LARGE_FILES? if it cannot detect the right value, probably
the attached patches for configure.in would help.
--
Thanks,
Vitaly Fertman
On Sunday 13 March 2005 12:13, Naveen Nathan wrote:
> Hey Reiser team & fellow R
-0.4.so.18 (0x4cd45000)
> libaal-0.4.so.13 => /usr/lib/libaal-0.4.so.13 (0x4ccef000)
> libuuid.so.1 => /lib/libuuid.so.1 (0xb7f28000)
> libncurses.so.5 => /lib/libncurses.so.5 (0xb7ed1000)
> libreadline.so.4 => /lib/libreadline.so.4 (0x467e6000)
> libc.so.6 => /lib/libc.so.6 (0xb7da8000)
> /lib/ld-linux.so.2 (0xb7f47000)
please update your libaal & reiser4progs to the latest version.
(ftp://ftp.namesys.com/pub/reiser4progs/)
--
Thanks,
Vitaly Fertman
but it didn't help either, and subsequent fsck also
> botched the filesystem. Were there any fixes in 1.0.4 regarding this?
--
Thanks,
Vitaly Fertman
On Monday 21 February 2005 16:10, Ookhoi wrote:
> On Sun, Feb 20, 2005 at 01:44:41PM +0300, Vitaly Fertman wrote:
> > The new reiser4progs package is available on our ftp
> > site (ftp://ftp.namesys.com/pub/reiser4progs/).
>
> Thank you for this release. It doesn't cr
`int' in declaration of `__tmp'
> format40.c:255: warning: initialization makes integer from pointer
> without a cast
--
Thanks,
Vitaly Fertman
ftp://ftp.namesys.com/pub/reiser4progs/grub
--
Thanks,
Vitaly Fertman
On Friday 18 February 2005 17:08, Ookhoi wrote:
> On Fri, Feb 18, 2005 at 04:19:59PM +0300, Vitaly Fertman wrote:
> > On Friday 18 February 2005 11:31, Ookhoi wrote:
> > > Are new reiser4progs available? I can only find 1.0.3 as newest,
> > > but that version is au
On Friday 18 February 2005 17:08, Ookhoi wrote:
> On Fri, Feb 18, 2005 at 04:19:59PM +0300, Vitaly Fertman wrote:
> > On Friday 18 February 2005 11:31, Ookhoi wrote:
> > > Are new reiser4progs available? I can only find 1.0.3 as newest,
> > > but that version is augus
ee if it helps.
> Kernel is 2.6.11-rc3-mm2.
>
> I'll read the archives so please reply to the list. Thanks in advance.
>
> With kind regards, Sander
--
Thanks,
Vitaly Fertman
dditional patches are needed for running reiser4 on sparc64.
> They not yet included into -mm kernels. I am attaching them to this
> e-mail.
and at least these 2 patches needs to applied also.
--
Thanks,
Vitaly Fertman
diff -rup libaal-1.0.3/include/aal/Makefile.am libaal-1.0.3-1/include/aal/M
ee.
so you can try to recover from the whole partition on the copy. Have
you made fs/partition backup before rebuild-tree (probably fdisk)?
If no, make a copy of the hda6 partition and run
reiserfsck --rebuild-tree -S -l logfile
if yes, copy it back to hda6 and run on hda6.
--
Thanks,
Vitaly Fertman
> > > > On Thursday 10 February 2005 22.03, Vitaly Fertman wrote:
> > > > > > > > reiserfsck 3.6.13
> > > > > > > > I used -S to scan the whole partition, as per man page
> > > > > > > > A bug heh.. :(
>
On Monday 14 February 2005 19:38, Laurynas Biveinis wrote:
> Cituojant Vitaly Fertman <[EMAIL PROTECTED]>:
> > > [EMAIL PROTECTED] ~]# mkfs -t reiserfs /dev/hda6
> >
> > did you shrink ntfs under win and reboot?
>
> NTFS was shrinked several reboots ago
On Monday 14 February 2005 17:40, Laurynas Biveinis wrote:
> Hello,
>
> Cituojant Vitaly Fertman <[EMAIL PROTECTED]>:
> > reboot is required between repartitioning a drive and starting to use
> >
> > moved/created partitions. without that the kernel may continue t
a6: replayed 17
> transactions in 0 seconds
> Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: Using r5 hash to
> sort names
> ---
>
> And one more line looks particularly interesting:
> -------
> Feb 13 18:08:05 laurynas-pc kernel: ReiserFS: hda6: warning: vs-4080:
> reiserfs_free_block: free_block (hda6:32998)[dev:blocknr]: bit already
> cleared
> ---
>
> Is there anything I can do to look for my other missing data?
--
Thanks,
Vitaly Fertman
On Monday 14 February 2005 14:24, Rikard Johnels wrote:
> On Friday 11 February 2005 08.57, Rikard Johnels wrote:
> > On Thursday 10 February 2005 22.03, Vitaly Fertman wrote:
> > > > > > reiserfsck 3.6.13
> > > > > > I used -S to scan the whole par
hash to sort names
>
> Could you give me a technical describtion why this worked?
the kernel found an ext2 magic somewhere in the first 64K,
reiserfs keeps the super block on 64K offset, so ext2 one was
not overwritten by rebuild-sb. this is why it was mounted as ext2.
but why the kernel refused to mount as reiserfs when was explicitely
specified -- this is a bug.
--
Thanks,
Vitaly Fertman
-3.6.19.tar.gz
>
> Same problem:
>
> lost+found.c 348 pass_3a_look_for_lost
> look_for_lost: The entry 'lost+found' could not be found in the root
> directory Aborted
>
> This is getting more than frustrating...
would you pack the metadata with
debugreiserfs -p | bzip2 -c > -meta.bz2
and provide them for downloading?
--
Thanks,
Vitaly Fertman
eck
> # reiserfsck -y /dev/loop/0 --rebuild-tree
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
> # reiserfsck -y /dev/loop/0 --rebuild-tree -S
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2
>
> Use ftp://80.133.138.104:12121
sorry, but I get 'no route to host' every time.
--
Thanks,
Vitaly Fertman
s option after __this__ reiserfsck --rebuild-tree? Not
> > after the following ones?
>
> Let me explain my mode of operation: I make a copy of the original image
> taken of the harddrive. Then I use 'losetup' or 'mount -o loop' in order to
> mount the image as device. Next I perform different operations using
> 'reiserfsck'. Above you see _one_ possiblity. Then I mount the image as
> filesystem using 'mount -o ro /dev/loop/0 /mnt/temp1/', and, as I described
> below, I get no directories or files. Mounting with '-t reiserfs' always
> result in following output:
>
> mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
>or too many mounted file systems
after rebuilding the tree, does 'reiserfsck --check ' see these files?
do you have a reiserfs support in the kernel?
what if you zero the first 64K with
dd conv=notrunc if=/dev/zero of= bs=4096 count=16
can you mount it now? (rebuild-tree should already complete by the mount time).
do you have anything related in the syslog about the mount time?
--
Thanks,
Vitaly Fertman
On Thursday 10 February 2005 00:19, Peter Klotz wrote:
> I attached a patch that fixes a few typos in reiser4progs 1.0.3.
Thanks a lot, applying it.
Vitaly Fertman
eed (the data on it is not particularly
> sensitive) but of course it's hard to send the full 600GB worth of raw data
> :)
>
> Thank you very much for any help you can provide.
let's try to pack the fs metadata with:
debugreiserfs -p | bzip2 -c > -meta.bz2
they probably will be not so large for downloading.
--
Thanks,
Vitaly Fertman
On Monday 07 February 2005 18:58, Michael Styer wrote:
> On Monday, 07 February, 2005 10:38 AM Vitaly Fertman wrote:
> > On Saturday 05 February 2005 19:31, Michael Styer wrote:
> >> OK. So I killed everything that was keeping /usr busy and unmounted it.
> >> I ran d
On Saturday 05 February 2005 19:31, Michael Styer wrote:
> On Fri, 4 Feb 2005, Vitaly Fertman said:
> > so what I do not understand is why reiserfsck does not report any
> > problem to you. Which reiserfsprogs do you have? have you 'umount &
> > mount ro' or &#x
On Wednesday 02 February 2005 19:25, Michael Styer wrote:
> On Wed, 2 Feb 2005 19:10:15 +0300, "Vitaly Fertman" <[EMAIL PROTECTED]>
>
> said:
> > would you pack the metadata with debugfs.reiser4 -P |
> > bzip2 -c > .bz2 and let us to download them
to this:
>
> Feb 2 03:19:31 apollo reiser4[rsync(17957)]: key_warning
> (fs/reiser4/plugin/object.c:97)[nikita-717]:
> Feb 2 03:19:31 apollo WARNING: Error for inode 483238 (-2)
>
> The only difference between the messages is the process name and pid,
> and the inode number (well, and the date and time, obviously).
>
> Does that help?
would you pack the metadata with
debugfs.reiser4 -P | bzip2 -c > .bz2
and let us to download them?
--
Thanks,
Vitaly Fertman
: 2.6.8.1
>
> Host: linux-i686
> Target: linux-mipsel
> Compiler: gcc 3.3.4
> compilation flags:
> -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2
trying to reproduce it.
what packages for mipsel cross compiling have you installed?
probably some cross headers are needed also...
--
Thanks,
Vitaly Fertman
1 - 100 of 283 matches
Mail list logo
