Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012

[greengeek]

Good on you both for persisting with this. It looks like some deeper understanding may come from it. I will certainly gain from knowing more about the boot process and pmedia etc commands and how they actually affect the booting. It might help me resolve some of the oddball issues I sometimes have when booting from multi-Pup installs. I've noticed things don't always go quite the way for me that they seem to for others, so it is handy to see tricky issues worked through thoroughly. It is often the exceptions that require the deepest investigation, rather than just persisting with shortcuts that happen to work...

[otropogo]

Good on you both for persisting with this. It looks like some deeper understanding may come from it. I will certainly gain from knowing more about the boot process and pmedia etc commands and how they actually affect the booting. It might help me resolve some of the oddball issues I sometimes have when booting from multi-Pup installs. I've noticed things don't always go quite the way for me that they seem to for others, so it is handy to see tricky issues worked through thoroughly. It is often the exceptions that require the deepest investigation, rather than just persisting with shortcuts that happen to work...

Thanks,

Have wasted most of the afternoon with more experimentation, mostly disastrous, but with a few tidbits of info gleaned.

1. Bootflash install Puppy to USB, which I used to reinstall after my flash card somehow got corrupted, and failed with a simple

boot error

message (I recommend locking the SD card except when modifications are needed) requires some tweaking, at least when you use the iso to install. The syslinux.cfg generated consists of only one line, and provides no boot command line.

So I copied all of the boot messages and the isolinux.cfg file from the LiveCD to the flash card, renaming the last syslinux.cfg. This gives you the option of modifying the boot parameters from the command line when the syslinux configuration fails to work.

2. pmedia=atahd psubdir=pupsave is a bit misleading. It displays all lupusave.2fs files found in "pupsave" directories, including any on a flash card.

3. when you load the 528.sfs and the 2fs file from different partitions, both partitions are automatically mounted and neither can be unmounted (this is indicated by the red dot on the desktop icons for both)

4. the source partition for the 2fs file automatically becomes /mnt/home, and can be written and saved to

5. the source partition for the sfs file if different, is no longer found in the normal /mnt/ path. If you click on the desktop icon, you can open it on the desktop, and see that its path is /initrd/mnt/dev_ro2

It's not clear whether you can write to the drive at all under these conditions. I tried to do a Pupsave Hot Backup to the drive, and I couldn't browse to it in the app's gui.

When I entered the path manually in the gui's navigation window, and tried to save a hot backup that way, I got the response:

not enough free space

My dev_ro2 (normally sda1 or home) currently has about 90GB of unused space, and the file being saved is only 32MB! So I'd say this configuration spells nothing but trouble for the user. I decided not to risk the data on my hard drive by exploring this mystery.

It would be interesting to know how or why such an arrangement came about. After all, when both sfs and 2fs are loaded from the same partition, that partition is perfectly writable. In fact, most of my saves are to folders in the /mnt/home directory.

The one possibly useful function of loading 2fs and sfs from different partitions is to tell you (if there's any doubt) the location of the sfs file loaded into RAM.

[rerwin]

Will try running lsmod later. The drop down menu I referred to is the one presented by hitting the "load module" button in the Puppy Network Wizard gui. The list displays neither 8191 nor 8192 modules, although on my Toshiba, it offers to (and does) install) a working wireless module.

To determine the precise vintage of my regular 2fs file, I'd have to go through my postings for many months. That will take some time. However, I think it's likely it originated with lupu_525, and it's certain that I used 528 patch upgrades, as they're still shown in the petget list of installed pets.

It's too bad petget doesn't display the dates of installation for pets. That would help. I also wish I had uninstalled all of these before going on to newer versions, as I'm a bit antsy about what the uninstallation of an earlier pet might do to the currently installed app. It would make more sense if petget automatically uninstalled the earlier pet for a given application before installing the new one, after taking over the configuration.

otropogo,
I don't know, right now, how that module list is generated, so cannot explain why you module in not listed.

As for your regular pupsave, I am very pleased that you ran the update patch. That removes a lot of possible contaminants.

