On 2/19/02 at 2:01 PM, Serge Caron <[EMAIL PROTECTED]> wrote: > This does not require any adherence to any foreign code, > programs or the like. In fact I can implement the entire > concept in Oxygen 1.9 by editing two DATA files. The first > one is root.list which contains the single entry ../ and > which I replace with the unambiguous enumeration of the > contents of root.gz (see the appendix below). The second > one is any other file I choose as my default store: my > personnal preference is home.lrp and I edit home.list to > contain the single entry ./.
This paragraph explains a *LOT* more than those terms you were using - I never was able to understand it, until you said what you did... With the new use of root.gz, this is almost what is happening - since root.gz is a compressed filesystem, the contents of root.gz will not change under normal use - or even erroneous use - as happens sometimes when using a root.list of "./" ... Adding a NEW package with the entry "./" in the new Oxygen environment (which uses root.gz) would be interesting. It basically means you can extend the base without having to create packages or other things. But then, would this capability be useful? > I can use Oxygen 1.9 right now, even without the backup > code that will be part of a later update. I obviously use > it in ways that its author has not envisioned. Further, > root.gz with the edited root.list satisfies in every way > the definition I have put forward for the concept of an > "enclosure". It's alright by me - I'm glad you used Oxygen, and it's nice to see people hacking away and trying things. Don't get discouraged. > Yet, given the fact that Oxygen 1.9+ may be compatible > with tar.gz and plain gz ramdisks, and given the fact that > the default store always retain the "standard" LRP format, > I can only see benefits from this idea for Oxygen. Because > it is an idea, it can be implemented by anybody in the > form of their choice and does not have to BE part of a > product offering. It can be documented and left at that. It should be documented; please do. Write up a text file (HOWTO) and explain things. One note: explain everything without using the words "default store" "unambiguous enumeration" "appliance" and others even once. These terms only serve to confuse. > In my case, I wanted to use the product NOW and I choose > to edit the two files. Further, when Oxygen 1.9+ becomes > available, I will drop my home.lrp on the new kit and > reboot with all my stuff intact. Instant upgrades are > always interesting :). I thought that's what config.lrp was for. If you use home.lrp as you've said, with "./" in home.list - isn't that "new" package going to be obliterated with a NEW home.lrp? > I believe that it is possible to have these specifications > without a baseline. When told that it was impossible to > abstract something that would be common to 2.2 and 2.4 > kernels, I actually produced a floppy on which people can > comment. That says something. I would have looked at it, but I've been very busy recently. Like you said: Life gets in the way :) > The fact is, much of the code that runs once init receives > control is the same in LRP, *stein, Bering and a number of > other derivatives. What really separates one LEAF distribution from another was what happens BEFORE init takes control - once control is given to init, then it's normally in the hands of /etc/rc > Once he has a grasp that everything else can be > enumerated, Michael can take the "root" appliance in the > above floppy and document its tacit specifications. Again, > this can be done from the "appliance" point of view > without being reflected in code. Huh? > v5.3.0 is my "standard" busybox ash experiment: I have > tested on many occasions the compatibility of busybox ash > to the Debian ash. In this case, I simply replaced the > busybox in the original enclosure with the busybox found > in Oxygen 1.9. busybox ash is not a drop in replacement > for ash, but it is getting better all the time. Actually, it *IS* a drop-in replacement - after all, busybox ash comes from debian ash directly. It's the same code, massaged a little more. > In this case, there is a "Segmentation fault" in the > following construct: > > # Modules required to complete the boot process > if [ -r $BOOTDIR/etc/modules ] ; then > # (Do not process comments and white space.) > (blind cat $BOOTDIR/etc/modules; echo) | > sed -e "s/#.*$//1" -e "/^[[:space:]]*$/d" | > while read module args; do > blind insmod $BOOTDIR/lib/modules/"$module".o $args > done > fi > > There is nothing wrong with this construct and it will run > perfectly if it is moved around in the script (the > segmentation faults happens in the pipe between sed and > the while clause). In the problem at hand, the file is > empty and the startup continues correctly. It is the ONLY > thing to report for the scripts in this enclosure when > using a 2.2 kernel. There is about a dozen "Segmentation > fault"s when using a 2.4 kernel, none of them fatal. What does "blind" do? Also, why not use this construct instead of sed? grep -v "^#" | grep -v "^ *$" Also don't forget to put a "\" at the end of the line to continue it - after the pipes... Also, if you're getting SegFaults, then I'd say that 2.4 isn't as interchangable as you thought. > I also need a replacement script for Charles mail script > which happens to use netcat, a utility that I do not want > in production equipment. Which smtp _output_only_ program > should I use and is there a script compatible to Charles's > syntax? Oxygen has ssmtp; why not use that? There is a number of other mail scripts (including the LRP original, and one by Mike Sensney) - but all of the scripts use that minature nc. > Appendix: contents of root.list in my Oxygen 1.9 setup: [...snip...] > var/lib/lrpkg/config.md5 This is likely to be extra and could probably be deleted, methinks... > var/lib/dialer/* > var/spool/* These are dangerous. This package (root) will then contain: var/lib/dialer/x var/lib/dialer/y var/spool/a var/spool/b ..but NOT.. var/spool var/lib/dialer If you try to extract var/lib/dialer/x without var/lib/dialer existing, it will error out. Change the lines to: var/spool var/lib/dialer ...and not only the files, but the directories themselves will be backed up. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
