My pup save is not being used

[rafkid]

So, this is a tad embarrassing. My ring main crashed in my home and I reset everything. This turned off my foasspup64 pc. When it rebooted it came up without using my pup save file as if it was a first time install. After diligently attempting to find out how to tell grub4dos to use the pupsave file which is on SDB1 for about an hour I realised I was not going to get my work done today as nothing is configured correctly without using the pupsave I have on the second drive.

I cannot find any information on a search engine that will lead me to linking the booting fossapup to the pupsave I want to use.

I know this is probably screamingly easy but I would be very grateful for some help to resolve this. So fossapup boots successfully from SDA1 but does not use the pupsave which is on SDB1, and I need it to. I want the boot of fossapup64 to use the pupsave I have on SDB1. How do I do that please?

Minimum information we need:

What specific Puppy version?
Examples:

Fossapup64

Computer specs or make and model?

CPU? An AMD from five years ago
Memory? 16Gig DDR4
Graphics hardware? Onboard AMD
Network hardware? An ethernet port and wifi - ethernet used
It is an HP Pavilion

Any info about the computer can always help.

How is Puppy installed?
Frugal
Installed on what drive?
A 128 gig SSD with ext4
How is drive partitioned?
The partition(s) are formatted what format? They are formatted as ext4 - should have been ext3 I think?
Puppy is installed on which partition? - SDA1
If a installer program was used to do the install - puppy installed itself?

[taersh]

Boot-loader?
Content of e.g. menu.lst - if Grub4DOS boot-loader is used.

[s243a]

If you are using grub4dos then here is some example menu entries where I specify the save folder:

Code: Select all

title Start upupGG+D
  uuid CAEB-E3FF
  kernel /upup/GG/+D/20/10/vmlinuz screen=text pmedia=usbflash pfix=fsck pdrv=CAEB-E3FF psubdir=/upup/GG/+D/20/10/ psave=969e9dc8-e089-4586-a9e2-7ce490246e9e:/upup/GG/+D/20/10/upupgg+dsave 
  initrd /upup/GG/+D/20/10/initrd.gz  

title Start dpup Buster
  uuid CAEB-E3FF
  kernel /dpup/buster/32/PAE/8.0.0/RC2/28032020/vmlinuz screen=text pmedia=usbflash pfix=fsck pdrv=CAEB-E3FF psubdir=/dpup/buster/32/PAE/8.0.0/RC2/28032020/ psave=68a663bc-eb95-4fa2-b0a3-466de2b51d7e:/dpup/buster/32/PAE/8.0.0/RC2/28032020/bustersave 
  initrd /dpup/buster/32/PAE/8.0.0/RC2/28032020/initrd.gz  

For this to work puppy has to be able to find your partition at boot. In theory it should be but bugs are always possible. The uuid numbers (either CAEB-E3FF or 68a663bc-eb95-4fa2-b0a3-466de2b51d7e) were obtained from the blkid command.

[rafkid]

Boot-loader?
Content of e.g. menu.lst - if Grub4DOS boot-loader is used.

# menu.lst produced by grub4dosconfig-v1.9.3
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

# Frugal installed Puppy

title Puppy fossapup64 9.5 (sda1/fossapup649.5frugal)
find --set-root uuid () b86a8e19-2995-473d-bd21-ce7c51a61156
kernel /fossapup649.5frugal/vmlinuz pdrv=b86a8e19-2995-473d-bd21-ce7c51a61156 psubdir=/fossapup649.5frugal pmedia=atahd pfix=fsck
initrd /fossapup649.5frugal/initrd.gz

# Windows
# this entry searches Windows on the HDD and boot it up
title Windows\nBoot up Windows if installed
errorcheck off
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr
find --set-root --ignore-floppies --ignore-cd /io.sys
chainloader /io.sys
errorcheck on

# Advanced Menu
title Advanced menu
configfile /menu-advanced.lst
commandline

[bigpup]

If Originally Fossapup was a frugal install on sda1 and the fossapupsave was on sdb1 and it booted using the save OK.
It should still be working, if you are booting using the correct boot menu entry.
To confirm, it has worked OK before this bad shutdown was done?

There is a chance something is wrong with the save.
If somehow it got corrupted, that could make it not usable.
I assume the save is a save folder on sdb1.
So to check it, and fix errors. You need to check the partition it is on.

