Puppy Linux Discussion Forum

@foxpup
Thanks for correcting my syntax. I tried your correction to the psave code below

psave=sda2:/80dpupbuster64/dpupbuster64save-1

and now have access to my save folder at boot up.

@josejp2424

you could look at the file. /etc/rc.d/PUPSTATE .
if the save specifies the correct address.

I'm not sure how I could have done this as I did not have any persistence in that I didn't have a working save folder therefore each time I rebooted I got another fresh copy of dpupbuster. However, now I have a working save folder I will look at it. I'm short of time to do this now but I will try this latter and report back.

Regards,

Ken.

keniv wrote: Wed Jan 13, 2021 1:28 pm

@josejp2424

you could look at the file. /etc/rc.d/PUPSTATE .
if the save specifies the correct address.

I'm not sure how I could have done this as I did not have any persistence in that I didn't have a working save folder therefore each time I rebooted I got another fresh copy of dpupbuster. However, now I have a working save folder I will look at it. I'm short of time to do this now but I will try this latter and report back.

Regards,

Ken.

Below is the contents of /etc/rc.d/PUPSTATE.

PUPMODE=12
PDEV1='sda1'
DEV1FS='ntfs'
PUPSFS='sda1,ntfs,/80dpupbuster64/puppy_dpupbuster64_8.0.0.sfs'
PUPSAVE='sda2,ext4,/80dpupbuster64/dpupbuster64save-1'
PMEDIA=''
#ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
ATADRIVES=''
#ATAOPTICALDRIVES is list of non-usb optical drives...
ATAOPTICALDRIVES=''
#these directories are unionfs/aufs layers in /initrd...
RW_LAYER='/pup_rw'
SAVE_LAYER='/pup_rw'
PUP_LAYER='/pup_ro2'
#The partition that has the dpupbuster64save file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV='sda1,ntfs,/80dpupbuster64/zdrv_dpupbuster64_8.0.0.sfs'
FDRV=''
ADRV=''
YDRV=''
#Partition no. override on boot drive to which session is (or will be) saved...
PSAVEMARK=''
PSAVEPART='sda2'
PSAVEDIR=''
PSUBDIR='/80dpupbuster64'
PUNIONFS='aufs'
DOIMODS='yes'
DOMIBS='no'

This line,

PUPSAVE='sda2,ext4,/80dpupbuster64/dpupbuster64save-1'

I presume controls how dpupbuster saves. It looks OK to me though I,m no expert on this stuff. Has this line now come from my menu.lst entry?

Also is this line part of the save process.

PSAVEPART='sda2'

Again it looks OK to me though I'm not sure what PSAVEPART is/does.

Regards,

Ken.

@keniv
This is after you have booted with the path to the pupsave in the boot parameters?

foxpup wrote: Thu Jan 14, 2021 6:07 pm

@keniv
This is after you have booted with the path to the pupsave in the boot parameters?

Yes that's correct. This is what I have now I have access to the save folder and I only got this access when I used the correct syntax after psave=.

Regards,

Ken.

Well I've got back to trying 64bit DpupBuster 8 and now I have another problem in that I cannot get the package manager to populate. I double click on it's icon on the desktop which opens a dialogue box. I then select the button for "update the package repros". I then get another dialogue box which after a while shows a list of updated packages with "please wait" (please see attached image). After that nothing appears to happen. If after waiting for sometime I attempt to close the box by clicking "x" it freezes. After clicking a number of times I get a message with something like GDKdialogue 0.5 is not responding and I'm given the options to "cancel" or "end process". If I choose "end process" it does close. I can't see the point of having a package manager which is not populated so I assume it should be. Am I doing something wrong? Can somebody tell me how I should go about getting the package manager to populate?

Regards,

Ken.
PS I had trouble either previewing or submitting this in DpupBuster 8 using SeaMonkey so I copied it to a blanc file and am now going to attempting to post it from Slacko 7 using Firefox. Well preview worked OK so now for submit.

I had similar problems in my MISUNDERSTANDING of syntax for PSAVE=.

My corrected PSAVE is

psave=sda6:/FOLDER-PATHNAME/

That ending "/" is IMPORTANT so include it as shown.

Since syntax correct use, I have had no problems in getting my PUPs to find the folder where ALL of my session files are kept.