Regarding uninstallation: That process either removes the installed files or replaces them from the lupu528 SFS file (the original in the distro). If you have multiple versions of a pet installed, uninstallin any of the versons will do that deed, so that any alternate version will be lost. So, if you have the latest pet for a package, I suggest uninstalling each of the versions, then installing the latest. If any of the installed pets are for relevant wifi drivers, uninstalling each of those would eliminate potential conflicts. You could then reinstall the module-pet that works elsewhere, if necessary.

Regarding the date of pet installation, check the modify date (list mode) of the "/root/.packages/*.files" files, which should correspond to when they were installed. Those files list the files that would be uninstalled. If there are also any "remove" (not sure of the exact name format) files, they are the "puninstall" scripts to do additional cleanup upon uninstallation.

[otropogo]

...

Regarding the date of pet installation, check the modify date (list mode) of the "/root/.packages/*.files" files, which should correspond to when they were installed. Those files list the files that would be uninstalled. If there are also any "remove" (not sure of the exact name format) files, they are the "puninstall" scripts to do additional cleanup upon uninstallation.

Thanks for the further explanation.

Have done as suggested, but the results are a bit puzzling, because of the earliest "modify dates". I haven't found a way to copy and paste this display, other than as a screen save, which I'll try to post here. The earliest dates are for "Packages-Ubuntu-Lucid-xxx, dated April 30, 2010. Is it possible that my 2fs file is that old?

Next come Puppy 5 and Quirky packages dated February and May 2011, followed by a dozen Ubuntu and Puppy packages all dated the same date and time to the second on August 17, 2011.

The first pet install I recognize in the list is xfprot_2.4 on Sept 8, 2011.

This suggest to me that my 2fs file was created on August 17, 2011. But how to explain the prior dates then?

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.

[otropogo]

Have been playing further with USBflash boot creation, and discovering more and more pitfalls along the way.

Aside from third party bootlash apps, there are two Puppy menus to accomplish this, and a number of bifurcations on those.

My latest attempt was to use Puppy Universal Installer. For reasons I don't understand, choosing the seemingly obvious first option on the menu:

setup/Puppy Universal Installer/USB Flash drive/sdc Generic USB CF reader, size 244.3 MiB/ install Puppy to sdc

The only other option on this menu is apparently entitled "Superfloppy", but if you read the largish text carefully, it turns out that the option I chose is the superfloppy one, which leaves the CF card without any partitions, so that it appears simply as sdc on the desktop.

After installing, for which one must either have a LiveCD mounted or an iso opened on the system, I found that the CF card had a usbflash marker placed on it. I added the boot messages from the iso and also a pre-created 2fs file, renamed isolinux.cfg syslinux.cfg, and changed the line pmedia=usbflash to pmedia=atahd.

On rebooting, I discovered that the loader ignored the change, and booted with the sfs and 2fs files on the card. I tried renaming the usflash marker, but that made no difference, nor did moving the marker to one of the hard drives, that only accomplished automounting that drive as well.

In order to boot automatically with the sfs file on the hard drive, and be able to choose among the three 2fs files available,I had to:


1. delete the usbflash marker completely, and

2. add the arguments

Code: Select all

pdev1=sda1 psubdir=pupsave

after

Code: Select all

pmedia=atahd

in sytslinux.cfg

It's still not clear exactly what,

Code: Select all

 pmedia=atahd

does. I suspect it's superfluous, but haven't tested this yet.

Code: Select all

pdev1=sda1 psubdir=pupsave

also behaves unexpectedly.

Logically, it should look only in sda1/pubsave for both the sfs and the 2fs files. But in reality, it looks for a pubsave folder in all of the available drives, including the partitionless CF card, (which can hardly qualify as an atahd).

Will try a few more test reboots to clarify this further.

Update - following numerous reboots rewrites of syslinux.cfg, I've learned that:

1. the argument

Code: Select all

pdev1=sda1

seems to accomplish nothing, leaving it out between

