Users online right now: 101 - Login  » search  » forum index  

Corrupted slaxsave.dat after crash:help to recover

joex
wrote 4 years ago


reply
Hi all.
I've had a crash this morning and I've had to poweroff my notebook without regular shutdown cause system didn't respond...
Then I've try to boot the system but slaxsave.dat was unmontable... and slax was booted in "fresh mode".

I've saved corruted slaxsave.dat image and then I've try to recover it:

xfs_check said:

ERROR: The filesystem has valuable metadata changes in
a log which needs to be replayed. Mount the filesystem
to replay the log, and unmount it before re-running
xfs_check. If you are unable to mount the filesystem,
then use the xfs_repair -L option to destroy the log
and attempt a repair.
Note that destroying the log may cause corruption --
please attempt a mount of the filesystem before doing
this.


So I've tried to mount it without any succsess...
Then Ive tried to use xfs_repair -L as sugested.
Now I can mount and use slaxsave.dat, yes...
...But seems this command has cancelled some data:
There are missing packages regularly installed before the crash. Seamonkey hasn't extensions installed any more.
And so on...

Yes, I know the solution shuold be the holy backup, I've also done it but only for sensible data and not for all the system slaxsave.dat.

Now I would ask you if you know any other way to try to recover slaxsave.dat.
I've have now a backup of the corrupted slaxsave.dat and the copy of it fixed with xfs_repair but affected by data loss, as described above.
Thanks in advance.
Bye.
 
burninbush
wrote 4 years ago


reply
Well ... I'm not sure this will do you any good, but the way to explore inside it is to loop-mount the filesystem. Boot to always fresh, and

#mkdir temp
#mount -o loop slaxsave.dat temp

and then you can browse inside it, via temp, maybe.

Suggest that in the future you make important config changes and additions by making modules. My theory is, you should be able to run your preferred setup without using any changes file. Poop happens, sooner or later.
 
francois.e
wrote 4 years ago


reply
@BB:

This is wisdom it seems, even for slax hdd install (poor man install type, not full install). This happened to me even with the fromhd cheatcode.

So if I understand, once and a while you do some kind of total backup in addition to relying on the changes cheatcode option^
 
burninbush
wrote 4 years ago


reply
So if I understand, once and a while you do some kind of total backup in addition to relying on the changes cheatcode option^ >francois.e

++++++++++++

No ... what I do here, starting with a fresh new slax, is to start it up in always fresh mode, do some configs, and then a dir2lzm /mnt/live/memory/changes z1-config.lzm. Then move that to /modules and reboot. Then make some more changes and do it again, z2-config.lzm, etc, etc. After several iterations of that, I'll have it in near final form, completely usable or near it, with no changes file at all.

The thing is, none of the xxx.lzm files that makeup the bulk of slax is ever opened for writing by the system -- you can turn off the power to shut down just as if it were a calculator, and they won't be damaged because they were only read, never written-to.

Then finally, enable a slaxsave.dat, but it will only contain minor tweaks, stuff I can lose without any pain.
 
joex
wrote 4 years ago


reply
burninbush wrote:
Well ... I'm not sure this will do you any good, but the way to explore inside it is to loop-mount the filesystem. Boot to always fresh, and

#mkdir temp
#mount -o loop slaxsave.dat temp

and then you can browse inside it, via temp, maybe.


Well.. at this point there's no need to boot in always-fresh mode.
Now I've a slaxsave.dat file affected by data loss, but working... I'm writing and working from within this system. Morever I've an other slaxsave.dat, corrupted and apparently unmontable, but I think it still countains all data. It is the backupped slaxsave.dat (corrupted) file I made yesterday morning before try to recover with "xfs_repair -L" command:
root@slax:~# ls /mnt/sdb2/slax-related/*corrupt
/mnt/sdb2/slax-related/20100728-slaxsave.dat-corrupt


I mean I can still work on that backupped file tring to recover data from it.
Obviously I'll copy that backupped file to an other one and leave the first as is now.
Hope situation is clear, I have:
1- slaxsave.dat restored and running countaining my most configurations etc.. I'm working from it.
2- 20100728-slaxsave.dat-corrupt the backup of corrupted (not restored) slaxsave.dat
3- 20100728-slaxsave.dat-testing an other copy of the backup (2). I can try to recover this one.

