| Author |
Message |
| otropogo |
 Posted: Tue 29 Jan 2013, 03:09 Post subject:
Re: How does puppy's flash boot loader pick the sfs file?
Subject description: pdev1 and psubdir don't determine which lupu_528.sfs file loaded, what does? |
|
| greengeek wrote: | | otropogo wrote: | 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.
|
I just saw an interesting comment from ETP regarding sfs and savefile discovery here:
http://www.murga-linux.com/puppy/viewtopic.php?t=24047&start=278
Possibly all puppies may benefit from further work/understanding in this area. Time consuming and tricky to cover all contingencies though. |
Thanks for the link. Have responded to ETP's post there.
|
|
 |
| greengeek |
Posted: Thu 24 Jan 2013, 14:33 Post subject:
Re: How does puppy's flash boot loader pick the sfs file?
Subject description: pdev1 and psubdir don't determine which lupu_528.sfs file loaded, what does? |
|
| otropogo wrote: | 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.
|
I just saw an interesting comment from ETP regarding sfs and savefile discovery here:
http://www.murga-linux.com/puppy/viewtopic.php?t=24047&start=278
Possibly all puppies may benefit from further work/understanding in this area. Time consuming and tricky to cover all contingencies though.
|
|
|
| sheldonisaac |
Posted: Fri 18 Jan 2013, 09:26 Post subject:
Subject description: re gtkdialog |
|
(portions snipped)
| pemasu wrote: | I follow the logic explained by 01micko ..
.. to use one improved gtkdialog binary only...and the others are symlinks.
|
Thanks to all for your posts on this issue.
I had installed the one that don570 made
http://www.murga-linux.com/puppy/viewtopic.php?p=677831#677831
I did the below, and Pmusic (which looks for gtkdialog) starts normally.
| Code: | /usr/sbin> ln -s gtkdialog4 gtkdialog
/usr/sbin> which gtkdialog
/usr/sbin/gtkdialog |
|
|
|
| jpeps |
| Posted: Fri 18 Jan 2013, 02:53 Post subject:
|
|
| pemasu wrote: |
But 01micko posted this idea, to use one improved gtkdialog binary only...and the others are symlinks. If there is incompatibility the idea was that those gtkdialog apps should be updated by the developer.
I have gone with this logic since then...as 01micko |
exactly...I wish everyone was on board with this approach...but......
BTW/ update JWM-653, since it now works with java...thanks to 01micko kicking butt....
I don't know if you got around to reposting a working JRE in the SFS directory. I posted one the other board, but there's probably some new versions on the way.
|
|
|
| pemasu |
| Posted: Fri 18 Jan 2013, 02:18 Post subject:
|
|
I follow the logic explained by 01micko at some time when the debate about gtkdialog naming was hot. Due to incompatilities of improved version at that time. I wont go to the details. They can be found from the gtkdialog thread.
But 01micko posted this idea, to use one improved gtkdialog binary only...and the others are symlinks. If there is incompatibility the idea was that those gtkdialog apps should be updated by the developer.
I have gone with this logic since then...as 01micko.
So....there is diversity...Barry Kauler do the naming his way....some others other way. But there has not been much problems with it,
Also....01micko and I use the latest gtkdialog version at the time. Barry updates woof slower.
|
|
|
| don570 |
| Posted: Thu 17 Jan 2013, 21:21 Post subject:
|
|
Shouldn't you guys stick to the same naming convention that
Barry Kauler uses. He hasn't advanced to gtkdialog5.
I try to stick to his methods as close as possible.
Barry likes to make gtkdialog4 the application and gtkdialog the link.
This is an image of Exprimo which does it differently.
__________________________________________
|
|
|
| RSH |
| Posted: Thu 17 Jan 2013, 01:15 Post subject:
|
|
I think you did not really understand my question the right way.
As you can see in my gtkdialog output, the gtkdialog4 binary version is 0.8.0
You posted a gtkdialog version 0.8.4 - also from a gtkdialog4 binary.
I want to know:
- is this file wrong renamed to gtkdialog4 after compiling?
- or is every new gtkdialog binary 0.8.0 and above renamed after compiling to gtkdialog4 - from now on
Thanks
RSH
Edit:
Or will this confusing all users/developers of Puppy Linux in the future and therefor adding a big minus to the related big list of minuses on installing and using applications? 
|
|
|
| sheldonisaac |
Posted: Wed 16 Jan 2013, 23:25 Post subject:
Subject description: re gtkdialog |
|
(portions snipped) | 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?
| Code: | ~> 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
|
|
|
| RSH |
| Posted: Wed 16 Jan 2013, 23:08 Post subject:
|
|
Hi.
Here is my output on gtkdialog:
GtkDialog, which is a link to gtkdialog3
| Code: | sh-4.1# gtkdialog -v
gtkdialog version 0.7.21 (C) 2004, 2005, 2006, 2007 by Laszlo Pere
|
GtkDialog4
| Code: | sh-4.1# gtkdialog4 -v
gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor
|
GtkDialog5
| Code: | 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: | ~> 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 |
| Posted: Wed 16 Jan 2013, 22:48 Post subject:
gtkdialog 0.8.3 etc |
|
Thank you very much, don570; it does indeed work.
I copied the gtkdialog4 file:
| Quote: | ~> which gtkdialog
/usr/bin/gtkdialog
~> |
| Quote: | ~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~> |
|
|
|
| don570 |
|
|
| sheldonisaac |
| Posted: Wed 16 Jan 2013, 16:33 Post subject:
gtkdialog 0.8.3 |
|
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
|
|
|
| otropogo |
| Posted: Tue 15 Jan 2013, 16:40 Post subject:
|
|
| 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
|
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.
| Quote: | | 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.
| Quote: |
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: | | 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 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 to
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: | | 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?
|
|
|
| ICPUG |
| Posted: Mon 14 Jan 2013, 08:56 Post subject:
|
|
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:
| Quote: | | 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
| Quote: | | 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 |
| Posted: Sun 13 Jan 2013, 04:14 Post subject:
|
|
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 . 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 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
at boot command line
result: sda1/pupsav offered for loading, lupu standard loaded, sda1 automounted
Test 4. entered | Code: | | 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 alone
result: sdb1/pupsaveC offered for boot, lupu std loaded from sdb1
Test 6. repeat of Test 5. Same result\
Test 7. entered
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 only
result: sda1/pupsave528s offered for loading, lupu std loaded
Test 9. reboot with command line entry | Code: | | puppy pdev1=pupsave528L |
result: sda1/pupsave528L offered for loading, lupu+libre loaded
Test 10. reboot with only
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 alone
result: sdb1/pupsaveC offered for loading, lupu std loaded, sdb1 automounted.
Test 12 rebooted with command line entry
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 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
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 16. rebooted with alone
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 17. booted with commandline entry | Code: | | 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 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 , 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.
|
|
|
|
Display posts from previous: Sort by:
|