Code: Select all

pmedia=atahd

and

Code: Select all

psubdir=puppy

One would expect it to limit the loading of 2fs files to those in sda1/pupsave, but in fact, all 2fs files in /pupsave/ folders on all available drives are presented. Perhaps it would allow the loading of lupu_528.sfs from a drive other than sda1, if that was desired. But if the sfs is on sda1 that argument seems pointless.


2. my attempts to limit the presentation of 2fs files to those in sda1/pupsave with the entry

Code: Select all

psubdir=sda1/pupsave

and

Code: Select all

psubdir=/mnt/sda1/pupsave

all resulted in a lockup with a message the lupu_528.sfs couldn't be found.

I tried various ways to circumvent this at the boot command line without having to modify the syslinux.cfg line, but all of these failed the same way, including the various boot drive override options


3. after removing both the pdev1= and psubdir= arguments, and leaving only

Code: Select all

pmedia=atahd

, Puppy automatically loaded both the sfs and the 2fs file from the CF card, without offering any other options. I tried putting a marker file caled atahd in the root directory of sda1, since the loader obviously can't distinguish hard drives from any other drive, but it made no difference.

4. However with configuration #3, I was able to modify the loading procedure by entering

Code: Select all

psubdir=pupsave

at the boot command line. The loader then offered all of the 2fs files in the sda1 and sdc pupsave folders, as well as the "0" option.

So it appears one can amplify the last line of the syslinux.cfg file, but not contradict it.

For emergency uses, this last configuration would seem to be the best, as it's the most flexible, allowing one to choose loading from hard drive or from flash media with a simple reboot, without having to somehow get an OS running to access and edit the file.

A final (I hope!) update.

Still hoping to discover some utility in the pdev1=sdxx argument, I rebooted with the minimalist syslinux configuration last described above, and at the boot prompt entered:

Code: Select all

puppy pdev1=sdb1 psubdir=pupsaveC

This resulted in the autoloading of the only 2fs file in the pupsaveC folder (the only such folder on the system), on sdb1. That folder also contains a copy of the standard 139 MB version of lupu_528.sfs. And the reason for the pdev1 entry was to see whether that version would be loaded.

It wasn't. The loader ignored the pdev1 argument, and loaded the libreplus version from sda1/pupsave instead.

I would welcome a correction, but until I see evidence to the contrary, I conclude that the code pdev1=sdxx is entirely useless. Apparently, the puppy loader looks for the first instance of a lupu_528.sfs file, starting with either the boot media or root directory of the first partition of the first hard drive, and loads it. I forgot to test this adequately, but will do so after posting this.

The good news is that one can leave a spare 2fs file or two and a spare sfs file in another directory on a secondary drive, and call is up as needed from the boot command line with nothing more than an appropriate psubdir argument

And possibly when the usual sfs file fails for some reason, the puppy loader will deign to use the next copy in line.

Further update. Several hours more of testing leave me more dumbfounded than ever. My guess as to how the puppy loader selects the sfs file to load proved wrong, and I couldn't make any sense of what actually happend. See my next post below on loading.

[ansivar]

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.

For rt8192 with k2.6.33.2 try this:
http://www.murga-linux.com/puppy/viewto ... 469#462469

[otropogo]

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.

For rt8192 with k2.6.33.2 try this:
http://www.murga-linux.com/puppy/viewto ... 469#462469

Thanks. I do have the problem fixed now, after using depmod on my 2fs file. That is, Network Wizard is able to detect the wifi device and install the driver.

However, I am still puzzled as to why the driver doesn't appear in the load list as the r8169 does.

[otropogo]

Have just completed a dizzying series of test with a newly configured USBflash boot card, trying to figure out how to control which version of the lupu_528.sfs file is loaded.

Have established that:

1. pdev1=sdxx will not determine the partition from which the sfs file is loaded

2. psubdir=folderx will not determine the /partition or /partition/folder from which it's loaded

