Puppy 412 won’t make save files without CD (SOLVED x2)

Using applications, configuring, problems
Message
Author
Dewbie

Puppy 412 won’t make save files without CD (SOLVED x2)

#1 Post by Dewbie »

It’s installed frugally, booting with WakePup2.
My other Puppies will make save files this way.
412 is the only one that won't.

I tested 412 with 301's rc.shutdown script.
No luck. :?
So apparently this is controlled by another file...but which one?
Last edited by Dewbie on Tue 10 Dec 2013, 21:34, edited 2 times in total.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#2 Post by mikeb »

That old chestnut... some odd init behaviour in those with regards to how pup location is detected...guess it was cludged around in the end. I did make a fixed init based on the original init so may be useful of the problem persists.

I would start with seeing what /etc/rc.d/PUPSTATE has listed... you will most likely find pdev1 and maybe another is empty.

mike

Dewbie

#3 Post by Dewbie »

OK, first...booting to pfix=ram from MultiPup CD:

Code: Select all

PUPMODE=5
PDEV1='hdc'
DEV1FS='iso9660'
PUPSFS='hdc,iso9660,/412R-k2.6.21.7/pup_412.sfs'
PUPSAVE=''
PMEDIA=''
SATADRIVES=''
#these directories are unionfs layers in /initrd...
SAVE_LAYER=''
PUP_LAYER='/pup_ro2'
#The partition that has the pup_save file is mounted here...
PUP_HOME=''
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='no'
PSWAPFILE=''
PSAVEMARK=''
Next, booting to pfix=ram from WakePup2 (to frugal):

Code: Select all

PUPMODE=5
PDEV1=''
DEV1FS=''
PUPSFS='sda6,vfat,/pup_412.sfs'
PUPSAVE=''
PMEDIA='atahd'
#v3.97: kernel with libata pata has both sata and pata drives in ATADRIVES...
ATADRIVES='sda '
#these directories are unionfs layers in /initrd...
SAVE_LAYER=''
PUP_LAYER='/pup_ro2'
#The partition that has the pup_save file is mounted here...
PUP_HOME=''
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='no'
PSWAPFILE=''
PSAVEMARK=''
Pretty much what you said.
Is there any way to hack this?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#4 Post by mikeb »

Ok as it happens I have 'fixed' inits in these otherwise original initrds if you want to try . I notice you are using retro I assume in both cases but here are both.
These never got a full workout but seemed to fix a few problems I found but might at least shed some light. (pfix=ram not working if there is a full install around which then gets used as a save partition is another)

http://dl.dropbox.com/u/110545536/Puppy ... 2_fixed.gz
http://dl.dropbox.com/u/110545536/Puppy ... o_fixed.gz

My original post on the subject is buried on here somewhere.

If its what I think it is the problem centered on detecting initrd.gz to determine where puppy is .... a plan with flaws so I changed it to look for pup_xxx.sfs. The problem occurs if 1. there is more than one initrd.gz or 2. you like me rename your initrd.gz for convenience (ie all in one boot folder) .
If my init does help but gets upset in another way (possibly sub sub folder searching) then that's the area to look at....ie just apply the initrd search fix.
The common workaround at the time was to premake a save file...not quite so user friendly.

mike

Dewbie

#5 Post by Dewbie »

mikeb wrote:
Ok as it happens I have 'fixed' inits in these otherwise original initrds if you want to try.
Thanks Mike...didn't have any luck with them, though; same old...
I notice you are using retro I assume in both cases.
MultiPupCD=412 retro.
frugal=412 regular.
MultiPup 412 regular won't boot because I screwed up the menu. :roll:
(They both have the same problem with save files, though.)
I would start with seeing what /etc/rc.d/PUPSTATE has listed... you will most likely find pdev1 and maybe another is empty.
And that's the key.
Have another look at these two:

Code: Select all

PDEV1=' '
DEV1FS=' '

If I change them to 'sda6' and 'vfat', then it works correctly; I get the save-file dialog box.