Puppy ONLY search root of drives UNLESS you specify the folder location of our session files via PSAVE.

Today, ALL of my saved-sessions for ALL of my PUPs are kept in my folder named "/Sessions/" and ALL of my WoofCE PUPs and my forum DOGs are booted from their ISOs in "/boot-isos" folder.

Things have gotten all so simple now. And every PUP need is found in these 2 folders. I no longer do a Frugal as it is NOT needed anymore.

This process allows me to download any new WoofCE PUP to my /boot-isos folder. ... boot the system ... select the ISO I want .... save the session when complete in /Session. Boot, again, the PUP ISO, edit (e) the linux line adding psave=... F10 to boot with save(s) found or listed if there are multiples for the PUP.

Hope this is helpful.

Clarity wrote: Thu Jan 21, 2021 10:00 pm

Puppy ONLY search root of drives UNLESS you specify the folder location of our session files via PSAVE.

I think that's not entirely accurate, at least in my system. I use Dpupbuster 8, my pupsave folder is inside another folder (dpupb64), and I don't use PSAVE at all (only PDRV, PSUBDIR and PMEDIA). However, my system finds my pupsave with no problem

...back again to Puppy after a long absence in the Windblows environment.
I picked DpupBuster to guide me back into the Puppy Linux fold, having a long-standing assignment for a research project and finding a little "down-time" to recobble a desktop machine together for the express task of video analysis. I am trying to use one of my old chestnut software I often mentioned on the Murga forum, CowLog http://cowlog.org/download/ (Down the track I hope to include Ronald Blakendaal's DOSBoxGameLauncher in this Puppy via the PPA avenue developed by savoury1 https://launchpad.net/~savoury1/+archive/ubuntu/dbgl, but that is a story for another day.)
I've installed VLC 3.0.12 Vetinari via PPM, and I've got sound and video working fine, but I have what appears to be a font problem (???) as indicated in my attached screenie. It shows the emboldened "Maternal vigilance...json" file listed as a string of empties. Can anyone please suggest a workaround for me please?

My current getup is (truncated):

System:    Host: dpupbuster64 Kernel: 4.19.23 x86_64 bits: 64 compiler: gcc v: 7.3.0 
           Desktop: JWM 2.3.7 Distro: Puppy 8.0.0 
Machine:   Type: Desktop Mobo: Gigabyte model: 990FXA-UD3 serial: N/A BIOS: American Megatrends 
           v: F2 date: 07/15/2013 
Battery:   Device-1: hidpp_battery_0 model: Logitech M585/M590 Multi-Device Mouse charge: Normal 
           status: Discharging 
CPU:       Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP arch: Bulldozer 
           L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 64316 
           Speed: 1406 MHz min/max: 1400/4000 MHz Core speeds (MHz): 1: 1406 2: 1406 3: 2371 
           4: 1408 5: 1405 6: 1406 7: 1797 8: 1629 
Graphics:  Device-1: NVIDIA GT218 [GeForce 210] vendor: ASUSTeK driver: nouveau v: kernel 
           bus ID: 01:00.0 
           Display: server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: NVA8 v: 3.3 Mesa 18.3.6 direct render: Yes

UPDATE: hmm it doesn't *seem* to be a javascript issue at present, testing across recent Puppy64 versions. I might have to slink back to Windaze for this particular problem Not Happy, Jan...

Questions:

• Are you using nVidia driver?

• AND, is your monitor VGA/DVI/HDMI?

• And, is your display device a monitor or a TV?

These are becoming increasingly important questions-answers for BOTH video and audio coming from our PCs.

I have to confess to being disappointed with both 32- and 64-bit versions of this.

64-bit version needed multiple kernel swaps before finding one that would actually work. I don't like PulseAudio; never have done. Retrovol will install, but refuses to work properly. Plus a lot of other niggling little things.....

32-bit, every single time I booted into it, it had lost my network connection, and insisted it couldn't even find a kernel module driver. It appears to be set-up for Frisbee and wireless by default? What about those of us using desktops on Ethernet? And after I reset it the first time, I then found out that, somehow, every other Puppy in the 'kennels' had also lost its network connection..! NOT IMPRESSED. I didn't bother with it any further....

