Re:
Can you let us know where you found the conflicting documentation?
from 'PDF page #' 126, from file (that I re-downloaded today): http://leaf.sourceforge.net/doc/guide/leaf-guide-collection.pdf
Loading partial backup from floppy disk after booting cdrom
• Check syslinux.cfg on boot cd to see if PKGPATH includes partial backup device the default is
PKGPATH=/dev/cdrom:iso9660,/dev/fd0:msdos
• set the load order in lrpkg.cfg file on the floppy disk to load CDROM version of the package then the floppy version of the partial back of the package.
This ":f" ( the default ) will first load the cdrom version then the floppy updates it they exist.
Use ":R" to load the floppy version a full package and totally avoid the cdrom version of the package.
This section of the leaf-collection PDF is from the Bering User's Guide and this particular text is to be found (original source?) at (Ch. 11):
http://leaf.sourceforge.net/doc/guide/bubooting.html
=-=-=-=-
Please forgive my questioning the way you have done things Charles: but to me it seems a little 'inverted' to have the package-list 'read' from right-to-left (where the default=:f[orward]). For we English-readers 'forward' would normally connote left-to-right, non?
As you said (snipped for clarity):
( loaded last) is *FIRST* and ... (loaded first) is listed last.
However please have no doubt how thankful I am for this partial-backup functionality though! It's tres cool :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Re:
NOTE: Multiple package path entries is a little-used (especially prior to the deprication of the boot= entry in the kernel command line)
Is there some other way to effect the cd-rom + (partial-backup) floppy setup or is it that simply very few people go this route?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Thanks for LEAF, folks!
scott; canada
Charles Steinkuehler wrote:
freeman groups wrote:
I have a CD-ROM & f/d partial-backup setup happening. I was finding that no matter the changes made to a config file and saving it ('partially') to the floppy, when I rebooted I was met with the 'original' cd-rom-stored settings.
My relevant leaf.cfg lines: PKGPATH="/dev/cdrom:iso9660,/dev/fd0u1440:msdos"
<snip>
I was able to work around this by merely reversing the order of the media on the PKGPATH line so no major hardship, but my observation seem to be in conflict with the documented (expected) behaviour.
Might someone else be able to confirm that this is not happening to 'just me'? Alternatively I could do more testing if someone would like to tell me a preferred setup - I have 2 f/d, a h/d and a cd-rom on my test box so I can make an efficient (quick reboots) testbed.
Can you let us know where you found the conflicting documentation?
As the person who actually wrote the partial backup scripts in the first place, the problem sounds like it's with the documentation. In the PKGPATH list, the "most authoritative" source (ie: loaded last) is *FIRST* in the PKGPATH list, with the "least authoritative" (ie: loaded first and possibly overwritten) source is listed last, which matches the behavior you're seeing (ie: by default PKGPATH entries are read from right to left), and the documentation I provided:
http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/README.txt
<quoute> package[:searchorder][,package[:searchorder]]
package is an LRP package file (without the .lrp extension) searchorder controls the pakckage load behavior, and is one of: f forward search, load multiple packages *DEFAULT* F forward search, load first package found and stop r reverse search, load multiple packages R reverse search, load first package found and stop A "forward search" starts with the PKGPATH entries (read right to left) and looks at the boot= device last A "reverse search" starts with the boot= device, and goes through the PKGPATH entries (read left to right) <quote>
Note that the boot= device is no longer used, so the floppy disk needs to be added to the PKGPATH variable.
NOTE: Multiple package path entries is a little-used (especially prior to the deprication of the boot= entry in the kernel command line) and often mis-understood feature of the backup scripts, so I would not be suprised to find some incorrect documentation floating around.
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