Your suggest is to mount the 3rd slaxsave.dat copy and browse it. But I can't mount it because filesystem seems really compromised. That is the matter...
I'm tring to access to filesystem but doesn't seem so simple as you described.
I'll try with dmesg and "man mount", reporting some operations in following code tag.


root@slax:/mnt/sdb2/slax-related# mount -o loop 20100728-slaxsave.dat-testing /tmp/mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop30,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

root@slax:/mnt/sdb2/slax-related# dmesg|tail -n 5
PPP Deflate Compression module registered
ACPI: EC: non-query interrupt received, switching to interrupt mode
l2cap_recv_acldata: Unexpected start frame (len 421)
XFS: Filesystem loop30 has duplicate UUID - can't mount
XFS: Filesystem loop30 has duplicate UUID - can't mount

root@slax:/mnt/sdb2/slax-related# mount -o loop,nouuid 20100728-slaxsave.dat-testing /tmp/mnt
root@slax:/mnt/sdb2/slax-related# dmesg|tail -n 54
XFS mounting filesystem loop30
Starting XFS recovery on filesystem: loop30 (logdev: internal)
Filesystem "loop30": XFS internal error xfs_btree_check_sblock at line 307 of file fs/xfs/xfs_btree.c. Caller 0xc02e6aac
Pid: 28311, comm: mount Tainted: P 2.6.27.27 #1
[] xfs_btree_check_sblock+0x5b/0xd0
[] xfs_inobt_lookup+0x1ac/0x470
[] xfs_inobt_lookup+0x1ac/0x470
[] kmem_zone_zalloc+0x28/0x60
[] kmem_zone_zalloc+0x28/0x60
[] xfs_difree+0x268/0x630
[] xfs_ifree+0x60/0x140
[] xfs_trans_ijoin+0x2b/0x70
[] xfs_inactive+0x212/0x4f0
[] xfs_imap_to_bp+0x91/0x110
[] xfs_fs_clear_inode+0x7a/0xc0
[] invalidate_inode_buffers+0x15/0x70
[] clear_inode+0x59/0xe0
[] generic_delete_inode+0x10a/0x130
[] iput+0x3e/0x50
[] xlog_recover_process_iunlinks+0x411/0x440
[] xfs_iget_core+0x353/0x570
[] xlog_recover_finish+0x3b/0xf0
[] xfs_iunlock+0x78/0x90
[] xfs_mountfs+0x548/0x720
[] default_wake_function+0x0/0x10
[] xfs_fs_fill_super+0x22d/0x3a0
[] get_sb_bdev+0xfa/0x120
[] kstrdup+0x39/0x70
[] xfs_fs_get_sb+0x20/0x30
[] xfs_fs_fill_super+0x0/0x3a0
[] vfs_kern_mount+0x59/0x120
[] do_kern_mount+0x3d/0xf0
[] do_new_mount+0x81/0xc0
[] do_mount+0x1c9/0x1f0
[] copy_mount_options+0x40/0x140
[] sys_mount+0x77/0xc0
[] syscall_call+0x7/0xb
=======================
xfs_difree: xfs_inobt_lookup_le returned() an error 117 on loop30. Returning error.
xfs_inactive: xfs_ifree() returned an error = 117 on loop30
xfs_force_shutdown(loop30,0x1) called from line 1406 of file fs/xfs/xfs_vnodeops.c. Return address = 0xc030b291
Filesystem "loop30": I/O Error Detected. Shutting down filesystem: loop30
Please umount the filesystem, and rectify the problem(s)
Ending XFS recovery on filesystem: loop30 (logdev: internal)
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.
Filesystem "loop30": xfs_log_force: error 5 returned.

root@slax:/mnt/sdb2/slax-related# ls /tmp/mnt
ls: cannot access /tmp/mnt: No such file or directory

# mount -o loop,nouuid,norecovery,ro 20100728-slaxsave.dat-testing /tmp/mnt
root@slax:/mnt/sdb2/slax-related# dmesg|tail -n 5|less
[...]
Filesystem "loop30": Disabling barriers, underlying device is readonly
Mounting filesystem "loop30" in no-recovery mode. Filesystem will be inconsistent.

root@slax:/mnt/sdb2/slax-related# ls /tmp/mnt
changes copy2ram httpfs images lost+found modules xino


Woow! at the end seems I've done it... Let me try to view some data no more present in my recovered slaxsaved.dat:


