Puppy does not wait for pup_save file password.

Booting, installing, newbie
Post Reply
Message
Author
machare
Posts: 5
Joined: Sat 22 Dec 2007, 22:16

Puppy does not wait for pup_save file password.

#1 Post by machare »

I am running Puppy from a Kingston 2GB USB memory stick on an Asus P5B-V motherboard also with 2GB.

If I don't encrypt my save file I can save my settings etc and use them the next time without problem. (512MB pup_save file.)

If I encrypt the save file then when booting the PC does not stop and ask for a password. Rather it displays a PASSWORD prompt in blue followed by red text to the effect that the save file is corrupt and perhaps I would like to use the e2fsck -b 8193.

How can I persuade this puppy to ask for password before trying to open the pup_save file?
I was also expecting a menu where I could choose which save file to use!

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#2 Post by PaulBx1 »

Try making another encrypted pupsave. Maybe the last one got torqued some way.

What puppy version are you using anyway?

I might have to figure out a script to fsck encrypted pupsaves. It is kind of a fiddly manual process now.

machare
Posts: 5
Joined: Sat 22 Dec 2007, 22:16

#3 Post by machare »

PaulBx1 wrote:Try making another encrypted pupsave. Maybe the last one got torqued some way.
I tried several times with and without passwords, and wasted some time as I initially thought that it was the USB stick that was corrupt.
PaulBx1 wrote:What puppy version are you using anyway?.
Should have said 3.01 (Just downloaded today)
PaulBx1 wrote:I might have to figure out a script to fsck encrypted pupsaves. It is kind of a fiddly manual process now.
The way I see the problem is that the boot process does ask for a password before trying to process the pup_save file.

Thanks for your help

machare
Posts: 5
Joined: Sat 22 Dec 2007, 22:16

#4 Post by machare »

PaulBx1 wrote:Try making another encrypted pupsave. Maybe the last one got torqued some way.
I tried several times with and without passwords, and wasted some time as I initially thought that it was the USB stick that was corrupt.
PaulBx1 wrote:What puppy version are you using anyway?.
Should have said 3.01 (Just downloaded today)
PaulBx1 wrote:I might have to figure out a script to fsck encrypted pupsaves. It is kind of a fiddly manual process now.
The way I see the problem is that the boot process does not ask for a password before trying to process the pup_save file.

Thanks for your help

aarf

#5 Post by aarf »

I have this same problem too.
saved a heavy encrypted pup_save to a sda mounted USB flash.
got the nonstop boot with bad file message after the password-prompt. as above: "PASSWORD prompt in blue followed by red text to the effect that the save file is corrupt and perhaps I would like to use the e2fsck -b 8193."

copied the encrypted pup_save from sda to hda1 and the pup_save then booted correctly with password as is correct.

then copied the encrypted pup_save to a sda1 mounted flash drive and once again the pup_save mounted correctly.

so it seems it is a problem with sda mounts of (heavy?) encrypted pup_saves only.

a solution for sda mounts would be nice. there is nothing wrong with the sda USB as I use it in preference to boot puppy from. it is ext3.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#6 Post by Pizzasgood »

I ran into this last night, with a normal ide (hda) harddrive and both xor and aes encryption in 3.01. I looked at the code that mounts them and it looked correct, but I didn't look very hard. I haven't worked with the encrypted files in at least half a year so I'm pretty rusty.
The way I see the problem is that the boot process does not ask for a password before trying to process the pup_save file.
There isn't an actual line in the boot scripts that requests the password. If I remember right, that happens automatically when the loopback device is set up. So the real problem is that the loobpack device is failing to be set up correctly. Without going in and testing, I don't know whether that's caused by a failure to detect the encryption method, a failure to load the correct modules, a glitch in the losetup app, or something else entirely.

If nothing more important comes up, I might take a closer look at it tonight or tomorrow.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#7 Post by Pizzasgood »

This is the line where we're getting the problem:
losetup $CRYPTO /dev/loop1 /mnt/dev_save$PUPSAVEFILE
(note: that line occurs twice - once for if you want to resize the save file, and again for if you don't).

As for the problem itself, it's that losetup isn't honoring the '-e aes' and '-E 1' options (which are passed in through the $CRYPTO variable, but I tried hard-coding them too). Why? No idea.

What's weird is that if I use pfix=rdsh and try it after being dropped out, it works fine. But if I modify the init script to drop me out where the losetup is and try it, it doesn't work right.

I've compared lsmod from both locations and the same modules are loaded.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#8 Post by John Doe »

Pizzasgood wrote:I've compared lsmod from both locations and the same modules are loaded.
is losetup the same?

is the variable $CRYPTO not getting passed over?

just trying to help you brainstorm. :D

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#9 Post by Pizzasgood »

I just checked the md5sums. They're the same. As for the $CRYPTO, I set up an echo statement before to check that it was set. Even if it wasn't, I also tried hard-coding the exact command, with no variables at all.

I also checked to make sure the filesystem was actually mounted and the save-file accessible.

I have no more ideas.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#10 Post by PaulBx1 »

I thought we are supposed to use losetup-FULL. Wasn't the busybox losetup lacking in features? Or is that old information? I use losetup-FULL in my convert-pupsave program...

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#11 Post by Pizzasgood »

In the initrd.gz stage of Puppy 3.01, the only losetup available is the full one. It just doesn't have the -FULL suffix.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#12 Post by PaulBx1 »

What about the other variable, $PUPSAVEFILE? Could it be getting confused between your two cases?

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#13 Post by Pizzasgood »

I had an echo statement to make sure that was set correctly too.
Even if it wasn't, I also tried hard-coding the exact command, with no variables at all.
I've been taking a break from this and working on some other stuff to let my brain empty. Depending on how long my next couple tasks take, I might do some more testing this weekend. Obviously there's some difference between when it's run normally and when it's run from using pfix=rdsh. I just need to figure out what that difference is. I've eliminated the command string and losetup itself, along with the module loadout. Maybe the modules themselves are different...
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

aarf

#14 Post by aarf »

variable length of hda and sda is three(3), variable length of sda1 and hda1 is four(4). is it this variable that is causing the problem somewhere?

Post Reply