How to properly repair an encrypted 4fs Save file?

Booting, installing, newbie
Post Reply
Message
Author
User avatar
James186282
Posts: 270
Joined: Tue 08 Sep 2009, 19:14
Location: Minnesota

How to properly repair an encrypted 4fs Save file?

#1 Post by James186282 »

First an admission. I'm a noob. I'm still picking up things slowly. I've been fiddling with puppy linux since version 4.3 in the pre lucid days. *so I'm not a long time user.

The question is about 4fs save images. My problem is that once in a geat while I managed to lock up the machine and have to power off and on. When I do this I get inode errors and all manner of problems.

I'm using an IBM Thinkpad T60. I have a frugal installation of Slacko 5.4 My save file has the mild encryption and its in .4fs format. *So is everything. I chose 4fs because in some documentation its speaks of journaled file systems and how recovery is possible even in the event of power going off unexpectadly. I'm not sure how to access that feature. Instead I've read a number of threads that talk about using fsck or the new and improved e2fsck. When I've resorted to this I seem to make a bad problem much worse. I wrote up a Grub menu.lst file to let me boot up the above mentioned Slacko or a Lucid or Wary system. The lucid system got hung up I tried to fix it and that screwed it up totally so I deleted everything and never bothered to reinstall it

When my slacko system got munged I boot up Wary which I don't really use for daily use its just my emergency back up "boot"

After booting form Wary I thought this is where its ok to try to repair the Slacko Save file.

Step #1 I find the first available LOOP Device by doing this
losetup-FULL -f
The result in this case is loop2

Step #2 I do this to gives me some information on loop device 2
loseitup-FULL /dev/loop2

Step #3 I load the linux kernels crypto packages
modprobe cryptoloop

Step #4 I make a directory (No error if its already been done before)
mkdir -p /mnt/crypto
*Note I'm not sure why this is done. What is this going to be used for?

Step #5 I setup my encrypted save file to be accessable as loop2
losetup-FULL -e 1 /dev/loop2 /mnt/home/slacko5.4/pup_save_crypt.4fs

Step #6 I repair the encrypted loop2 (Which I think is the password open version of the puppysave.4fs file?)
# -b tells the program to use an alternative superblock.
# -p Automatic repair with no questions.
# -n Make no changes to the file system
# -y Answer yes to all questions.
# -c Check for bad blocks.
# -f Force checking even if the file system is marked clean.
# -v Give a lot of information, verbose.
e2fsck -v /dev/loop2

e2fsck tells me about a variety of inodes and files that should be this but are really that and so on. I hit "y" a lot and when its done and says everything is "ok" and I reboot.
The system is then totally unbootable and not at all useable so I cry and scream uselessly into the keyboard and start over from scratch.

Question 1. Something is not going right. Can anyone guide me to the correct solution to repair a slighltly munged up puppy save file in the future?

Question 2. If 4fs is a journaled file system what program / routine is used to make it "roll back" to a point where its not screwed up? e2fsck doesn't seem like the correct tool if I understand journaling *Which I probably don't.

Question 3. All I am trying to do with encrypting the frugal save file is keep the kids from booting up and messing around on the computer I use for work. Is there a better way to do this? *I'm thinking crypto is compliating this or maybe even part of the cause?

I've tried searching around for an answer but... The above is as close as I've gotten and I might not be understanding what I "think" I understand. If thats understandable...
Science is what we understand well enough to explain to a computer.
Art is everything else we do.
[i]Donald Knuth [/i]

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#2 Post by Karl Godt »

Nowerdays clicking on an encrypted save file should bring a box to enter a password to mount it. Look into /usr/sbin/filemnt for that. Ext4 is faster to fsck than ext3. But may have disadvantages. One problem might be the default mount option data=writeback if set so in the kernel driver configuration (data=ordered is said to be safer).

If the box is like that :
Prozessor Intel Core 2 Duo T5500 (1,66 GHz)
Chipset Intel 945 GM
RAM inst. / max. 1.024 / 4.096 MB DDR2
Grafik Intel 950, shared Memory max. 224 MByte
Display 14,1" TFT, 1.024 x 768 Pixel

Puppy should be OK running on it. My Dell Core2Duo runs better with kernels pre-3.x, especially with Puppy-4.3.1, (which is not bugfree and set ext4 defaults to data=writeback) , since later kernels mostly refuse to reboot . Kernel-2.6.30.5 is the first to support ext4, while the scripts don't take it into account .
tune2fs has the option -o journal_data_ordered to toggle the default data flag.

User avatar
James186282
Posts: 270
Joined: Tue 08 Sep 2009, 19:14
Location: Minnesota

#3 Post by James186282 »

Clicking my encrypted save file now brings up a red box that says
Failed Mounting or Unmounting

e2fsck? Did I goof this up?
Science is what we understand well enough to explain to a computer.
Art is everything else we do.
[i]Donald Knuth [/i]

User avatar
James186282
Posts: 270
Joined: Tue 08 Sep 2009, 19:14
Location: Minnesota

#4 Post by James186282 »

Humm.... I tried doing the same steps over with the exception of letting e2fsck fix anything. *Just display/

It accepts the password!

e2fsck -n responds with...
/dev/loop2: clean, 14697/589824 files, 726124/2359296 blocks
I'm puzzeld even more now...
Science is what we understand well enough to explain to a computer.
Art is everything else we do.
[i]Donald Knuth [/i]

User avatar
James186282
Posts: 270
Joined: Tue 08 Sep 2009, 19:14
Location: Minnesota

#5 Post by James186282 »

Having e2fsck see my munged save file (And accept the password) gives me hope. The machine gives a few interesting messages that may be a clue to whats happened.

Feature R13 (and 14,16,18,21,22,24,29 and 30) e2fsck get a newer version of e2fsck

mounting /dev/loop1 on /pup_rw failed invalid argument

I've been trying to work on the save file by booting a slacko 5.5.4 version that I just installed. So I'm wondering if newer version is correct. And if so do I find it and compile it myself? These missing "features" - I do wish they had some more detail the R29 etc.
Science is what we understand well enough to explain to a computer.
Art is everything else we do.
[i]Donald Knuth [/i]

Post Reply