root@slax:/mnt/sdb2/slax-related# ls /tmp/mnt/changes/var/spool/news/.outgoing/
: localhost:119 news.aioe.org:119 nntp.aioe.org:119
root@slax:/mnt/sdb2/slax-related# ls /var/spool/news/.outgoing/
: localhost:119 nntp.aioe.org:119


As you can see a dir "news.aioe.org:119" is no more present in my actual recovered slaxsave.dat but it's still in the backupped corrupted one.

At this point I could try to make a new empty slaxsave.dat file... as usual for example:
dd if=/dev/zero of=/path/to/slaxsave.dat-clean bs=512 count=2000000
mkfs.xfs /path/to/slaxsave.dat-clean
mnt -o loop /path/to/slaxsave.dat-clean /tmp/mnt2

And then try to copy data from /mnt/tmp to /tmp/mnt2:
cp -a /mnt/tmp/. /mnt/tmp2/.

What do you think about?
(I think I'll can't have access to some data due to inconsistency of filesystem, anyway... I could try)

Suggest that in the future you make important config changes and additions by making modules. My theory is, you should be able to run your preferred setup without using any changes file. Poop happens, sooner or later.

[...]

No ... what I do here, starting with a fresh new slax, is to start it up in always fresh mode, do some configs, and then a dir2lzm /mnt/live/memory/changes z1-config.lzm. Then move that to /modules and reboot. Then make some more changes and do it again, z2-config.lzm, etc, etc.


Then finally, enable a slaxsave.dat, but it will only contain minor tweaks, stuff I can lose without any pain.


Seems a safe way to work.
A question:
1) when finally you use slaxsave.dat, will all your changes wrote (also from changes.lzm) to slaxsave.dat?
2) when using slaxsave.dat could you always create your changes manually as described with dir2lzm?
If yes, this would be a good way to make online-backup of the system.
 
burninbush
wrote 4 years ago


reply
Seems a safe way to work.
A question:
1) when finally you use slaxsave.dat, will all your changes wrote (also from changes.lzm) to slaxsave.dat?
2) when using slaxsave.dat could you always create your changes manually as described with dir2lzm?
If yes, this would be a good way to make online-backup of the system. >joex


+++++++++++++++

I think you've missed understanding a fundamental feature of slax -- once you've made a changes.lzm file as I described above, and put it into /modules or /base, then on the next bootup the files inside that changes.lzm file are no long seen as changes -- the modified files inside those .lzms do not appear in /mnt/live/memory/changes. It is as if the changed files were always a part of the base system. Only =new= changes since the last bootup are recorded in /mnt/live/memory/changes. Think this magic is due to the union filesystem.

Your #2) above -- no, I always boot to always fresh mode when I intend to make a changes.lzm file. It could be done as you ask, but the point of my style of use is that I don't really care much if I lose the slaxsave.dat file, since it contains nothing vital. A user could do what you suggest, but it would only make sense then to replace the slaxsav.dat file with a new empty one.

Now, there is no point in backing up the bulk of slax, that is the contents of the iso file, and little point in backing any modules you have downloaded from the slax modules site; those can be recovered if needed from the original site they came from. So that leaves the setup changes you have made to the system, usually not occupying much space, plus any personal data files you have created or added to the media that holds slax. Yes, I do periodically backup my zN-config.lzm files to another partition. And in my use of slax [and all other distros] I always place docs and other personal stuff on a separate partition.

And to be very clear, nothing inside those xxx.lzm files is ever changed due to running or tweaking the setup of slax. They are never written-to, only read.

So, to review: my custom slax consists of 190mb of the original distribution, 200mb of added modules that I have downloaded, and ~20mb of setup tweaks in my zN-config.lzm files. That last 20mb is all I really need to backup.
 
joex
wrote 4 years ago


reply
Mmmm, I'm now runninng slax booted as usual with changes=slaxsave.dat.
If I now look at content of /mnt/live/memory/changes i obtain:


root@slax:~# du -sh /mnt/live/memory/changes/
205M /mnt/live/memory/changes/


This means that all changes I've saved in the past, also in past work sessions, are stored in that directory and used at any boot time (if I use slaxsave.dat).
 
fanthom
wrote 4 years ago


reply
joex wrote:
This means that all changes I've saved in the past, also in past work sessions, are stored in that directory and used at any boot time (if I use slaxsave.dat).

they wont be there if you create slax module 'dir2lzm /mnt/live/memory/changes z1-config.lzm', move z1-config.lzm to /slax/modules and use fresh 'slaxsave.dat' file as suggested by burninbush above.

