Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
Thanks,greengeek wrote: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...
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
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.boot error
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:
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.not enough free space
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.
otropogo,otropogo wrote: 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.
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.
Thanks for the further explanation.rerwin wrote:
...
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.
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.
- Attachments
-
- packageslst104_13.jpg
- list view screenshot of folder /root/.packages/ when running oldest 2fs file with lupupluslibre
- (88.81 KiB) Downloaded 541 times
More on quirky lupu boot command syntax
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:
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.setup/Puppy Universal Installer/USB Flash drive/sdc Generic USB CF reader, size 244.3 MiB/ install Puppy to sdc
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
Code: Select all
pmedia=atahd
It's still not clear exactly what,
Code: Select all
pmedia=atahd
Code: Select all
pdev1=sda1 psubdir=pupsave
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
Code: Select all
pmedia=atahd
Code: Select all
psubdir=puppy
2. my attempts to limit the presentation of 2fs files to those in sda1/pupsave with the entry
Code: Select all
psubdir=sda1/pupsave
Code: Select all
psubdir=/mnt/sda1/pupsave
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
4. However with configuration #3, I was able to modify the loading procedure by entering
Code: Select all
psubdir=pupsave
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
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.
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.ansivar wrote: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
However, I am still puzzled as to why the driver doesn't appear in the load list as the r8169 does.
How does puppy's flash boot loader pick the sfs file?
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
Adding
Code: Select all
psubdir=pupsave
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?
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.
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!
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.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
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.bigpup wrote:...
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
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.
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
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
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
result: sda1/pupsav offered for loading, lupu standard loaded, sda1 automounted
Test 4. entered
Code: Select all
puppy psubdir=pupsavr
result: sda1/pupsaver offered for loading, lupu+libre loaded
Test 5. renamed sda1/pupsavr to sda1/pupsave, booted with
Code: Select all
pmedia=atahd
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
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
result: sda1/pupsave528s offered for loading, lupu std loaded
Test 9. reboot with command line entry
Code: Select all
puppy pdev1=pupsave528L
Test 10. reboot with only
Code: Select all
pmedia=atahd
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
result: sdb1/pupsaveC offered for loading, lupu std loaded, sdb1 automounted.
Test 12 rebooted with command line entry
Code: Select all
puppy pdev1=sda1
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
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
Test 16. rebooted with
Code: Select all
pmedia=atahd
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 17. booted with commandline entry
Code: Select all
puppy psubdir=pupsave
Test 18. booted with commandline entry puppy
Code: Select all
psubdir=pupsave
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
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.
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:
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: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).
/etc/rc.d/PUPSTATE
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.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.
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 ...
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.ICPUG wrote:..
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
/etc.rc.d/PUPSTATE confirmed that the sfs file in sda1/pupsave was in use.
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 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 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.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..
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
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
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
Code: Select all
pmedia=atahd
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
chooses to use sb1/pupsave over both sda1/pupsave and sda1/pupsave_b, when the psubdir argument is left out?
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
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
I put together a package for Barrry' Kauler's Precise distro.Where is a version of gtkdialog 0.8.3
It should work for Lucid.
Try it and report back...
http://www.murga-linux.com/puppy/viewto ... 831#677831
_______________________________________
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
gtkdialog 0.8.3 etc
Thank you very much, don570; it does indeed work.don570 wrote:I put together a package for Barrry' Kauler's Precise distro.Where is a version of gtkdialog 0.8.3
It should work for Lucid.
Try it and report back...
http://www.murga-linux.com/puppy/viewto ... 831#677831
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.
~>
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
Code: Select all
sh-4.1# gtkdialog4 -v
gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor
Code: Select all
sh-4.1# gtkdialog5 -v
gtkdialog version 0.8.2 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
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.
~>
Please explain...
Thanks
RSH
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
RSH, please excuse any unclearness.RSH wrote: I have downloaded the above linked .pet and
found a binary named gtkdialog4.
So, how did you get this output from a gtkdialog4 binary?
Is gtkdialog4 the right name for this 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. ~>
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