3. no matter what is written in syslinux.cfg or entered at the boot command line, the loader always boots from sda1 if a lupupluslibre sfs is located there.

4. the loader always loads lupupluslibre instead of lupu_528 standard, even when the latter is in the root directory of sda1 or in a higher subdirectory (ie. earlier in the search order).

5. when lupu_528 (standard) was initially installed earlier today to a CF flash card, the entry:

Code: Select all

pmedia=atahd 

Without further arguments, would make it load the 139 MB standard sfs from the card, without presenting any other options.

Adding

Code: Select all

psubdir=pupsave

, either in syslinux or at the boot command line, would cause it to present all of the 2fs files found in all of the /pupsave folders on the system, including that on the CF card itself.

In the second configuration, however, no matter which 2fs file was selected, the lupupluslibre sfs would be loaded from sda1.

6. after a good deal of rebooting, however, booting with the same code

pmedia-atahd

also resulted in the 353MB libre version being loaded!

7. it doesn't matter how one renames the folder holding the lupupluslibre sfs, the loader finds it and loads it instead of the standard sfs. The psubdir argument affects only the location of the 2fs files made available for loading.


Can anyone make sense of this?

[ICPUG]

You might like to read this post and those around it:

http://www.murga-linux.com/puppy/viewto ... 119#652119

The discussion spreads over pages 9-11 of the thread and sorta peters out without a definitive answer after rcrsn51 found a solution to his particular problem.

Shinobar makes an interesting contribution in his post of Wed 12 Sep 2012, 22:02.

I think you are being a bit draconian in your last post in suggesting pdev1 or psubdir are not doing the job. I think in certain circumstances you may be right but not in all circumstances. I have a multitude of pups on my PC each in their own (hard drive) subdirectory. I do have sfs files and associated save files in the same subdirectory though. I use pmedia, pdev1 and psubdir for each pup in its own section of the boot config file (I use grub4dos and menu.lst). I don't like putting any pup in the root folder of a partition. So far I have not experienced the conflict you are reporting. I must run some tests and see if I can replicate your problems.

[ICPUG]

I've run a couple of tests. My current set up has Lupupluslibre and standard Lupu in 2 subfolders of my sda5 partition. Booting each separately I create a file in the home directory to identify which lupu I was in. This was done to be sure I had the correct save file loaded in subsequent tests.

Test 1
I moved lupupluslibre and its save file into the root of sda5 and used the following menu.lst with grub4dos:

##############################################
# GvR Sept 30th 2004
color black/cyan yellow/cyan
timeout=5
default=0

title Default Boot on HD 0
rootnoverify (hd0,0)
chainloader +1
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda5
kernel (hd0,4)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda5 psubdir=lupu5285 video=640x480
initrd (hd0,4)/lupu5285/initrd.gz
boot

title LupuPlusLibre Linux 5.2.8.005-2 from NTFS sda5
kernel (hd0,4)/vmlinuz PMEDIA=idehd PDEV1=sda5 video=640x480
initrd (hd0,4)/initrd.gz
boot
##########################################

I first booted to Lupupluslibre and because I had not specified psubdir since it was in the root of sda5 it offered me a choice of save files. I chose the lupupluslibre file and it booted fine. I checked for the file in home and I did indeed have the lupupluslibre save file.

I now rebooted and chose to boot standard lupu. According to point 4 of Otropogo's post, Lupupluslibre was going to boot anyway. It didn't. Standard Lupu booted without offering a choice of save files. I checked the file in the home directory and it was indeed the standard lupu save file.

Test 2
I now copied standard lupu to a similar folder on my sda1 partition. Using the following menu.lst:

##############################################
# GvR Sept 30th 2004
color black/cyan yellow/cyan
timeout=5
default=0

title Default Boot on HD 0
rootnoverify (hd0,0)
chainloader +1
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda5
kernel (hd0,4)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda5 psubdir=lupu5285 video=640x480
initrd (hd0,4)/lupu5285/initrd.gz
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda1
kernel (hd0,0)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda1 psubdir=lupu5285 video=640x480
initrd (hd0,0)/lupu5285/initrd.gz
boot