Sorry, Jose. I'd love to be able to praise these the way many others are doing, but I have no basis to do so.....

(*shrug*)

Far be it for me to be the sole voice of dissent, but I cannot give a thumbs-up to something that just won't work for me. Sorry and all that.

Mike.

@keniv :-

With regard to your 'invisible' save-folder, erm.....pardon me for saying it, but we're kinda going back to 'Puppy-school basics' here.

You couldn't get it to see the save-folder on sda1, but it was discovered immediately on sda2, yes? You know WHY, don't you?

The original save-files would work anywhere.....because they contain their own Linux file-system inside. The more modern save-folders, on the other hand, require an underlying Linux file-system to work correctly, and be recognised. So:-

sda1 : NTFS - Not found/seen. It's a Windoze file-system, right?

sda2 : Ext4 - Found & used straight away, yes..? Because it's a Linux file-system.....

I'm surprised everybody else missed this, although I believe Jose alluded to it further back in the thread.....

(*shrug*)

Mike.

mikewalsh wrote: Sun Feb 28, 2021 9:39 pm

@keniv :-
The original save-files would work anywhere.....because they contain their own Linux file-system inside. The more modern save-folders, on the other hand, require an underlying Linux file-system to work correctly, and be recognised. So:-

sda1 : NTFS - Not found/seen. It's a Windoze file-system, right?

sda2 : Ext4 - Found & used straight away, yes..? Because it's a Linux file-system.....

Hi Mike,
Yes I did know that a save folder had to be on a linux file system hence the reason for making an ext4 partition on the disk. What baffled me was that I had allowed DpupBuster to make this folder on shutdown so it presumably knew it was on sda2 but on reboot it did not find it. I think I explained this on the third page of this thread starting three posts down i.e.

I downloaded the 64 bit openbox (122020) version of the iso. I have two partitions on an hdd. sda1 is formatted ntsf and sda2 is formatted ext4. I made a manual frugal install on sda1 and booted with grub4dos. This booted up OK. I made a few setup changes and set up wifi them shutdown. On shutdown I was offered the choice to save to a file or folder. I chose a folder. This process seemed to work OK and the folder was made on sda2 (ie on the ext4 partition) as /80dpupbuster64/dpupbuster64save. This file seems to be populated (please see attached image). However, on rebooting this file is not loaded so I get a fresh boot each time. 80dpupbuster64 is the folder on sda1 that contains the frugal install. I did wonder about why this was there but as the process of making the save folder is largely automated I can't see that I've done anything wrong. I'd welcome any ideas as how to fix this.

In my next post I included the menu.lst entries for DpupBuster and Bionicpup. I had also allowed Bionicpup to make a save folder in sda2(ext4). However, this save folder was detected on reboot. I have subsequently installed QuickPup again allowing it to make a save folder on sda2 and this also was detected on reboot without having to add extra information to the menu.lst entry as I had to do with DpupBuster i.e.

psave=sda2:/80dpupbuster64/dpupbuster64save-1

I think it's fair to say, that for me at least, there is a bit of an inconsistency in how save folders work from one puppy to another. Perhaps I should expect this. However, as you can see on page 4 of this tread 5th post down I also had trouble with getting the ppm to populate as well as seamonkey which I could not resolve and so I'm sorry to say I've largely given up on DpupBuster.

Regards,

Ken.

@keniv :-

No probs, mate. I, too, feel the same. from what I can see of them, they're nice Pups.....but there ARE inconsistencies with how they work on different machines.

Shame. Ah, well; plenty more Pups in the pound..!

Mike.

Yep, I agree with that. As someone who doesn't have a lot of expertise I seem to struggle more with some modern pups than I remember doing with older ones. Save folders are an example. I know there are advantages to having save folders as opposed to save files but I don't remember having trouble setting up save files. Anyway, grump over.

Regards,

Ken.

Hi,

regarding the problem of "not finding the savefolder on another partition (like @keniv reported):

Last year (August/September 2020) I did a few tests with DpupBuster.

1. frugal install on usb-stick, frugal install on sdb1 (FAT32), booted via grub4dos. Savefolder created on sdb2 (ext3)
On reboot all went well, savefolder was found ... (I tested dpupbuster32PAE800uefibeta4_04012020 and dpupbuster32PAE800uefiRC2_28032020).

