[Leaf-devel] test sorry (support-request 505419) please ignore
You didn't. Please excuse this test mail, but I had problems with mail delivery with this list and opended the mentioned support request on sourceforge. They reported it should be solved. To check and to give feedback, I'll send this mail. Might be annoying for you, but will help sourceforge support. regards kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Useful comments from Dave
On 2/5/02 at 4:31 PM, Serge Caron <[EMAIL PROTECTED]> wrote: > In the concept of an enclosure, I abstract the binary > format of the initial RAM disk. The same enclosure is > offered in tar.gz and initrd.gz formats, with references > to 2.2 and 2.4 kernels respectively. There is nothing > preventing cross usage of these files if the user builds > the appropriate support in his Linux kernel, a fact that > extends beyond the scope of this project as I understand > it. Therefore, I believe this is a sane decision and I > will stick by it. The initial RAMdisk configuration is either in *.gz or in *.tar.gz formats. A standard Linux kernel without LRP patches cannot handle a *.tar.gz format file for an initial RAM disk; this precludes the abstraction you were talking of. Also, the use of 2.4 precludes the use of ipchains without special configuration; there are other 2.4 requirements that don't exist in 2.2. One can't take this initial RAM disk and swap back and forth easily - unless you are referring to its contents only - but even then, one has to account for Linux 2.2 vs. Linux 2.4... ipchains vs iptables... > Mankind is full of talented people and marketers are some > of them. The less I say about the state of current marketing the better... > Actually, I am explicitly proposing that the contents of > the initial RAM disk be enumerated in an unambiguous way > and that the project default store (usually root) be > separated from the RAM disk. "Project default store"? Eh? > I am also explictly proposing > that the person designing an enclosure be absolutely free > to put anything they want in their enclosure and do > whatever they want before /sbin/init receives control. That's what happens now - and with Oxygen, even more so. Want to use fcron instead of cron? You can. Want to not run cron at all? Can do that too. Want to run with lrpkg instead of apkg? You can. Want to use rcf instead of seawall? You can. What makes up the bulk of scripting in most LRP systems is /linuxrc - which amounts to everything that happens before init is run. > Potential users will decide what is useful and not, just > as consumers decide which product lives and which dies. Consumers don't always decide in favor of the clearly technically superior; look at Beta video tape. Another example: most engineers would tell you that the IBM PC architecture should have been gutted and replaced completely a decade ago. > Finally, I am explicitly proposing that the person > designing yet another way to stick a RAM disk in a kernel ...you don't stick RAM disks into the kernel... > be responsible for providing the conversion code from an > existing scheme to their new one. "Conversion code"? "Existing scheme"? > It seems to me that I am > proposing a lot of freedom for people to try different > ideas without having to redo the work all of the time. Redo what work? > The word distribution keeps coming back with slightly > different meanings, or so I understand. To me, a distribution is: * A collection of programs combined with an OS kernel combined in such a way as to make the combination useful. This includes FreeBSD, OpenBSD, Dachstein, Oxygen, Windows NT, HP-UX... > Following my post > regarding the conversion of an existing disk, here are the > forensics on Charles's Dachstein 1.0.2 floppy: To me, forensics is the science of studying what has happened after a crime has been committed by studying the evidence which remains. > 1) if the instructions were followed exactly, the new > root.lrp would contain ipchains 1.3.10, the bridge > configuration utility (brcfg), a symlink to > /etc/init.d/network (/sbin/net) and the seed for the > /random number generator > (/var/lib/random-seed). root.lrp would also contain > /lib/libss.so.2 a library used for system specific ext2 > filesystem functions that is not referenced by any of the > 43 packages on Charles CD; /usr/sbin/ipfwd, an obsolete > (?) utility for routing incoming pptp traffic, > /usr/sbin/traceroute which has a (lame) busybox > equivalent, and /usr/sbin/icmpinfo. That's it! I know that you're using Dachstein, but in Oxygen: * ipchains is a package (ipchains.lrp) * bridge utilities are packaged (brctl.lrp) * libss - probably packaged in ext2fs.lrp * busybox is now at 0.62.0 - make sure it's current * There is a tracert.lrp which is quite current. > 2) I decided to modify my own instructions to add the > ipchains package separately and to add /sbin/brcfg, > /sbin/net and /var/lib/random-seed to the etc package /sbin/net and /var/lib/random-seed are not in /etc > syslinux.cfg was modified to read LRP=ipchains,etc,... Automatic loading of packages was proposed in 1995 why doesn't Dachstein do this? > However the real question is this: since everything that > is Dachstein_1.0.2_floppy_version can be reduced to this > single 40Kb file, what is a LEAF distribution and what is > a LEAF appliance? To me, "LEAF appliance" is a marketing term: trans
[Leaf-devel] Ports
I've been working on setting up ports a little bit. I've finally gotten to installing OpenBSD (this time on intel instead of mac68k) and it uses ports like the other BSDs. Ports are really nice - basically you can download the entire ports tree, or just one. Then, you change directory into /usr/ports/net/wget (for example) and do a make - then a make install. The system automatically gets the original file, patches it and configures it, and builds it for your system. In the case of OpenBSD, it even creates the package and installs THAT when you do a make install. Considering what this could mean for LEAF, consider this: a NFS-enabled LEAF system, with / from a full system mounted somewhere. Changing directories to /usr/src/ports/net/wget, do a make (pulls the file in, patches, builds, compiles) - and a make install. After the make install is done, the LEAF system now has /tmp/wget.lrp and an installed wget binary. Another possibility: using that full Linux system again, doing the same thing - except this time a make install uses scp and a private key to copy the file over to the LEAF system, then uses ssh and a private key to install the package on the LEAF system. Thoughts? -- 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
[Leaf-devel] Date/Time
I've been looking into the date and time set in an Oxygen system, and comparing to a Mandrake system. The confusion comes this way: * Hardware clock: set value * Hardware clock (hwclock): value displayed * System clock: set value * System clock: value displayed ...and these interact with: * /etc/localtime * TZ It would also appear that the man page for asctime(2) is wrong, and that the variable timezone is NOT set as it says it is. It would also appear that: * hwclock does not shift the time read according to timezone; it just "stamps" the output with the given timezone * hwclock remembers how the RTC was set - thus, hwclock --show may report UTC, or it may report localtime... I'm also getting lost in functions: gettimeofday() tzset() time() localtime() ...which ONE of these gets the timezone right? Then there's header files: #include #include #include *ALL* of these conflict And it even appears that busybox date may be reporting the wrong time... sigh... I wrote my own time display program (tz) just for testing purposes - it calls all of the above functions. I'll try to put it up on in the development area with source code. My hypothesis are: * hwclock works differently than I thought * there may be actual bugs in busybox date * I may be mixing up standard C functions, Linux kernel functions, and old obsolete Linux kernel functions Someone give me an aspirin! -- 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
Re: [Leaf-devel] CF (write protect) + IDE adapter
At 2002-02-06 16:10 -0800, Jeff Newmiller wrote: >On Wed, 6 Feb 2002, Mike Noyes wrote: > > Lynn, > > This looks like a winner. It claims Linux compatibility too. > > > > http://www.ssti.com/ata_disk/admbrief.pdf > >This looks like the same hardware I bought from Advantech a year ago, >but my PCD-1240V doesn't have any WP# pin, or at least any access to it. Jeff, From what I've read, SiS added a non ATA compliant WP# signal to their ATA controller. The WP# jumper has three states outlined in the SSTI pdf below. I expect a lot of manufacturers will start using this new SiS ATA controller. http://www.ssti.com/products/pdf/519-58SM-LM8-192-01.000-DS.pdf -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
At 2002-02-06 16:10 -0800, Jeff Newmiller wrote: >On Wed, 6 Feb 2002, Mike Noyes wrote: > > > Lynn, > > This looks like a winner. It claims Linux compatibility too. > > > > http://www.ssti.com/ata_disk/admbrief.pdf > >This looks like the same hardware I bought from Advantech a year ago, >but my PCD-1240V doesn't have any WP# pin, or at least any access to it. Jeff, Exactly. It's almost identical to the PQI DiskOnModule (DOM) product too. I'm still trying to get pricing information. From what I can tell the product came out in Oct, so the channel hasn't filled yet. Apacer is making a ATA-Disk Module (ADM) too. http://www.apacer.com/product/flash/f_adc.htm -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Wed, 6 Feb 2002, Mike Noyes wrote: > At 2002-02-06 11:21 -0600, guitarlynn wrote: > >I did find another interesting link though, pricing is very > >nice too: > > > > http://www.ssti.com/news/news115.html > > Lynn, > This looks like a winner. It claims Linux compatibility too. > > http://www.ssti.com/ata_disk/admbrief.pdf This looks like the same hardware I bought from Advantech a year ago, but my PCD-1240V doesn't have any WP# pin, or at least any access to it. --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
Mike Noyes wrote: > > At 2002-02-06 11:21 -0600, guitarlynn wrote: > >I did find another interesting link though, pricing is very > >nice too: > > > > http://www.ssti.com/news/news115.html > > Lynn, > This looks like a winner. It claims Linux compatibility too. > > http://www.ssti.com/ata_disk/admbrief.pdf Thanks for posting that. It *does* look neat. Can't wait to hear about the prices they can quote you. Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
Jeff Newmiller wrote: > > On Wed, 6 Feb 2002, guitarlynn wrote: > > > On Wednesday 06 February 2002 02:04, Jeff Newmiller wrote: > > > On Sun, 3 Feb 2002, guitarlynn wrote: > > > > Yes, a product to keep me from cutting tiny toggle switches into > > > > those blasted IDE cables would be a godsend! [snippety snip] > The reason I bit was that in theory this should not work. > > The write signal is used to convey information to registers in the device > that select which data to retrieve from the IDE device. Thus, a write > protect signal on the device that acts between the registers and the > storage medium is required, and Mike Noyes' find really is significant. The whole question of write-protecting a hard drive is a moot point if you people would just use scsi equipment. The jumper for write-protect is clearly marked, and even the non-technical people could connect switch leads to the pins, given the correct mini-jumper connector. I suggest dusting off your old Mouser catalog and putting it to some good use :) I got so many of those old scsi drives that I'd love to boot from, then power down, because I don't need the indoor chainsaw :) Personally, I prefer secure network loading of packages off my fileserver. And why don't you people use cdrw? Rewriters are like $50 for a bottom of the line, no-name, ide burner. Who's compiling cdrecord.lrp? Regards, Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
At 2002-02-06 11:21 -0600, guitarlynn wrote: >I did find another interesting link though, pricing is very >nice too: > > http://www.ssti.com/news/news115.html Lynn, This looks like a winner. It claims Linux compatibility too. http://www.ssti.com/ata_disk/admbrief.pdf I don't think I want to buy 100K units, so I'll have to ask one of their distributors for a retailer with pricing information. http://www.ssti.com/contact/nadist.html -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Wednesday 06 February 2002 10:56, Jeff Newmiller wrote: > On Wed, 6 Feb 2002, guitarlynn wrote: > > I'll give it a try, I need to do some soldering today anyway! > > You bit, I will too. > > The reason I bit was that in theory this should not work. Your right, my BIOS won't acknowledge the disk with the write pin (#23) 'disabled'. I guess if you wanted to go far enough, you could put a solid state time-delay relay on the power switch and set it to shut the write pin off after 'x' seconds ... not too practical though. I did find another interesting link though, pricing is very nice too: http://www.ssti.com/news/news115.html > The write signal is used to convey information to registers in the > device that select which data to retrieve from the IDE device. Thus, > a write protect signal on the device that acts between the registers > and the storage medium is required, and Mike Noyes' find really is > significant. I can attest that this affects the BIOS too ... no write, no drive! Thanks for the info ... I've been intending to atleast try it for quite some time in any case. I might go ahead and try the relay thing, but time would be rather expensive just to do it other than fun. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
At 2002-02-06 08:56 -0800, Jeff Newmiller wrote: >On Wed, 6 Feb 2002, guitarlynn wrote: > > > > It wouldn't be much trouble for me to try this if your really > > interested though. A less frustrating way of trying would be to > > wack a piece out of wire #23 and simply switch to another cable > > to write. > > > > I'll give it a try, I need to do some soldering today anyway! > > You bit, I will too. > >The reason I bit was that in theory this should not work. > >The write signal is used to convey information to registers in the >device that select which data to retrieve from the IDE device. Thus, >a write protect signal on the device that acts between the registers >and the storage medium is required, and Mike Noyes' find really is >significant. Jeff, I'm reading through the CF 1.4 specifications. http://www.compactflash.org/cfspc1_4.pdf I'm starting to wonder if true ide mode will work with PQI's write protect CF card. From what I can understand of the CF specifications, it will depend on how PQI implemented write protect. I was unable to locate any information on the PQI site that describes how they implemented write protect on their CF card. -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Wed, 6 Feb 2002, guitarlynn wrote: > On Wednesday 06 February 2002 02:04, Jeff Newmiller wrote: > > On Sun, 3 Feb 2002, guitarlynn wrote: > > > Yes, a product to keep me from cutting tiny toggle switches into > > > those blasted IDE cables would be a godsend! I can live with the CF > > > cards nicely though for the time being (if I can get one anyway)! > > > > My curiosity gets the better of me... just how many of these toggle > > switches have you installed, and how well have they worked? > > hehe, I haven't to be honest I was in a strange mood @that time. > I probably shouldn't have put it in there, sorry. > > I remember a long thread with some people trying this a couple of years > ago though, did anybody ever have any success??? If my memory > serves me right, there was a problem with disk-corruption errors if > the system tried to write to the HD. > > It wouldn't be much trouble for me to try this if your really > interested though. A less frustrating way of trying would be to > wack a piece out of wire #23 and simply switch to another cable > to write. > > I'll give it a try, I need to do some soldering today anyway! > You bit, I will too. The reason I bit was that in theory this should not work. The write signal is used to convey information to registers in the device that select which data to retrieve from the IDE device. Thus, a write protect signal on the device that acts between the registers and the storage medium is required, and Mike Noyes' find really is significant. --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Wednesday 06 February 2002 02:04, Jeff Newmiller wrote: > On Sun, 3 Feb 2002, guitarlynn wrote: > > Yes, a product to keep me from cutting tiny toggle switches into > > those blasted IDE cables would be a godsend! I can live with the CF > > cards nicely though for the time being (if I can get one anyway)! > > My curiosity gets the better of me... just how many of these toggle > switches have you installed, and how well have they worked? hehe, I haven't to be honest I was in a strange mood @that time. I probably shouldn't have put it in there, sorry. I remember a long thread with some people trying this a couple of years ago though, did anybody ever have any success??? If my memory serves me right, there was a problem with disk-corruption errors if the system tried to write to the HD. It wouldn't be much trouble for me to try this if your really interested though. A less frustrating way of trying would be to wack a piece out of wire #23 and simply switch to another cable to write. I'll give it a try, I need to do some soldering today anyway! You bit, I will too. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] bering beta3 and typo in interfaces file
Hello Jacques, I just found out why my third network card didn't get set. It's a typo in the examples of the interfaces file. For Step 3 and step 4 the word adress is written with one d while it should be 2. # Step 3 (optionnal): configure DMZ # Default: eth2 / fixed IP = 192.168.1.100 #auto eth2 #iface eth2 inet static # adress 192.168.1.100 # network 192.168.1.0 # netmask 255.255.255.0 # broadcast 192.168.1.255 # Step 4 (optionnal): configure bridge #auto br0 #iface br0 inet static # adress 192.168.1.254 # network 192.168.1.0 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.1 # bridge_ports all ICQ# 37047796 [EMAIL PROTECTED] (Work) [EMAIL PROTECTED] (Home)