EDIT:\\
he didnt say it directly but when you boot slax without slaxsave.dat container, changes are saved to tmpfs (memory) and wiped out automatically after each reboot. in your case changes are saved to 'real fs' in a container so it must be deleted or wiped out (formatted) manually before next use.

Cheers
 
joex
wrote 4 years ago


reply
Ok. We have two ways to boot:

1) slaxsave.dat
/mnt/live/memory/changes is populated with all changes contained in slaxsave.dat at boot time.
Others changes made during current session are saved in that above directory too and I think they eventually overwrite those were present at boot time.
When we end work session and shut down system, content of changes dir is copied into slaxsave.dat file.


2) changes.lzm in modules/ directory
/mnt/live/memory/changes appears empty at boot time.
It is populated only with changes made in current session.
When we exit and shutdown, this changes expires. If we want to save them, we have to manually create a new changesX.lzm moudule as described above by BB.

I'm now searching for a strategy to maintain backed up my system.
BB has explained his own way:
- Creating changesX.lzm and put them in backupdevice
- Using them as any other module.
- Using a slaxsave.dat for few last changes.
Anyway I think he creates an other changesX.lzm module before doing critical operations.
However, I've some doubs about this way.
The question is:
what happens if changesX.lzm contains a file es. /usr/bin/something and this file is present in changesY.lzm?
I mean if both X and Y modules are present at the same time in modules/ directory, which one overwrite part of the other one? which /usr/bin/something is used? from X... or Y module?
 
joex
wrote 4 years ago


reply
Isn't my question such clear?

I've browsed slax file system and comapred content of /mnt/live/memory directory with slaxsave.dat (I've loop monted a backup image in /tm/mnt).

root@slax:~# mount -o loop,ro,nouuid /mnt/sdb2/slax-related/20100729-slaxsave.dat /tmp/mnt
root@slax:~# ls /tmp/mnt
changes copy2ram images lost+found modules xino
root@slax:~# ls /mnt/live/memory/
changes copy2ram images lost+found modules xino
root@slax:~# du -sh /tmp/mnt
659M /tmp/mnt
root@slax:~# du -sh /mnt/live/memory/
1,8G /mnt/live/memory/


Great difference... let's go deep:

root@slax:~# du -sh /mnt/live/memory/*
254M /mnt/live/memory/changes
0 /mnt/live/memory/copy2ram
1,1G /mnt/live/memory/images
369M /mnt/live/memory/lost+found
33M /mnt/live/memory/modules
0 /mnt/live/memory/xino
root@slax:~# du -sh /tmp/mnt/*
258M /tmp/mnt/changes
0 /tmp/mnt/copy2ram
4,0K /tmp/mnt/images
369M /tmp/mnt/lost+found
33M /tmp/mnt/modules
0 /tmp/mnt/xino


Yes, now it's more clear. The "images" dir seems contain mounted modules, so it's obiously big when the system is up (1.1G) and about empty in the slasave.dat backupped file.
But the pthers subdirectories, have about the same size.
Now I've a suspect:
1) at the end of work session when we shutdow the system, slax copy the content of /mnt/live/memory into slaxsave.dat (think loop mounted) file.

If this is true. We could manually bakcup the following directories:

254M /mnt/live/memory/changes
0 /mnt/live/memory/copy2ram

369M /mnt/live/memory/lost+found
33M /mnt/live/memory/modules
0 /mnt/live/memory/xino

Then if a disaster happens, we could recreate a slaxsave.dat:
We could make a first "base" backup with cp:
1) dd if=/dev/zero of=...
2) mkfs.xfs slaxsav.dat-new
3) mount -o loop slaxsave.dat /tmp/mnt
4) cp -a /mnt/live/{changes,copytoram,lost+found,modules,xino} /tmp/mnt/

Then we could maintain it uptodate with rsync (I don't remember all exclude include rsync otions)
5) rsync -avz -other_options /mnt/live/memory/ /tmp/mnt/
With "other option" we provide a way toexclude "images" dir).
If my suspect is really true, I think this a very fast and simple way to backup "online" the system becasue rsysync will copy just files that differs by th yet copied the last time.

When a disaster happens, we have to copy slaxsave.dat-new to slaxsave.dat overwriting corrupted one.

What do you think about?
 
jcsoh
wrote 4 years ago