2. frugal install on ssd, frugal install on sdb1 (FAT32), booted via grub4dos. Savefolder created on sdb2 (ext4). This time the savefolder was not found on reboot, I had to use the <psave=> - argument to boot with the created savefolder. (I tested dpupbuster64-8.0.0-mate-beta4-22092020).

May be the problem is related to the format of the "savepartition" --> ext4?

peace

one wrote: Wed Mar 03, 2021 10:10 am

May be the problem is related to the format of the "savepartition" --> ext4?

This might be the case in DpupBuster, however, as I've said previously,

I had also allowed Bionicpup to make a save folder in sda2(ext4). However, this save folder was detected on reboot.

and so making a save folder and it being detected on reboot on an ext4 partition does work for Bionicpup.
I would consider changing the format of sda2 to ext3 if it did help in making save folders less problematic .

Regards,

Ken.

keniv wrote: Wed Mar 03, 2021 1:20 pm

one wrote: Wed Mar 03, 2021 10:10 am

May be the problem is related to the format of the "savepartition" --> ext4?

This might be the case in DpupBuster [...]

Regards,

Ken.

Yes Keniv, DPupBuster is what I'm talking about - not Bionicpup or any other puppy. I test a lot and DPupBuster is the only one (in my experience) that shows this problem ...

peace

Sorry - double post

@ Clarity, sorry I missed your reply earlier - RL issues have been quite pressing lately:

Clarity wrote: Fri Feb 26, 2021 4:47 pm

Questions:

• Are you using nVidia driver?

• AND, is your monitor VGA/DVI/HDMI?

• And, is your display device a monitor or a TV?

These are becoming increasingly important questions-answers for BOTH video and audio coming from our PCs.

I didn't mention that both sound and images from the video are excellent - monitor Benq XL2411T has all those ports (i use audio via headphones if required), but running the desktop setup via DVI. Just using the standard video driver, not the NVIDIA pet etc. I have seen this kind of issue before (other Puppies, other software) which made me think of missing fonts - will install TTL libraties etc and post back when successful, cheers

i'm sorry if I missed it, but SAVEMARK doesn't seem to have been mentioned as a solution to having the install location and the save location on different partitions of the same device.
In @keniv 's case a text file named SAVEMARK that contains just "2" (without the quotes), stored in the install location should have done the trick.
In a console, issue a command like the following:

echo "2" > /path/to/install/location/SAVEMARK

SAVEMARK is an ancient Puppy mechanism, that still works in the latest woof-ce Puppies.

I would not be surprised if some of @keniv 's old Pupppies installed on sda1, do contain a SAVEMARK file in the install location.

Note: If SAVEMARK is used, Puppy does assume that the sub-directory of the save location is the same as the sub-directory of the install location.

FYI
This leads us to a "Topic Area" (wiki? or google doc accessible by all users) for examples to use cases such that boot-time session finding is understood and minimized. This would go a long way for future users and developers of an IMPORTANT basic of PUPs.

Current documentation is not necessarily clear enough for good understanding as it intermingles file and folder operations. That documentation could stand for some restructuring making things more apparent.

I am willing to work with anyone on such to promote a clearer understanding with examples if anyone wants. PM me should you desire.
FYI

Finding the save, is something that has gone back and forth in Woof-CE coding, of the basic operations, of booting Puppy.
It seems to change, with the wind, on what the boot process, will do.

Several Puppy versions back.
The boot process would keep looking on any drive, any partition, until it found the save.
Then the idea changed to the save, should be in the same location, as the other Puppy files.
That would be the only place to look for them.
Then it went back to looking in more places.
Then the idea of putting Puppy on a USB stick, would be best if the save was only on, that USB stick.
So, using the stick on another computer. The USB stick would have the save, along with the Puppy, booting from it.

Then people started complaining about the time that it was taking to boot, because all drives, where being searched, for the save.
So, lets limit where to look for the save.

Another issue was, how far into the layers of directories, do you go looking.
2, 3, 4, 5, unlimited directories deep, and do this for each partition, searched on all drives.