Boot Fossapup the way it is now booting, not using the save.
Do not need to do any setup. You just need to run e2fsck.

To test for and repair errors in Linux file system, use "e2fsck".
The partition must be unmounted.
Open a terminal, and enter:
e2fsck -p /dev/sdb1

It will find and fix any errors it finds.

It is best if you can put the save in the same location as the other Fossapup files.
Usually in the frugal install directory(folder)

Do not use boot menu entry that says ram only.
That is telling Fossapup to boot not using the save.

[rafkid]

It has been working for about two months I think. Maybe a bit less. Probably booted 30 odd times. The event that has borked things would appear to be the electricity to the PC going off abruptly. I don't know why I put my pup save file on the main disk. But that is where I found it when I went looking for it a few hours ago. I actually did copy it into the main SDA1 sub directory from SDB1. It is now in two places but is still not used during the boot.

I ran:

2fsck -p /dev/sdb1
datadrivefossa: clean, 2393/122101760 files, 8007714/488378368 blocks

It came back clean as you can see.

VMT to you (Bigpup) and to taersh. Whilst I would love to actually learn something from all of this and find the actual answer I am going to have simply rebuild the system I think in order to save time and get some work done. Thankfully I don't actually save anything on this system yet and I also have my laptop to plug in and get on with things.

Let me know if out of professional curiosity you would like me to delay reinstalling fossapup64 and if you would like me to try anything to get this resolved. Otherwise we can close the plea for help and assistance down for tonight.

Thank you both for such a very swift response to my embarrassing little problem

If Originally Fossapup was a frugal install on sda1 and the fossapupsave was on sdb1 and it booted using the save OK.
It should still be working, if you are booting using the correct boot menu entry.
To confirm, it has worked OK before this bad shutdown was done?

There is a chance something is wrong with the save.
If somehow it got corrupted, that could make it not usable.
I assume the save is a save folder on sdb1.
So to check it, and fix errors. You need to check the partition it is on.

Boot Fossapup the way it is now booting, not using the save.
Do not need to do any setup. You just need to run e2fsck.

To test for and repair errors in Linux file system, use "e2fsck".
The partition must be unmounted.
Open a terminal, and enter:
e2fsck -p /dev/sdb1

It will find and fix any errors it finds.

It is best if you can put the save in the same location as the other Fossapup files.
Usually in the frugal install directory(folder)

Do not use boot menu entry that says ram only.
That is telling Fossapup to boot not using the save.

[taersh]

title Puppy fossapup64 9.5 (sda1/fossapup649.5frugal)
find --set-root uuid () b86a8e19-2995-473d-bd21-ce7c51a61156
kernel /fossapup649.5frugal/vmlinuz pdrv=b86a8e19-2995-473d-bd21-ce7c51a61156 psubdir=/fossapup649.5frugal pmedia=atahd pfix=fsck
initrd /fossapup649.5frugal/initrd.gz

What happens, if you remove these entries from menu.lst:

find --set-root uuid () b86a8e19-2995-473d-bd21-ce7c51a61156

and

pdrv=b86a8e19-2995-473d-bd21-ce7c51a61156

??

[rafkid]

So I deleted the menu items as suggested and the system booted with no drama. It appears to be using my pup save file because I noted it copying everything to ram and also observed the pup save filename in the boot sequence. However it is as if the pup save has been burgled as half the downloaded and installed apps are missing and I have had to reset the sound card and mike etc.

I don't feel as if this is a bug, it is more like a RAM resident file did not get saved to disk when the power went off and puppy is just doing its best to work. I know - that last sentence shows me up as a complete n00b. I just don't have the time to get to the bottom of this properly, to do asking for your time, justice. I was hoping there would a quick fix in a configuration file somewhere. Now I am just conscious of using up goodwill when reinstalling and resetting the wizards would get me where I need to be without using your time.

title Puppy fossapup64 9.5 (sda1/fossapup649.5frugal)
find --set-root uuid () b86a8e19-2995-473d-bd21-ce7c51a61156
kernel /fossapup649.5frugal/vmlinuz pdrv=b86a8e19-2995-473d-bd21-ce7c51a61156 psubdir=/fossapup649.5frugal pmedia=atahd pfix=fsck
initrd /fossapup649.5frugal/initrd.gz

