Corrupted slaxsave.dat after crash:help to recover

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".

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.

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.

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.

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.

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.

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:
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.

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?

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.

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.

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.

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.

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.