reply
This maybe a bit off topic , but in the saved changes , you can delete

Everything in

/copy2ram
/images
/modules
/xino

Only what is in /changes is important
Even within /changes , there is a lot of non essentials which can be deleted

I don't save to a slaxsav.dat but to a linux partition so all the subdirectories is unpacked . Before I make a backup of my saved changes subdirectories , I will delete the unnecessary to minimise the size of the backup.

For those items that are deleted , slax simply recreates them each time it boots up.
Some are simply unused/outdated saved changes , for example , if you used a module , it will be shown in /images , even long after you deleted the module.
 
joex
wrote 4 years ago


reply
So, If I take backupped some sub dirs of changes it will be ok...
Changes dire seemsto contain a common *nix file system:

root@slax:~# ls -al /mnt/live/memory/changes/
total 24
drwxr-xr-x 17 root root 4096 2010-07-29 17:03 .
drwxr-xr-x 8 root root 90 2010-07-31 12:11 ..
-rw-r--r-- 1 root root 115 2010-03-06 19:12 aaa
-rw-r--r-- 1 root root 1 2010-03-06 19:12 aaaa
-rw-r--r-- 1 root root 0 2010-03-06 19:12 bbb
drwxr-xr-x 2 root root 39 2010-07-29 16:08 bin
drwxr-xr-x 2 root root 31 2010-03-04 16:18 dev
drwxr-xr-x 16 root root 4096 2010-07-31 18:04 etc
drwxr-xr-x 4 root root 26 2010-07-29 16:13 home
drwxr-xr-x 3 root root 20 2006-11-27 20:39 lib
drwxr-xr-x 13 root root 131 2010-07-31 10:14 mnt
drwxr-xr-x 2 root root 6 2010-06-05 13:28 proc
drwxr-xr-x 25 root root 4096 2010-07-31 16:14 root
drwxr-xr-x 2 root root 6 2010-06-05 23:33 sbin
drwxr-xr-x 2 root root 6 2010-06-05 13:28 sys
drwxrwxrwt 13 root root 4096 2010-07-31 14:19 tmp
drwxr-xr-x 10 root root 95 2010-05-07 14:09 usr
drwxr-xr-x 9 root root 81 2006-09-12 09:33 var
-r--r--r-- 86 root root 0 2010-03-04 16:18 .wh..wh.aufs
drwx------ 2 root root 6 2010-03-04 16:18 .wh..wh.plnk
drwx------ 2 root root 6 2010-03-04 16:18 .wh..wh..tmp


Which subdir could I exclude?
I think dev, proc, sys subdirs are recreated at any boot time... isn't it right? So no need to backup them.

And then, ok, backup itself can stay unpacked too. But when disaster happens and I'll want to recover slaxsave.dat, is sufficent to put changes backupped dir in the clean slaxsave.dat? And then cp it in place of old corrupted slaxsave.dat. I mean, others directoryes like dev, proc and also modues xino etc are recreated at boot time?
I cuold just try... anyway if could confirm this behavior...
Thanks in advance.
 
jcsoh
wrote 4 years ago


reply
Within the /changes , the following are unnecessary to back up , as they will be recreated:
/.wh..wh..tmp
/.wh..wh..plnk
/dev
/media
/mnt
/tmp

Edit -add
/var/tmp
/var/spool
 
burninbush
wrote 4 years ago


reply
What do you think about? >joex

++++++

Too much struggling. Just boot always fresh, loop mount the slaxsav.dat file, and then dir2lzm on the directory [mount point] where you mounted the .dat file. Copy that to some separate media if you want. Reboot with the changes= enabled again, and go onward.

As jcsoh suggests, take the opportunity while you have it loop mounted to delete junk from it.

Having that file onhand, you can copy it to /modules if you want, and run forever without any changes, if you are happy with the machine as it is today. If you run the make_iso.sh script you can make a new cdr / dvd with all your changes incorporated.

As I wrote before, your changes are all you really need to backup -- all the rest can be reloaded from optical or whatever other media. No matter how much you use slax, those /base and /modules .lzm files will be the same as when you first used slax.
 

  » search  » forum index  

Post your reply

Your name (Login):

Message:

These HTML tags are allowed: <quote>, <b>, <u>, <i>, <pre>, <code>, <small>, <h1>, <h2>, <h3>, <li>



Slax is generously supported by: P&P Software GmbH and wisol technologie GmbH