What happens, if you remove these entries from menu.lst:

find --set-root uuid () b86a8e19-2995-473d-bd21-ce7c51a61156

and

pdrv=b86a8e19-2995-473d-bd21-ce7c51a61156

??

[mikeslr]

Hi rafkid,

Sorry about your problem.
While rebuilding your system I recommend that you implement the following.
(1) Edit your menu.lst. By default, grub4dos writes the "pmedia=atahd" argument whenever it finds a Puppy's system files on a hard-drive. Open menu.lst in your text editor and change that to "pmedia=ataflash". [AFAIK, any bootloader can use that argument]. That argument 'tricks' Puppies into 'thinking' they are on a USB-Key. The difference is that you will then be able turn off the "automatic save". After you've booted into Puppy, open Menu>System>Puppy Event Manager, Click the Save Sesssions Tab, change the Save Interval to 0/zero and check the "Ask at shutdown" box. With the automatic save turned off, you will be able to Save manually --there'll be a Save Icon on your desktop; and you'll be asked when you shut-down/reboot. But you'll have reduced the possibility of Puppy being in the middle of an Automatic Save and creating a corrupted SaveFile during a power surge or outage. [It also means that you won't automatically Save broken applications and garbage you've picked up while surfing].

(2) When you've installed your essential applications --those you use regularly and often-- and made your system (e.g. Timezone =) and application (e.g. wifi password) settings, Save and reboot "pfix=RAM". Using grub4dos that's easy to do: At the bottom of Menu.lst is a listing named "Advanced Menu". Select that. The 2nd from the top listing of Advanced Menu's display has the title "title Puppy YOUR PUPPY RAM mode\nBoot up Puppy without pupsave". Select that. File-browse into your Puppy's Folder; Right-click an Empty Space >Select>New Directory; give it a name, e.g. Protect. Then copy your SaveFile into that folder. If anything goes wrong, you can, again, boot pfix=RAM and substitute your 'protected' SaveFile for your damaged one.
On bootup, Puppies only look 2 levels deep for SaveFiles/Folders. Level one is the top of drives/partitions, e.g. sda1. Level two is a 'top-level' folder, e.g. sda1/fossapup649.5frugal. Puppy won't look for SaveFiles at the third level, e.g. sda2/my-stuff/protect. It will interrupt booting and ask which SaveFile/Folder to use if it finds more than one on the 1st and 2nd levels.
You can, of course, create and delete other 'protected' SaveFiles as you flesh-out/alter your system.
By the way, long folder names only serve the purpose of inducing typographical errors. I always keep folder names short even if I run more than one version of a Puppy: e.g. fossa64, fossa64-test, fossa-onUSB.

[taersh]

Yes, it seems the sudden power off caused the problem.
Reinstalling and setting up again everything needed seems to be best.

[rafkid]

Taersh - what a fantastic response from you. You are so very kind, I really appreciate the time you have taken to suggest all of the above. I am looking forward to later this evening now when I will have some time to reinstall in the way you are suggesting.

VMT,

rafkid

[taersh]

Taersh - what a fantastic response from you. You are so very kind, I really appreciate the time you have taken to suggest all of the above. I am looking forward to later this evening now when I will have some time to reinstall in the way you are suggesting.

VMT,

rafkid

I'm sure you meant mikeslr!

[mikeslr]

If you implement the change of 'pmedia=ataflash' discussed above, you may want to consider its effects and work-arounds discussed on this post, viewtopic.php?p=2235#p2235

[bigpup]

Most likely the sudden power off took place while the save was being written to.
Thus it got corrupted, or stuff got half written.
The original install should still be good, those files are read only. The save is the only thing read/write.
Could probably just delete the save.
Reboot and start over with a new clean save.

When you get the save back to the way you want it.
Simply make a copy of it and place it in a safe place. Best on a different drive.
Just make sure to add back. or backup. to the beginning of the copy save name, so it is not seen as a usable save.
To turn it back into a usable save, just remove the back. or backup. from the name.

If something like this issue happens again.
Delete the old save.
Replace with the back up save.
Back to working as it did when this backup save was made

If you do not want to manually do this.
The program Pupsave Backup does this any time you use it.
Makes a backup of the good working save.
It also time stamps the backup, so you know when it was made.