I am very surprised that I cannot find qmail for Bering-uClibc.
What am I missing?
Can somebody, please, make a Bering-uClibc qmail.lrp ???
TIA
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely
* Charles Steinkuehler [EMAIL PROTECTED] [2004:05:10:11:17:09-0500] scribed:
snip /
IIRC, the IPSec scripts don't try to load any modules unless IPSec
support isn't already enabled. I simply load all required modules at
boot. If you really want, you can add new modules to /etc/modules at
I have noticed in recent months that Charles is migrating from DCD to
Bering, and that migration has entailed some sleight-of-hand over
straight Bering.
Charles, have you published your DCD-Bering ``distribution''?
What do you think?
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to
* Charles Steinkuehler [EMAIL PROTECTED] [2004:04:29:11:36:11-0500] scribed:
Michael D Schleif wrote:
I have noticed in recent months that Charles is migrating from DCD to
Bering, and that migration has entailed some sleight-of-hand over
straight Bering.
Charles, have you published your DCD
* Charles Steinkuehler [EMAIL PROTECTED] [2004:03:13:16:47:02-0600] scribed:
snip /
I propose making log_mnt a new leaf.cfg variable (could also come in via
the kernel command line). Rather than the format you used, however, I
would like to use the existing PKGPATH/LEAFCFG format
* Charles Steinkuehler [EMAIL PROTECTED] [2004:03:13:21:51:06-0600] scribed:
Michael D Schleif wrote:
`not be hard-coded' is _exactly_ what I am referring to.
I don't know how you are doing this; but, I can see value in having some
arbitrary director(y|ies) persist across reboots -- in some
Also sprach Erich Titl (Tue 22 Jul 02003 at 07:29:23PM +0200):
Hi everybody
I am just about to port Bering to a new embedded piece of hardware, except
for a few keyboard errors quite successfully. I believe this platform could
be very interesting for anyone contemplating a distribution of
Also sprach Mike Noyes (Tue 04 Mar 02003 at 07:46:00AM -0800):
On Tue, 2003-02-25 at 07:58, Mike Noyes wrote:
This breakdown of the url may make things easier to understand. Please
let me know if further explanation is necessary.
Standard prefix:
a
Also sprach David Douthitt (Thu 20 Feb 02003 at 04:25:07PM -0600):
On Wed, 19 Feb 2003 19:25:28 -0600
Michael D. Schleif [EMAIL PROTECTED] wrote:
Are you booting off of this? How? Any special preparation to
boot off of USB?
You could say I am. It's a three-media startup: install
Certainly, after all this time some of you have been using this stuff
with LEAF, there must be a HOWTO?
Anyway, I am about to embark down that road and I'm hoping that we can
start a thread to consolidate the DO's and DONT's for using this type of
media with LEAF.
Some of the first questions
Mike Noyes wrote:
On Sun, 2003-02-09 at 09:45, Mike Noyes wrote:
Everyone,
It has come to my attention that our leaf-user list volume is
discouraging some/many users from using it. We have a variety of options
to address this issue.
a) Keep things as they are.
b) NNTP
Mike Noyes wrote:
On Sun, 2003-02-09 at 10:16, Lynn Avants wrote:
On Sunday 09 February 2003 11:45 am, Mike Noyes wrote:
b) NNTP support (news.gmane.org and/or nntp.sourceforge.net)
I like NNTP, but it doesn't necessarily address the volume problem at all.
Lynn,
Correct. It
Vladimir I. wrote:
Mike Noyes wrote about Re: Light a candle, curse the glare (was: Re: [leaf-devel]
ML volume):
Ray,
One of our project members sent me a message off-list expressing a
concern over leaf-user list volume. I have no idea how many of our users
No need to keep it
Ray Olszewski wrote:
At 11:03 AM 2/9/03 -0800, Mike Noyes wrote:
On Sun, 2003-02-09 at 10:39, Ray Olszewski wrote:
It would be easier to develop an (informed) opinion on this if we (or at
least I) knew a bit more about what causes you to bring it up as a
concern.
There is a big
Lynn Avants wrote:
snip /
I see either this concept can be embraced or ridiculed, but if you don't
see it as necessary in the future you plainly haven't followed the desires
on list for the last year or two. Packetfilter, apkg (Oxygen), LINCE,
Mosquito, and individual systems are proof
Another reason to use djbdns . . .
Greg Morgan wrote:
FYI,
Greg Morgan
Red Hat Network Alert wrote:
Security Advisory - RHSA-2002:197-09
--
Summary:
Updated glibc packages fix vulnerabilities in
Eric B Kiser wrote:
You must mean inside that really obvious directory named /lib. Urgh, it is
now probably a moot point to mention that I am a newbie. Your patience is
appreciated.
Here is where I am now. I execute the command #zebra -d to start the zebra
process running as a daemon
Eric B Kiser wrote:
I am using David's zebra.lrp package and trying to get it to run on
Bering_1.0-rc3. I wanted to check out what he did before I got started on
mine. I will, however, be using UML_slink to do my compiling.
You bring up an interesting question regarding ssh having the
Jacques Nilo wrote:
Hi Everyone
I have been asking myself for quite some time why there was so much
redundancy in the content of /var/log files in a LEAF distro.
A typical example is when your ports are being scanned, that is when your
iptables messages starts increasing. You will find
Manfred Schuler wrote:
this is another topic.
Your link reports vulnerabilities in openssl.
This information is about a trojan in the openssh source tarball.
The trojan opens a backdoor when compiling ssh.
It is no security issue for leaf, only a hint for those people compiling ssh.
Mike Noyes wrote:
Anyone,
Will removing the following lines from enforce_naming leave the perl
script functional?
Yes, absolutely yes; provided that either all of the lines are
completely _removed_ or completely commented out.
# Verify that all files are lowercase, except Makefiles
Mike Noyes wrote:
On Wed, 2002-07-17 at 08:58, Michael D. Schleif wrote:
Mike Noyes wrote:
Anyone,
Will removing the following lines from enforce_naming leave the perl
script functional?
Yes, absolutely yes; provided that either all of the lines are
completely _removed_
Mike Noyes wrote:
On Wed, 2002-07-17 at 12:23, David Douthitt wrote:
I've been looking at some things, and updated
syslinux and e3 (in the CVS tree) to their apparent
current versions.
I've noticed that CVS can be a major pain, especially with
renaming files, or deleting or moving
Jeff Newmiller wrote:
On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[ snip ]
I am starting to realize that, perhaps, I should take a directory based
approach to helices' cvs tree.
I have not settled on any particular structure. However, I am wondering
about several things
David Douthitt wrote:
[ snip ]
My model has been the following:
archives/
somearchive.tar.gz
otherarchive.bz2
...
iproute2/
distinfo
Makefile
patches/
somepatchname.diff
somepatchname2.diff
...
work/
, Michael D. Schleif wrote:
No matter how hard I try, I cannot commit a directory structure to cvs.
I get lock failures, even when I try to commit them one directory at a
time.
Clearly, there is some approved process for doing this and I do not know
what that is.
Michael,
I looked
Mike Noyes wrote:
On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote:
No matter how hard I try, I cannot commit a directory structure to cvs.
[ snip ]
I looked at your commit messages, and I think I understand what you were
trying to accomplish. Here is a sequence that I believe
No matter how hard I try, I cannot commit a directory structure to cvs.
I get lock failures, even when I try to commit them one directory at a
time.
Clearly, there is some approved process for doing this and I do not know
what that is.
Also, what is this limitation that all files must use
Mike and I were discussing cvs off-list. Since much of this is
un-structured now, perhaps, we can impose some user-friendly and
consistent form on our cvs tree.
I am starting to realize that, perhaps, I should take a directory based
approach to helices' cvs tree.
I have not settled on any
Jeff Newmiller wrote:
On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[ snip ]
[1] Should I have separate trees for different underlying versions of
net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating
building and committing both v4.2.5 and the totally different
Mike Noyes wrote:
On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
Jeff Newmiller wrote:
On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[1] Should I have separate trees for different underlying versions of
net-snmp? For example, I committed net-snmp v4.2.4. I am
Several months ago, Charles and I had an off-list discussion regarding
several dcd related issues. I know that he has his todo list, to which
I've contributed possible solutions; but, I also have issues with which
I've struggled on my own.
One thing that Charles and I want to do is remove all
Michael D. Schleif wrote:
[ snip ]
One thing that Charles and I want to do is remove all user configurable
parameters from all init scripts. To that end, I have reviewed all
/var/lib/lrpkg/*.conf, based on this list of packages that I use:
[ snip ]
My removal recommendations are based
guitarlynn wrote:
On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote:
Also, in standard dcd v1.0.2, what program uses /etc/rpc?
NFS and SUN login. I think a few people are using this style
of access on LEAF boxes.
O, now I see it:
/etc/init.d/mountnfs.sh
OK, /etc/rpc
Nathan Angelacos wrote:
I'm curious about /etc/group modification?
I've upgraded two (2) potato's and two (2) woody's. Yes, there is a
new user in passwd/shadow; but, I do not have any new group for
sshd.
Yes, I have seen the instructions for installing manually; but, I
cannot find
Jacques Nilo wrote:
[ snip ]
At this point, a default compile of OpenSSH will use privilege separation
with the sshd user. For new LEAF installations/releases, do we want to
deviate from the (new) OpenSSH standard, or accomodate it and move on?
I have a clear position on this: we
Nathan Angelacos wrote:
I'm curious about /etc/group modification?
I've upgraded two (2) potato's and two (2) woody's. Yes, there is a
new user in passwd/shadow; but, I do not have any new group for
sshd.
Yes, I have seen the instructions for installing manually; but, I
cannot find
Here is a patch for /etc/ipfilter.conf [DCD, v1.0.2], the need for which
I discovered while researching my multiple external interface challenge:
# diff -bu ipfilter.conf ipfilter.conf.OLD
--- ipfilter.conf Mon May 6 16:30:20 2002
+++ ipfilter.conf.OLD Mon May 6 16:10:14 2002
@@
Although there are already several other ntpclient.lrp's out there, this
one is different:
[1] It is the smallest that I've found:
# ls -al ntpclient.lrp
-rw-r--r--1 helices leaf 7651 Apr 26 09:32 ntpclient.lrp
[2] It includes an init script starting, stopping and configuring the
Charles Steinkuehler wrote:
Although there are already several other ntpclient.lrp's out there, this
one is different:
snip
http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.txt
http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.lrp
I'm finally getting
As I recall, prior to the recent changes to
http://leaf.sourceforge.net/, there was a link to a developer's site
via the main menus on the leftmost side to this page.
Perhaps, I am thinking of the Main Menu | Developer Content link.
However, would it be valuable to put these links under
Recently, I have seen several posts regarding searches for items seen in
LEAF articles quite in the past.
I also have found myself looking for something that I'd swear I had seen
on the main ttp://leaf.sourceforge.net/ page, or in the rightmost Past
Articles column.
Would it be valuable to
Likewise:
/etc/init.d/netstd_init ???
Michael D. Schleif wrote:
Why does this file exist? It does nothing and wastes space . . .
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding
Charles Steinkuehler wrote:
It sounds almost like you want a minimal set of enumerated binaries and
functions, and then Oxygen would add set X and Dachstein would add set Y.
Nope. No. Nein. Niet. Non. :-)
There is NO baseline.
There is one standard: the formation of a package.
Serge Caron wrote:
I apolologize for leaving in the middle of an important conversation.
Unfortunately, this will happen from time to time. Life gets in the way :-)
I, too, have been erstwhile distracted and now is not the best time to
take on all detractors.
It is disconcerting when one's
Serge Caron wrote:
[ snip ]
In the long term, I want to be able to run from secure media. In the short
term, I use CD for write protected storage and floppy for write-enabled
storage (wich I write-protect between sessions :). Suppose a package
designer stores something in /etc/mypackage
Correction: my bad . . .
Michael D. Schleif wrote:
Voilà!
Serge Caron wrote:
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
Correction #2: my bad . . .
Michael D. Schleif wrote:
Voilà!
Serge Caron wrote:
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files
David Douthitt wrote:
On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote:
I know that it is available; but, it is *not* included in
DCD -- is it included in Oxygen? I do not argue against
its usage; rather, I am often frustrated by lack of real
awk, sed and sort
David Douthitt wrote:
On 2/14/02 at 4:36 PM, Michael D. Schleif [EMAIL PROTECTED] wrote:
For example, /var/log is the standard residence of logfiles.
Is it? Only in Linux apparently; my Unixware and HP-UX systems use
/var/adm/syslog.
I am sorry that you always miss my point.
We
Serge Caron wrote:
[ snip ]
I am waiting for a plane and cannot do that right now. I suggest you visit
http://leaf.sourceforge.net/devel/scaron/leaf.htm with a fresh eye and mess
around with the discussion.img floppy.
Please take apart root.lrp before you start (just for fun!). If I
Serge Caron wrote:
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start
Serge Caron wrote:
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data.
Serge Caron wrote:
[ snip ]
mds said:
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
Linux people are usually more intelligent than I am. Your sed mask allows
for stuff like ...etc and ../../../etc and all kinds of ganes that I prefer
not to play
Voilà!
Serge Caron wrote:
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
which files comprise the ${pkg} package -- correct?
Once
Serge Caron wrote:
[ snip ]
By formulating the concept of a default store and that of an exclusion list,
here is _what_I_do_today_ : I boot from a CD which gives me all the storage
I need for the job at hand. I define my default store to be on the _floppy_.
So far, so good? Then I have
Hello
Finally, I am a card carrying member of your elite group of raconteurs!
Hopefully, the stories I tell will be of some value to somebody here ;
Although, most of you are very private and hold your credentials close
to your chest, I've been around the horn several times in more than
Serge =
Serge Caron wrote:
I got my first paycheck from a computer center (as they were called then :)
in September 1970. You do the math. It is obvious that your message below
was heathfelt and the product of a long experience. I respectfully request
that you humor me into reading this
kp =
I am releasing -- to you, per your request -- my three (3) leaf/lrp
packages based on NET-SNMP. Descriptions for each package follow.
For whatever reason, I cannot get cvs access
http://leaf.sourceforge.net/devel/helices -- anybody know what I need
to do to become a card carrying leaf
Surely, all of you experienced LRP'ers have tackled this one!
OK, I build a new application on a slink development box. Once I do
`make install', how do I know an exhaustive list of *ALL* files to turn
into the LRP file?
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Matt Schalit wrote:
And remember, mds, there's:
make -n install
to output the commands but not execute them.
Cool! I didn't know that one . . .
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is
David Douthitt wrote:
On 2/8/02 at 1:08 PM, Michael D. Schleif [EMAIL PROTECTED] wrote:
Hence, my interest in filesystem and file location standards . . .
This is exactly the reason for the restrictive djbtools license - he
wants his code to be in EXACTLY the SAME place in EVERY
David Douthitt wrote:
On 2/8/02 at 5:23 AM, Mike Noyes [EMAIL PROTECTED]
wrote:
At 2002-02-08 00:43 -0600, David Douthitt wrote:
So how important is setting the time/date with date? Is rdate
(or ntpclient) enough?
I think it's important to have the correct date. My ISP
Is there some kind of standard whereby, when building a new LEAF
package, we know *where* particular files belong?
From my brief experience, it appears that most LRP packages are built
with non-default file locations. For example (not to pick on you,
Andrew ;), netsnmpd.lrp puts configuration
OK, first off, with my recent problems with netsnmpd.lrp, I need to roll
my own ;
So, off I goto my slink development box and start compiling.
[1] For the life of me, I cannot figure out how the libraries grew 300%
between v4.2.1 and v4.2.3!
This is the current netsnmpd.lrp:
# ls -al `find
Charles Steinkuehler wrote:
I studied why Charles coded this the way it is and decided that this
simple rc script is probably the best way. Since the current mechanism
bases the backup destination on whence the package last came -- this is
a good thing -- I don't see an easy fix.
KP Kirchdörfer wrote:
the backup destination of packages points by default to cdrom, which
is write-protected by technology...
Could this be changed easily to default to /dev/fd0?
Cosmetic change, I know, for leaf-die-hards, but something new user
might be disattracted.
This is what
Charles Steinkuehler wrote:
For instance, just because your /var/cache maybe full, do you want to
arbitrarily purge /var/log files?
Not for an instant do I suggest that such complexity is insurmountable;
rather, it should be clear that this is far more involved and requires a
new
Charles Steinkuehler wrote:
I will at least apply the one line fix in the next release. For the
future,
I'd like to see support for a configuration directory. There would be
some
default entries, while add-on packages could drop entries into the
/etc/purge.d (or whatever)
KP Kirchdörfer wrote:
Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif:
KP Kirchdörfer wrote:
Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif:
I'll probably try to get the script to check *ALL* currently
mounted, writable file-systems...maybe
[RFC] DCD checkfreespace() vs. multiple filesystems
There has been some debate regarding /etc/cron.daily/multicron-d and one
of its functions, checkfreespace(), the default configuration for which
does *not* recognize nor act on multiple filesystems.
What follows is my proposed modification to
Charles Steinkuehler wrote:
Following problem:
Using Dachstein and creating a separate ramdisk /dev/ram1 for
/var/log malfunctions lrp.conf spacecheck.
I think the spacecheck intention is to monitor /var/log, cause there
are the most changes in file size during the routers lifetime
David Douthitt wrote:
On 12/16/01 at 7:35 PM, Michael D. Schleif [EMAIL PROTECTED] wrote:
Nevertheless, I am getting this output:
Loki:/home/mds/iptraf-2.5.0/src# make
gcc -Wall -O2 -DWORKDIR=\/var/local/iptraf\
-DLOGDIR=\/var/log/iptraf\ -DEXECDIR=\/usr/local/bin\
-I/usr
Current lrp instances of iptraf cannot see anything, except ethernet
devices.
Since I've been working with wanpipe, I've a requirement to debug tcp
issues and want to use iptraf.
iptraf v2.5 documentations states:
``IPTraf 2 requires Linux 2.2. It now uses the new PF_PACKET socket
family as
Am I the doofus or what?
My only excuse is, when my lrpkg.cfg looks like this, it is easy to miss
one:
Charles Steinkuehler wrote:
Did you see my post about net-snmp? This package requires libdb.so.2 which
is not part of the libraries on the Dachstein CD. I found the file on the
Debian web site in the libdb++ package. Did you include it in either of
your net-snmp packages? If not, what
Michael D. Schleif wrote:
Charles Steinkuehler wrote:
Did you see my post about net-snmp? This package requires libdb.so.2 which
is not part of the libraries on the Dachstein CD. I found the file on the
Debian web site in the libdb++ package. Did you include it in either of
your
Charles Steinkuehler wrote:
[ snip ]
Rebuilt log.tgz (part of ramlog.lrp) using busybox tar in hopes of
eliminating broken pipe messages appering on some systems.
Did I tell you that that fixes the problem?
Of course, in my modified instance, it took me quite sometime to figure
out how
Charles Steinkuehler wrote:
As always, this is truly superb stuff! Bravo, Charles !!!
Couple questions, even though these items appeared in RC5:
[1] What is the purpose of the ``leaf'' user?
It was in Jacques' example passwd file...I added it mainly as a 'stub' entry
for
Charles Steinkuehler wrote:
The official release (v1.0.1) of Dachstein-CD is now available for download
from the usual places:
slow:
http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/
fast:
http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/
Michael D. Schleif wrote:
Charles Steinkuehler wrote:
The official release (v1.0.1) of Dachstein-CD is now available for download
from the usual places:
slow:
http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/
fast:
http://lrp1.steinkuehler.net/files/diskimages/dachstein
Charles Steinkuehler wrote:
I haven't tried bash.lrp since pre-release. There used to be two
(2)
bash-related problems; now, I find one (1):
Mounting local filesystems...
ramdisk.pkg: Uncompressing archives -
log.tgz/etc/rcS.d/S36ramdisk.pkg:
line 33:
Jacques Nilo wrote:
I have updated openssh packages to their latest 2.9.9p2 version.
They are compiled statically against openssl-0.9.6b and dynamically
against zlib-1.1.3
See:
http://leaf.sourceforge.net/devel/jnilo
Excellent!
Charles, is this that version that you are adding to
Charles Steinkuehler wrote:
I haven't tried bash.lrp since pre-release. There used to be two
(2)
bash-related problems; now, I find one (1):
Mounting local filesystems...
ramdisk.pkg: Uncompressing archives -
log.tgz/etc/rcS.d/S36ramdisk.pkg:
line 33:
Charles Steinkuehler wrote:
I haven't tried bash.lrp since pre-release. There used to be two (2)
bash-related problems; now, I find one (1):
Mounting local filesystems...
ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg:
line 33:
1001 Broken
Charles Steinkuehler wrote:
The third release-candidate version of Dachstein-CD is now available. This
version feels like it's getting pretty close to done. Lots of minor
chagnges, none of them show-stoppers, just getting everything working the
way it should. This version is the first
Michael D. Schleif wrote:
Charles Steinkuehler wrote:
The third release-candidate version of Dachstein-CD is now available. This
version feels like it's getting pretty close to done. Lots of minor
chagnges, none of them show-stoppers, just getting everything working the
way
Charles Steinkuehler wrote:
I have new kernels available, which include patches for a couple recent
kernel bugs:
[ snip ]
I notice that your site
http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/CD-Contents/
indicates file change dates more recent than your original issue of
Charles Steinkuehler wrote:
I have new kernels available, which include patches for a couple recent
kernel bugs:
[ snip ]
I notice that your site
http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/CD-Contents/
indicates file change dates more recent than your original
Charles Steinkuehler wrote:
I've just put a new version of the Dachstein pre-release CD image online:
http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/
When I do this:
tar tvfz root.lrp var
on my woody box, I find this file:
Charles ==
Just a note:
If you are going to use bootdisk.bin instead of bootdisk.ima, please,
replace all references to bootdisk.ima in README.TXT };Þ
Charles Steinkuehler wrote:
I have released a preliminary version of Dachstein-CD. Based on Dachstein,
LRP-CD, and extensive modifications
Charles ==
As a deployer of several instances of LRP-CD, I am clearly interested in
Dachstein-CD. However, I'm having some difficulty getting this going ;
``Searching for Boot Record from Floppy..OK
SYSLINUX 1.62 . . .
. . . splash screen . . .
Loading root.lrp
Boot failed: please change
my bad -- i needed to change cmos ;
it's ok now . . .
Michael D. Schleif wrote:
Charles ==
As a deployer of several instances of LRP-CD, I am clearly interested in
Dachstein-CD. However, I'm having some difficulty getting this going ;
``Searching for Boot Record from Floppy..OK
93 matches
Mail list logo
