Hi Paul,
Sorry for the delay getting back to you, just got back from a week on
the playa lighting up dust storms with 2.4 and 5.8ghz wifi... :-)
;-)
The reason I'm not really enthusiastic about this idea is that it adds a
new dependency between sylinux, initrd and the etc package and also
Sorry for the delay getting back to you, just got back from a week on
the playa lighting up dust storms with 2.4 and 5.8ghz wifi... :-)
The reason I'm not really enthusiastic about this idea is that it adds a
new dependency between sylinux, initrd and the etc package and also adds
extra
Hi Paul,
What it saves them from having to do is hand mess with etc.lrp on a
second system the very first time they load the flash.
There is absolutly no need for that. We will release some specific
configdb packages for certain types of hardware, so it's just a matter of
copying the right
Hi Paul,
Hmmm, not sure. I find it a bit of a clutch. What happens if an user
edit the inittab for other changes like mgetty?
I prefer specific configdb/sylinux.cfg for different hardware where
also other changes can be done.
Eric
--Apple-Mail-3-25159442
Content-Type: multipart/mixed;
Hi Paul,
A real /etc/inittab is always present, it's part of the etc.lrp
package...
Eric
Look at the script. If a real /etc/inittab is present, it doesn't do
its magic.
It only does it if the proto is present and /etc/inittab is not.
This is one of the most annoying things for a new user
Hi Paul,
Not if it's not. You're the software developer, you make the
distribution etc.lrp. The whole point of this thing is to get people
running with a working console. Once they're on their feet, i.e. if
they edit the /etc/inittab or do a backup after the real inittab is
working,
Eric Spakman wrote:
Hi Paul,
Not if it's not. You're the software developer, you make the
distribution etc.lrp. The whole point of this thing is to get people
running with a working console. Once they're on their feet, i.e. if
they edit the /etc/inittab or do a backup after the