I first booted to the Lupu on sda1 and changed the file in the home directory to uniquely identify it with this partition.

I then booted Lupu from sda5 again. It worked and the file in the home directory hadn't been changed so I know I had the right save file.

So Otropogo's point 1 that pdev1 will not determine the partition from which the sfs file is loaded is clearly not true in my setup.

I have also extracted the init file of standard lupu 5.2.8-005 for review. I am going to try to flowchart the 'Finding Puppy Files' routine but as it consists of 8 A4 pages of Barry's bash scripting I may be a little while!

[bigpup]

Seems to me placement of these entries are important. There is a logical order to what they are telling the boot process.
Basically where to look in this order:
PMEDIA (What device).
PDEV1 (What partition).
PSUBDIR (What directory or sub-directory).

I think all three have to be used, in a boot entry, to get the desired results.

This post is a little old, but it basically holds true to how it works.
http://www.murga-linux.com/puppy/viewtopic.php?t=35003

ICPUG,
You may want to look over this very well written info post.
Thanks for this, Helped me understand in my early days with Puppy.

[otropogo]

...
This post is a little old, but it basically holds true to how it works.
http://www.murga-linux.com/puppy/viewtopic.php?t=35003

Thanks for the link. I believe the processes are a bit more complicated then shown, but the post makes a good basis for further testing.

BTW - I've discovered an error in my methodology for determining which sfs was actually loaded (which provided three different desktops, one of which was not what it seemed - lupupluslibre).