I also tried 301's init file with 412's initrd.gz.
It booted straight to desktop.
But it still won't make a save file.
(301's init will make a save file with 301.)

So apparently init doesn't assign these values to PDEV1 and DEV1FS during bootup.
The question is, what does?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#6 Post by mikeb »

Erm init does....ie it writes PUPSTATE.

Though its possible its not detecting drives properly and you are using the regular 4.12 in the problem setup which has the sata aware kernel.
Also 301's init might well fail for other reasons.... ie not aware of the sata awares kernels detection methods. I suggest this as sata and usb drives became as one..... all good fun...though there is a detection loop that tries to wait for usb and also uses the need for a delay as a sign that it is a usb drive...another potential error spot.

My fix was for one reason those parameters are not getting filled... by its nature there is most likely another scenario that will produce the same result. Remember the init in puppy 4 gathers info on anything around that may be for puppy and then guess and fumble its way to hopefully assemble the system correctly so anything that might be 'misunderstood' as it were will throw it off and it errs on not setting pdev1 if there is doubt even though it may still boot since it tries to load something regardless.
I am not making this up .
Perhaps another easier way would be to try and unmess up the menu.lst for multipupup...after all it works with no parameters by default.

mike

Dewbie

#7 Post by Dewbie »

mikeb wrote:
Erm init does....ie it writes PUPSTATE.
Which line(s) in the init script do this?
(I'm inclined to experiment further if I know where they are.)
Though its possible its not detecting drives properly and you are using the regular 4.12 in the problem setup which has the sata aware kernel.
Both 412 versions won't make save files running frugally, but they will when booting from CD.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#8 Post by mikeb »

Well its written at the bottom of init but the variables are collected from various parts but in this case searching for PDEV1 should trace back its creation.

The sata idea was only a suggestion as a possible cause so one to dismiss.

Its most likely in the handling of collected drive/file data.

I fixed a few things with those inits but the rest was simply worked around rather than fixed at the time though I have seen the odd post about non save creation with more recent pups.

my notes from what I did in those inits...

Code: Select all

1.Initrd sensing bug preventing save creation.......

 #BPATTERN="/initrd\\.gz"  ##changed to...could probably dump the find function too
 BPATTERN="pup_${PUPPYVERSION}"
 
 2. ram size check here...
 
 [ $RAMSIZE -gt 260000 -a "$PCOPY" = "yes" ] && COPY2RAM="yes" #256MB system. note, only checking physical ram.
 
 3. avoid using full install as pupsave and use pfix=ram option as intended
 
  #[ -f /mnt/data/etc/puppyversion ] && FND_FULLINSTALL="/etc/puppyversion"  #no make sense really...should it be cat????
 [ -d /mnt/data/initrd ] && FND_FULLINSTALL="/etc/puppyversion" #prescense of initrd confirms save as partition.
 
 #plus added PRAMONLY check like a good boy
 
 #if a pup_save was not found, perhaps boot partition has a full install of puppy...based on test for full install..
if [ "$PUPSAVE" = "" -a "$PDEV1" != "" -a "$PRAMONLY" != "yes" ];then
 APATTERN="^${PDEV1} "
 [ "`grep "$APATTERN" /tmp/PUPPYFILES | grep '/etc/puppyversion'`" != "" ] && PUPMODE=`expr $PUPMODE + 2`
fi

4. option to load 3fs or reiserfs pupsave....no resize option for reiser but 3fs should. Not done for crypto version either.

###detection
 FND_PUPSAVE2FS="`find /mnt/data -maxdepth 2 -mount -type f -name pup_save*.[23r]fs | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
#plus
   BPATTERN="/pup_save.*\\.[23r]fs"

###mounting
   losetup /dev/loop1 /mnt/dev_save${PUPSAVEFILE}
   FILEFS="ext2" #add filesystem types...not done for encrypt
   [ "${PUPSAVEFILE##*.}" = "3fs" ] && FILEFS="ext3"
   [ "${PUPSAVEFILE##*.}" = "rfs" ] && FILEFS="reiserfs"
   echo "/dev/loop1 $CREATEPUPSAVE2FS ext2 defaults  1 1" >> /etc/fstab #v2.21
   fsck_func loop1 $FILEFS $PUPSAVEFILE #v3.01 ####changed to fsck ..may work for reaiser if binary available#####
   mount -t $FILEFS -o noatime /dev/loop1 $CREATEPUPSAVE2FS
   if [ $? -ne 0 ];then
    fsck -y -f /dev/loop1 > /dev/console #-y answer yes to all repair questions.hmm will it work for all three
    mount -t $FILEFS -o noatime /dev/loop1 $CREATEPUPSAVE2FS


Dewbie

#9 Post by Dewbie »

Thanks for the tips, Mike. :)

After experimenting unsuccessfully with echo and sleep commands, I stumbled upon shinobar’s pupsaveconfig .pet. Among other things, it installs a modified rc.shutdown file.

So I booted to pfix=ram, installed the .pet and copied rc.shutdown.
Then I rebooted and tested it by itself.

It worked! :D
pup_save shutdown dialog is now there, despite the missing PUPSTATE parameters.
(The only problem is, if there's a CD in the drawer, it will auto-eject...:?)
Last edited by Dewbie on Mon 02 Dec 2013, 15:32, edited 1 time in total.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#10 Post by mikeb »

Ah ha so treat the symptoms rather than the cause... that was generally the approach used since the init was beyond reasonable comprehension.

Anyway why should it need those parameters to give a save choice...even that makes little sense....I don't...to me they only come into use once you have some sort of save anyway.

Too many parameters spoil the broth as the pixies say

mike

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#11 Post by nic007 »

mikeb wrote:Ah ha so treat the symptoms rather than the cause... that was generally the approach used since the init was beyond reasonable comprehension.

Anyway why should it need those parameters to give a save choice...even that makes little sense....I don't...to me they only come into use once you have some sort of save anyway.

Too many parameters spoil the broth as the pixies say

mike
Never had this problem with Puppy 412 but the bug exists in Wary Puppy 539, does not create save file from frugal install.

Dewbie

#12 Post by Dewbie »

nic007 wrote:
but the bug exists in Wary Puppy 539
Is that some sort of unofficial build?
(BarryK went straight from 5.3 to 5.5.)

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#13 Post by mikeb »

All that can be said for certain is that the causes of not making a save file are uncertain. Something I have seen crop up with various puppies on here so its a case of hitting a combination it spits its dummy at,

mike

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#14 Post by nic007 »

Dewbie wrote:nic007 wrote:
but the bug exists in Wary Puppy 539
Is that some sort of unofficial build?
(BarryK went straight from 5.3 to 5.5.)
Probably a beta for 5.3 or 5.5, not sure. Remastering script does not work either (well it runs but the result is a dummy). I've also noticed that one of my wine programmes freezes up when minimized to tray with this version.

Dewbie

#15 Post by Dewbie »

mikeb wrote:
All that can be said for certain is that the causes of not making a save file are uncertain.
Apparently yet another compatibility problem with certain hardware...
Last edited by Dewbie on Thu 05 Dec 2013, 00:14, edited 1 time in total.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#16 Post by mikeb »

Well I cannot think off hand of another operating system that has the user configure the system after running it ..ie at shutdown. In doing so that system has to work out what that config was when it next boots.. I also notice the increase in boot parameters that seem to try and configure the boot to work around potential weaknesses in the system detection or simply to speed it up. So really you end up with something that's not quite one thing or another.
I decided to keep the choose at shutdown way as that is a fairly unique puppyism that does have its merits and then kept the boot / detection side simple to avoid ambiguity and the need for parameters. Plus its really a live linux with an install option which does require a hands off boot up ability.

if that makes sense..answers on a postcard... or a jiffy bag cos it costs the same and you can include more goodies.

mike

Dewbie

#17 Post by Dewbie »

mikeb wrote:
If its what I think it is the problem centered on detecting initrd.gz to determine where puppy is .... a plan with flaws so I changed it to look for pup_xxx.sfs.
Previously, I had only tried mikeb’s “fixed

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#18 Post by mikeb »

Who is this mikeb anyway???

Well butter my bread ... I grabbed from my archives the 2 inits labelled as fixed.... so I need to double check what I actually have. Too many inits I guess and I have mixed them up when tidying up..

So it was the problem I suspected...there ya go.
I wonder if it still applies in newer pups...

By the way if its possible to find it.... there will be a very old post on this forum with my correct upload made at the time of 4.12 's release.

The retro init is not quite the same as the non retro so it does not quite drop in whole so I would need to have the 2 versions in my stash....can use my notes if I really don't have a copy.

mike

Dewbie

#19 Post by Dewbie »

mikeb wrote:
I wonder if it still applies in newer pups...
No problems here with (as-is) 2.14x / 3.01 / 4.31 / Wary 5-series. :)
4.12 is the outlier...

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#20 Post by mikeb »

Ok the question is, is the same detection used in newer pups?

mike

Post Reply