Then it became what pupmode are you running in.
From a CD/DVD the save has to be on another drive, unless you are saving back on the CD/DVD.
So it needs to look on all drives.
Installed on a USB flash drive, usually the save is on the USB drive. Why look other places.
Installed on an internal drive. The save should be on that same drive. So why look on other drives.

Then you have the people that seem to want to put the save, anywhere but the drive, Puppy is installed on.
Again, the question of how long do you want the boot process, to slow down, looking for the save.

So over the years, finding the save, has changed.
Depending on the version of Puppy.
It is looking for the save, based on what was being done, at that time, in the boot process.

Only thing for sure.
If the save is in the same place as the other Puppy files. It should be found, with no problems.
That has always stayed, as the first place to automatically look.

Hello. I would like to say thank you to josejp2424 for putting this wonderful puppy together. I've been playing with Dpup Buster 64 XFCE version since January and this has become my favorite puppy. I think this is the best XFCE puppy so far. I guess puppy+debian+xfce has the greatest appeal for me. Is a new version coming perhaps with the latest XFCE release?

I haven't encountered booting issues like others perhaps because I normally do manual frugal install of my puppies. I just copy puppy_dpupbuster64_8.0.0.sfs, zdrv_dpupbuster64_8.0.0.sfs, vmlinuz and initrd.gz to a folder in my drive (say DPupBuster8) then add entries to grub.

Sample menu.lst entry for grub 2.

title DPupBuster 8.0
  find --set-root uuid () 642E78822E784ED4
  kernel /DPupBuster8/vmlinuz  pdrv=642E78822E784ED4  psubdir=/DPupBuster8 pmedia=atahd pfix=fsck,copy
  initrd /DPupBuster8/initrd.gz

Sample grub.cfg if you're using this.

menuentry "DPup_Buster"{
	set root='(hd0,1)'
	search --no-floppy --fs-uuid --set=root 642E78822E784ED4
	linux /DPupBuster8/vmlinuz root=UUID=642E78822E784ED4 psubdir=/DPupBuster8 pmedia=atahd pfix=copy,fsck
	initrd /DPupBuster8/initrd.gz
}

-ronriel

ronriel wrote: Thu Apr 15, 2021 4:12 am

Sample grub.cfg if you're using this.

Code: Select all

menuentry "DPup_Buster"{
	set root='(hd0,1)'
	search --no-floppy --fs-uuid --set=root 642E78822E784ED4
	linux /DPupBuster8/vmlinuz root=UUID=642E78822E784ED4 psubdir=/DPupBuster8 pmedia=atahd pfix=copy,fsck
	initrd /DPupBuster8/initrd.gz
}

Just a little thing.
It looks as if you set root twice.
My guess is you can leave out the first line (or the second) under the menuentry line.

I've been using dpupbuster64-8.0.0 RC3 (jwm version) daily for awhile now. It has been
stable. I use the latest version of firefox (now at 88). A couple of apps were broken, and
I used PupClockset-2.7.pet and htop-2.0.2-x86_64.pet (easily found). abiword wasn't
installed but can be installed via PPM.

There is a very long delay (over a minute) before wireless starts to connect at startup.
I found that clicking on the htop desktop icon kills any delay. I haven't been able to
discover how to automate this workaround. Startup scripts don't do the trick.

It's unfortunate that this particular dpup version has never been fixed and raised to
release level. I really enjoy using this potential gem!

art

Just a quick note that DpupBullseye-9.7.0 beta was released a couple days ago. I've been using it the past couple days and it's quite nice.

Thanks for the info on bullseye, dasouth. It has the same old issues with htop and pupclockset.
The delay after startup before (sns) wireless connection process starts is far lower at about 20 seconds.
I could not find a word processor (such as abiword) installed. There are a few improvements and
a few things that are worse compared to 8.0.0 jwm.

art

@art
I'm in total agreement with some improvements and also some regressions with this build.
Anytime I have a new distro, I know I'm going to spend a bit of time setting it up so that it's usable for me.

Just to say thanks, josejp2424, for another really nice Puppy.
I haven't completed exploring. But AFAICT so far, it is able to run all the portables and AppImages that Fossapup64 can. Looking forward to your 'Bullseye' version preferably JWM-Rox. Hint, Hint.

Edit: Found your duveanpups, viewtopic.php?p=26799#p26799. Something new to learn.

Is this still alive?