It would help if I knew of a quick, simple, and certain way of determining which sfs is loaded (the two I'm using exclusively ant 582_005(standard -129MB) and lupupluslibre (353MB). All I can say for certain now is that when only one partition is automounted (red dot on icon), it means that both 2fs and sfs files were loaded from that partition, and when two are autoloaded, the one that isn't shown as /mnt/home is the one from which the sfs file was loaded.

I have come across at least two more anomalies in my testing - one is that pmedia=atahd , without further arguments, can sometimes result in a boot from sdb1 instead of sda1, even when both have intrd.gz and the sfs file.

I'll try to replicate and further define this later (my scribbled notes have proven inadequate).

The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.

I have also discovered that pmedia=usbflash psubdir=pupsave results in a failure to find lupu_528.sfs, lockup of the system, even though pusave exists on the flash medium and both sfs and 2fs files are in it.

When pmedia=atahd psubdir=pupsave, OTOH, all pupsave directories on all partitions are shown with their 2fs files, and 528 is found and loaded successfully.

[otropogo]

Since my testbed seems to behave differently from that of the only other tester reporting, I'll try to limit myself to simply reporting my results, and let the readers draw their own conclusions.

All the tests below were conducted with the standard (129MB) and the(353MB) lupupluslibre Lupu_528.sfs.present. In every test, lupu was booted from a USBflash installation to an SD card inserted in an external card reader on a USB2.0 port.

The test PC has two SATA hard drives, with one partition on each drive, sda1 and sdb1. In this instance, the flash card was also partitioned (unlike the card in the previously reported tests) as sdd1. The last change made no apparent difference to response to the boot commands

The USBflash card had lupu standard and a couple of 2fs files in a folder named pupsave. And the final line of the syslinux.cfg file was edited for the test to read

Code: Select all

pmedia=atahd

. The card was not edited throughout the series of tests, and I put it in write protected. But I forgot unreliability of the locking tab, and didn't check its write protect status. So it is possible that automatic processes were able to write to the card.

Sda1 contained one folder with the lupu standard sfs, and another with lupupluslibre version, and sdb1 contained one folder with lupu standard. Each folder had an initrd.gz file and was capable of loading lupu into RAM.

In the course of the testing, commands were entered at the boot command line and/or the names of the save folders modified, to assess the effects.

It was assumed at the outset that the 528 boot loader would look for and use sfs or 2fs files in priority order of drives (ie. sda1before sdb1) and folders within drives in alphabetical order (ie.sda1\ before sda1\a\ before sda1\b\), but the tests cast doubt on all of those assumptions.

Unexpected results are underlined.

Test 1. lupu std. in sda1/pupsav lupu+libre in sds1/pupsavr lupu std. in sdb1/pupsaveC
booted with

Code: Select all

pmedia=atahd

alone

result: 2fs files in sdb1/pupsaveC offered for loading, on loading, sdb1 automounted, lupu standard loaded

Test 2. repeat of Test 1. no change

Test 3. entered

Code: Select all

puppy pdev1=sda1

at boot command line

result: sda1/pupsav offered for loading, lupu standard loaded, sda1 automounted

Test 4. entered

Code: Select all

puppy psubdir=pupsavr

at command line

result: sda1/pupsaver offered for loading, lupu+libre loaded

Test 5. renamed sda1/pupsavr to sda1/pupsave, booted with

Code: Select all

pmedia=atahd

alone

result: sdb1/pupsaveC offered for boot, lupu std loaded from sdb1

Test 6. repeat of Test 5. Same result\

Test 7. entered

Code: Select all

puppy  pdev1=sda1

at boot command line

result: sda1/pupsav offered for loading, lupu std loaded

Test 8. renamed sda1/pupsave > sda1/pusave528L, sda1/pupsav >sda1/528s and booted with

Code: Select all

pmedia=atahd 

only

result: sda1/pupsave528s offered for loading, lupu std loaded

Test 9. reboot with command line entry

Code: Select all

puppy pdev1=pupsave528L

result: sda1/pupsave528L offered for loading, lupu+libre loaded

Test 10. reboot with only

Code: Select all

 pmedia=atahd

result: sda1/pupsave528s offered for loading, lupu std. loaded

NB: this was tried with the two folders renamed variously, always placing the folder with the standard sfs in descending boot order from the lupu+libre one, but the folder with the standard sfs was always selected by the bootloader.

Test 11. renamed the two sda1 folders to sda1/528_1(2) and rebooted with

Code: Select all

pmedia=atahd

alone

result: sdb1/pupsaveC offered for loading, lupu std loaded, sdb1 automounted.

Test 12 rebooted with command line entry

Code: Select all

puppy pdev1=sda1

result: sda1/528_2 offered for loading, lupu std loaded

Test 13. renamed sda1/528_1 > sda1/pupsave, sda1/528_2 . sda/pupsave_2, sdb1/pupsaveC > sdb1/pupsave; copied lupu+libre sfs, 2fs, and initrd.gz to root directory of sda1 and rebooted with

Code: Select all

pmedia=atahd

only

result: sdb1/pupsave offered for loading, lupu std loaded, both sda1 and sdb1automounted, sda1 read-only as /intitrd/mnt/dev_ro2, sdb1 as /mnt/home

Test 14. renamed sdb1/pupsave > sdb1/pupsaveC; deleted initrd.gz and lupu+libre sfs file from sda1\; copied lupu standard sfs and intird.gz from sdd1 to sda1\; booted with only pmedia=atahd

result: sdb1/pupsaveC offered for loading, loaded lupu std from sdb1

Test 15. booted with commandline entry

Code: Select all

puppy pdev1=sda1

result: sda1/pupsave_b offered for loading, loaded lupu std from sda1

Test 16. rebooted with

Code: Select all

pmedia=atahd

alone

result: sda1/pupsave_b offered for loading, loaded lupu std from sda1

Test 17. booted with commandline entry

Code: Select all

puppy psubdir=pupsave

result: both sdd1/pupsave and sda1/pupsave offered for loading, chose 2fs from sda1, loaded lupu+libre from sda1

Test 18. booted with commandline entry puppy

Code: Select all

psubdir=pupsave

again, but chose 2fs file from sdd1, sdd1 automounted as /mnt/home, sda1 automounted as
initrd/mnt/dev_ro_2, both writeable. Not sure which sfs version is loaded, as libre office suite is only shown as a download link in the menu, but when a libreoffice write file is left clicked, it opens in libreoffice writer...

It seems to me that these results differ significantly from the behaviour described in bigpup's link. The 528 loader seems to have a distinct preference for booting the standard sfs, an aversion to sfs in the root directory, and a preference for folders named "pup..." or "save".

There also seems to be some sort of dynamic in which having been forced once to boot in proper drive sequence by

Code: Select all

puppy pdev1=sda1

, it will then do it on reboot without the command.

I trust these notes are detailed enough that anyone with a usb-enabled PC and two hard drives will be able to replicate my tests. My notes got a little messy toward the end, so it is possible that some errors have crept in. I'd be happy to retest any results that cannot be replicated by others on a similarly configured machine.

[ICPUG]

Thanks for the info Otropogo and the kind comments on my previous post bigpup.

I must emphasise that the post I wrote before was written after I had flowcharted the init in series 3 pups. Hopefully, all the comments about search not being faster are negated by the init in use today. I think that was one of the reasons Barry undertook to rewrite the search routines.

I can confirm Otropogo's comment that things may well be more complicated now - the init script certainly is - 8 A4 pages of script for finding files and 12 more for loading them!

One significant difference betwen my system and Otropogo's is that I don't use usb installs. Maybe there is something in the current init scripts that is not quite right when usb is used.

I have not read Otropogo's detailed notes fully, yet, but I will make a couple of comments:

It would help if I knew of a quick, simple, and certain way of determining which sfs is loaded (the two I'm using exclusively ant 582_005(standard -129MB) and lupupluslibre (353MB).

When I was testing I simply fired up the Word Processor from the desktop icon. If I got Abiword it was standard Lupu. If I got LibreOffice Write it was Lupupluslibre. Also you can have a look at the file:
/etc/rc.d/PUPSTATE

The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.

The only thing that has to be written to is the save file. It makes sense to me that the partition with the save file has to writeable. If the sfs is on a different partition then it seems reasonable from a security viewpoint that this is not writeable.

As you can see from my comment above I have printed the init from Standard Lupu and made a start at deciphering it (with the side effect of finding some debugging boot codes I never knew/forgot about!). if I ever decipher the search scripts we can go through Otropogo's test notes to confirm them. I need to complete the decyphering in order to update that previous post of mine ...

[otropogo]

..

One significant difference betwen my system and Otropogo's is that I don't use usb installs. Maybe there is something in the current init scripts that is not quite right when usb is used.

...

I have not read Otropogo's detailed notes fully, yet, but I will make a couple of comments:


When I was testing I simply fired up the Word Processor from the desktop icon. If I got Abiword it was standard Lupu. If I got LibreOffice Write it was Lupupluslibre. Also you can have a look at the file:
/etc/rc.d/PUPSTATE

Thanks. My method of simply looking at the start menu for libre office wasn't effective, as when booting with the 2fs file located on the flash card sdd1/pupsave, only the entry "download libreoffice" appeared. But when I opened an rtf file, it used libreoffice writer.

/etc.rc.d/PUPSTATE confirmed that the sfs file in sda1/pupsave was in use.

The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.

I have since discovered that the automounted /intrd/mnt/dev_ro2 file is not always write protected, perhaps even not usually. Unfortunately, my notes don't shed any light on the peculiarities, if any, of the two instances when it was write protected.

The only thing that has to be written to is the save file. It makes sense to me that the partition with the save file has to writeable. If the sfs is on a different partition then it seems reasonable from a security viewpoint that this is not writeable..

I don't think it's sensible to write protect an entire partition just because the 2fs file is on it. In fact, it seems to me that the system will not let one edit the copy of the sfs file in memory in any case.

OTOH, this issue prompted me to try as an experiment booting using the 2fs file on the USB flash card with the write protect tab set to lock. Puppy loaded and shut down unremarkably, EXCEPT that the usual message line saying that the 2fs file was already saved didn't appear.

I would suggest that some modidication of the shut-down process would be very helpful for those using usbflash to boot - namely, that the writability of the medium should be checked, and if locked, an option should be given to the user to unlock it and save the 2fs before shutting down.

Conversely, it would be a handy option, especially for testing purposes, to be able to set the system to ask before saving the 2fs file (since not all flash media have physical write protection tabs). This is considerably more convenient than waiting for the system to back up a 1GB+ 2fs file (especially via usb2), and makes recovery from an installation disaster or running out of personal storage much easier.

Remember also that when booting from USBflash, the loader relies on the syslinux.cfg file on the flash medium, regardless of the location of the 2fs file used. If the flash card were autolocked by a given configuration, it would require booting via another means to change the boot parameters.

I have just run a few more tests and checked the results with PUPSTATE:

Test 1 with

Code: Select all

pmedia=atahd psubdir=pupsave

result: contents of sda1/pupsave and sdd1/pupsave offered for loading, loaded from sdd1

sdd1 automounted as /mnt/home
sda1 automounted as /initrd/mnt/dev_ro2

both writable, lupu+libre loaded from sda1/pupsave

Test 2. removed

Code: Select all

psubdir=pupsave

from syslinux.cfg and rebooted.

Result: only the content of sdb1/pupsaveC was presented for loading, and 528 standard was loaded into RAM from that directory

Test 3. rebooted and added the argument

Code: Select all

pdev1=sda1

to

Code: Select all

pmedia=atahd

result: only the content of sda1/pupsave_b was offered for loading, and 528 standard was loaded from sda1/pupsave_b

So, why does the loader choose to use sda1/pupsave over sb1/pupsave when the boot command is

Code: Select all

pmedia=atahd psubdir=pupsave

, but

chooses to use sb1/pupsave over both sda1/pupsave and sda1/pupsave_b, when the psubdir argument is left out?

[sheldonisaac]

The newest Pmusic requires gtkdialog 0.8.3

Where is a version of gtkdialog 0.8.3 which works under Lucid puppy? My primary Puppy is Lucid 5.2.8-005

Thanks,
Sheldon

[don570]

Where is a version of gtkdialog 0.8.3

I put together a package for Barrry' Kauler's Precise distro.
It should work for Lucid.

Try it and report back...


http://www.murga-linux.com/puppy/viewto ... 831#677831

_______________________________________

[sheldonisaac]

Where is a version of gtkdialog 0.8.3

I put together a package for Barrry' Kauler's Precise distro.
It should work for Lucid.

Try it and report back...

http://www.murga-linux.com/puppy/viewto ... 831#677831

Thank you very much, don570; it does indeed work.
I copied the gtkdialog4 file:

~> which gtkdialog
/usr/bin/gtkdialog
~>

~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~>

[RSH]

Hi.

Here is my output on gtkdialog:

GtkDialog, which is a link to gtkdialog3

Code: Select all

sh-4.1# gtkdialog -v
gtkdialog version 0.7.21 (C) 2004, 2005, 2006, 2007 by Laszlo Pere

GtkDialog4

Code: Select all

sh-4.1# gtkdialog4 -v
gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor

GtkDialog5

Code: Select all

sh-4.1# gtkdialog5 -v
gtkdialog version 0.8.2 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor

I have downloaded the above linked .pet and found a binary named gtkdialog4.

So, how did you get this output from a gtkdialog4 binary?

Code: Select all

~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~>

Is gtkdialog4 the right name for this binary?

Please explain...

Thanks

RSH

[sheldonisaac]

(portions snipped)

I have downloaded the above linked .pet and
found a binary named gtkdialog4.

So, how did you get this output from a gtkdialog4 binary?

Code: Select all

~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~>

Is gtkdialog4 the right name for this binary?

RSH, please excuse any unclearness.
Clicking the pet resulted in the binary gtkdialog4 being placed into
/usr/sbin
I copied that file into /usr/bin and renamed it to gtkdialog

It was one approach to dealing with the way gtkdialog is used by Pmusic.

Thanks,
Sheldon