"initrd" with command line parameters
Helmut Hullen
I need some possibility to boot a machine via "initrd" and telling
"initrd" another "root device" than the pre-installed device in the
"initrd".
Background: I make kernels and initrds for other machines, for unknown
machines (with P-ATA, S-ATA, SCSI, Compaq-Array, ...).
When I run "mkinitrd", the script takes the root device from my machine
(which doesn't fit everywhere - it's /dev/hda6), or I tell the skript to
take another root device (p.e. "/dev/cciss/c0d0p1"), which doesn't fit
everywhere.
The template contents of the initrd is packed in
/usr/share/mkinitrd/initrd-tree.tar.gz
Is there any way to let the "init" script look for parameters on the
command line?
If there is a way: what is to be changed in "lilo.conf"?
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
+Alan Hicks+
Hash: SHA1
On 2008-04-16, Helmut Hullen <hel...@hullen.de> wrote:
> I need some possibility to boot a machine via "initrd" and telling
> "initrd" another "root device" than the pre-installed device in the
> "initrd".
>
> Background: I make kernels and initrds for other machines, for unknown
> machines (with P-ATA, S-ATA, SCSI, Compaq-Array, ...).
>
> When I run "mkinitrd", the script takes the root device from my machine
> (which doesn't fit everywhere - it's /dev/hda6), or I tell the skript to
> take another root device (p.e. "/dev/cciss/c0d0p1"), which doesn't fit
> everywhere.
>
> Is there any way to let the "init" script look for parameters on the
> command line?
Yes, but it won't be simple.
The initrd mounts the proc filesystem at /proc (inside the initrd's /
basically) and you could grab a kernel commandline option from
/proc/cmdline, but that only gets you half-way.
The initrd's init grabs the root device and the root filesystem from
the /rootdev and /rootfs files respectively. You will have to
over-ride this in init to use whatever partition and filesystem you
specified on the kernel's commandline.
Specifying those commandline arguments in lilo.conf is fairly trivial;
they are just "append=" lines in each image statement.
I hope that helps. It's a very interesting problem, and I don't think
anyone who has worked on mkinitrd has considered it before. Please let
us know how it turns out for you, or if you run into any other
problems. Could you explain why it is necessary to make these initrds
on a computer they will not be run on? If it's a big problem for more
than a handful of people, I might look into submitting a patch for
mkinitrd to handle this when the next -current opens up.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkgHppgACgkQrZS6hX/gvjpXvwCgsdW15FO9KhucjeJmOVzJhHmG
E5wAoN1kwzPQXhHgAJtCZNBmkNElusPX
=BZqh
-----END PGP SIGNATURE-----
Helmut Hullen
Du meintest am 17.04.08:
>> Is there any way to let the "init" script look for parameters on the
>> command line?
> Yes, but it won't be simple.
> The initrd mounts the proc filesystem at /proc (inside the initrd's /
> basically) and you could grab a kernel commandline option from
> /proc/cmdline, but that only gets you half-way.
> The initrd's init grabs the root device and the root filesystem from
> the /rootdev and /rootfs files respectively. You will have to
> over-ride this in init to use whatever partition and filesystem you
> specified on the kernel's commandline.
> Specifying those commandline arguments in lilo.conf is fairly
> trivial; they are just "append=" lines in each image statement.
http://jootamam.net/howto-initramfs-image.htm
shows a way to import command line parameters - I'll try. Frank Paulsen
has send me the link.
And Frank Boehm has tried
http://www.baldar.de/pub/eeePC/initrd-tree-xl.tgz
for the ASUS EEE.
> I hope that helps. It's a very interesting problem, and I don't
> think anyone who has worked on mkinitrd has considered it before.
Look for "Process command line options" in the first mentioned page -
maybe that paragraph is all Patrick might add to the actual "init"
script in "/usr/share/mkinitrd/initrd-tree.tar.gz".
> Please let us know how it turns out for you, or if you run into any
> other problems. Could you explain why it is necessary to make these
> initrds on a computer they will not be run on?
Look at
http://arktur.de/download.php
(end of the page)
The installation CD is used in many schools, it's used from colleagues
with no skills in linux. They don't like to install a new server instead
of porting only the disks (or the backups) from an old server to a new
server.
Without an initrd perhaps they must run
rdev bzImage </dev/newmachine>
But with an initrd they must run "mkinitrd" on the new machine, but the
old disk won't boot.
I make the "general purpose" kernel with the "general purpose" initrd
for these school servers (p.e. without sound, without video4linux - a
pure server doesn't need them). And the initrd has to fit for P-ATA, for
S-ATA, for SCSI, for Compaq CCISS etc.
> If it's a big problem for more than a handful of people, I might look
> into submitting a patch for mkinitrd to handle this when the next -
> current opens up.
Sounds good.
A colleague and I try since 2 weeks to transfer and run the contents of
an IDE disk to a Compaq Proliant ("/dev/cciss/c0d0px").
Copying the data is simple. Changing the initrd.gz without a second
machine is nearly impossible, and the only necessary change is
"rootdev", from "/dev/hda1" to "/dev/cciss/c0d0p1".
Please excuse my gerlish ...
Helmut Hullen
Du meintest am 17.04.08:
> The initrd mounts the proc filesystem at /proc (inside the initrd's /
> basically) and you could grab a kernel commandline option from
> /proc/cmdline, but that only gets you half-way.
Just an idea: may it be possible for the "init" script to look for an
"initrd.conf" file and overwrite the hard coded parameters?
For testing I work with many kernels, I sort them per
/boot/<kernel>-<ext>
p.e.
/boot/2.6.24.3-ODS/.config
System.map
bzImage
initrd.gz
And then a nice place would be in this special directory, next to the
wanted kernel and the wanted initrd.
Joseph Rosevear
> /usr/share/mkinitrd/initrd-tree.tar.gz
> Viele Gruesse
> Helmut
Hallo Helmut,
I have a solution that I use that I think would meet your needs. As
Alan said, it is not simple. It is like Frank's method, but you do not
recompile busybox.
I do it by making a boot disk (Joe's Boot Disk) which is a CD. This
method also uses grub. This works well and is able to do what you
said. You can put the disk into a machine and boot.
It lets you pick a kernel from the kernels that are on the CD. And it
let's you specify boot parameters (for example, "vga=791"). Then it
uses the initrd.gz which is on the CD.
The initrd.gz has a modified init script and other changes. Script init
prompts you for partition name (for example, "/dev/sda4") and file
system type (for example, "ext3").
I have two scripts that I use to make boot disks. The first script
makes the initrd.gz file. The second uses the initrd.gz file to make a
grub boot CD (Joe's Boot Disk).
Both scripts are called "prep". Here is a prep script that makes
initrd.gz (on my computer it has this path
/opt/SAM/config/resurect/ramdisks/080418aa/prep):
vvv
#!/bin/sh
# prep, by Joe Rosevear
# This makes a new initrd.gz file. Run this as root from the dir that
# contains this. Note that this script puts files and dirs in
# initrd-tree before making initrd.gz.
# The way it puts them there uses "follow" and "asis" dirs. These
# refer to what they do to symbolic links. Either can have files that
# are meant to be copied "as is", but only "asis" should have symbolic
# links that are to be preserved as links. Links that are to be
# followed should go in "follow".
# Remake current
rm -R ../current
mkdir ../current
# Make a starter initrd-tree in current.
# The accompanying initrd.gz will be overwritten later.
mkinitrd -s ../current/initrd-tree -o initrd.gz
# add prep to current
cp -pi prep ../current
# copy and follow links when copying
mv follow initrd-tree -i
cp -RLp initrd-tree ../current
mv initrd-tree follow -i
# copy and copy links "as is"
mv asis initrd-tree -i
cp -Rdp initrd-tree ../current
mv initrd-tree asis -i
# to avoid accidents remove prep's execute permission
chmod ugo-x ../current/prep
# put note in dir with pwd
pwd > ../current/pwd.txt
pushd ../current
mkinitrd -s initrd-tree -o initrd.gz
popd
cp ../current/initrd-tree/initrd.gz .
^^^
To understand what this does you will need to see directories (dirs)
follow and asis.
I'll pause here to let you catch up.
-Joe
Helmut Hullen
Du meintest am 19.04.08:
>> I need some possibility to boot a machine via "initrd" and telling
>> "initrd" another "root device" than the pre-installed device in the
>> "initrd".
> I have a solution that I use that I think would meet your needs. As
> Alan said, it is not simple. It is like Frank's method, but you do
> not recompile busybox.
Looks fine, but it sounds like much additional work for me, "eternal"
additional work.
Ok - I can do this work (just the time I have to do it ...). But it
might be a better way (for me) if some other guy puts this option into
the official slackware script.
You need it, Frank needs it, I need it - maybe there are many other
people who also would appreciate this option.
Joseph Rosevear
> Du meintest am 19.04.08:
> Viele Gruesse
> Helmut
Helmut,
I'm offering to show you how I do it.
You might find that it is worth the trouble.
-Joe
Helmut Hullen
Du meintest am 17.04.08:
>> I need some possibility to boot a machine via "initrd" and telling
>> "initrd" another "root device" than the pre-installed device in the
>> "initrd".
[...]
> It's a very interesting problem, and I don't think anyone who has
> worked on mkinitrd has considered it before.
I've just looked into the way SuSE uses. Seems like SuSE's "initrd" can
read command line parameters and/or parameter files.
But the way seems to be more than strange ... the biggest obstacle:
parameter files are stored in "/lib/mkinitrd", one directory for all
the different parameters I might use for different kernels. I prefer a
configuration file (or directory) in the same directory where the
(special) initrd (and perhaps the special kernel) is stored.
Helmut Hullen
Du meintest am 19.04.08:
>> I need some possibility to boot a machine via "initrd" and telling
>> "initrd" another "root device" than the pre-installed device in the
>> "initrd".
> I have a solution that I use that I think would meet your needs. As
> Alan said, it is not simple. It is like Frank's method, but you do
> not recompile busybox.
> I do it by making a boot disk (Joe's Boot Disk) which is a CD. This
> method also uses grub. This works well and is able to do what you
> said. You can put the disk into a machine and boot.
The way you describe is similar to my actual way.
First I use slackware's "mkinitrd" with a very long modules list to make
the first stage initrd (one of the options: "-c").
Then:
mkdir -p /tmp/initram
cd /tmp/initram
zcat /path/to/first_stage_initrd.gz | cpio -vim
Then I fill up the "dev" directory with the many other devices the disks
may need, p.e. "/dev/cciss/c0d0pxy".
Last step in this routine:
find . | cpio -o -H newsc | gzip > /path/to/final_dist_initrd.gz
And my self made kernel packages use (in the "install/doinst.sh" script)
the lines
# Root-Device
Pfad=boot/<new_kernel_version>
while read Device Mount Rest
do
case $Mount in
/)
Rootdev=$Device
;;
esac
done < etc/fstab
test "$Rootdev" || exit
(cd $Pfad; rdev bzImage $Rootdev)
test -s $Pfad/initrd.gz || exit
Pwd=$(pwd)
(cd $Pfad; mv --backup=t initrd.gz initrd.gz-alt)
mkdir -p tmp/initram
cd tmp/initram
zcat $Pwd/$Pfad/initrd.gz-alt | cpio -vim
echo $Rootdev > rootdev
find . | cpio -o -H newc | gzip > $Pwd/$Pfad/initrd.gz
cd $Pwd
#
----------------------
It works, but it's no nice way. Making the distribution initrd may be a
bit more comfortable - but it's no hard way.
The steps in the "install/doinst.sh" might be more comfortable. "rdev"
works fine and understandable. Some similar routine for invoking initrd
may make the install routine more simple and safe. And if I can tell the
needed parameters in "/etc/lilo.conf"or at the boot prompt life may be
nicer.
Vincent Batts
> Hallo, Joseph,
>
> Du meintest am 19.04.08:
>
>>> I need some possibility to boot a machine via "initrd" and telling
>>> "initrd" another "root device" than the pre-installed device in the
>>> "initrd".
>
>> I have a solution that I use that I think would meet your needs. As
>> Alan said, it is not simple. It is like Frank's method, but you do
>> not recompile busybox.
>
> Looks fine, but it sounds like much additional work for me, "eternal"
> additional work.
>
> people who also would appreciate this option.
>
> Viele Gruesse
> Helmut
as far as referring to suse, that is a *very* confusing process, and one
i wouldn't neccesarily recommend as a model, i think
it might have something to do with grub to, see the excerpt from a suse
boxes /boot/grub/menu.lst :
<paste>
title 2.6.18.2-34
root (hd0,3)
kernel (hd0,1)/vmlinuz-2.6.18.2-34-default root=/dev/sda4 vga=0x31A
resume=/dev/mapper/swap splash=verbose showopts
initrd (hd0,1)/initrd-2.6.18.2-34
</paste>
where root for this entry is sda4 and /boot is sda2, / is passed to the
bootloader and to the kernel
but when you mkinitrd on suse, the init configurations save the default
rootdev from the host system that built it, to use if nothing else is
passed to it from the bootloader and kernel command line
vb
Joseph Rosevear
> Hallo, Joseph,
> Du meintest am 19.04.08:
> >> I need some possibility to boot a machine via "initrd" and telling
> >> "initrd" another "root device" than the pre-installed device in the
> >> "initrd".
> > I have a solution that I use that I think would meet your needs. As
> > Alan said, it is not simple. It is like Frank's method, but you do
> > not recompile busybox.
> > I do it by making a boot disk (Joe's Boot Disk) which is a CD. This
> > method also uses grub. This works well and is able to do what you
> > said. You can put the disk into a machine and boot.
> The way you describe is similar to my actual way.
> First I use slackware's "mkinitrd" with a very long modules list to make
> the first stage initrd (one of the options: "-c").
[snip]
Hallo Helmut,
You gave some interesting information. I learned a few things.
Especially, I didn't know how to make an initrd.gz except by use of
mkinitrd. And I didn't know how to expand an initrd.gz. Thank you!
It looks like you aren't interested in using a boot disk? I'm not
sure, but it seems you want to make packages that both install a kernel
and make an initrd.gz that can be used by lilo. Have I got it right?
This way the user just installs your package, and bingo, he has a
bootable machine?
What I've done is a little different. It would be a shift of thought
from what you are doing. Maybe it would help. You decide.
My way is to make a grub CD with one or more kernels on it. The
initrd.gz includes modules for the various kernels and it has commands
that I might want to use in the first stage of booting. Script init
prompts the user like this:
vvv
ERR=1
#JHR 060706
#Do this until the mount succeeds
while [ ! "$ERR" = "0" ]; do
echo
echo "Type the partition name you wish to boot followed,"
echo "optionally, by the filesystem type (default: $ROOTFS)."
echo "Then press <Enter>."
echo
read partition fstype
ROOTDEV=/dev/"$partition"
if [ "$fstype" != "" ]; then ROOTFS="$fstype"; fi
if [ "$partition" = "command" ]; then
ash
ERR=1
else
###
cat << done
*** continue reading here ***
done
###
echo "doing \"mount -o ro -t $ROOTFS $ROOTDEV /mnt\""
mount -o ro -t $ROOTFS $ROOTDEV /mnt
ERR="$?"
if [ ! "$ERR" = "0" ]; then
###
cat << done
The partition you named could not be mounted. Did you enter the name of
the partition correctly? Is there a device of that name in the boot
disk's /dev? Is the filesystem type correct?
You may try again.
Or you may quit. If you wish to quit, please switch off the computer,
then switch off the external drive or unplug it. You may optionally
remove the boot disk before switching off the computer.
done
###
fi
fi
done
^^^
When the disk boots grub gives a menu that allows the user to choose a
kernel.
So the user of my boot disk needs to think a little. He needs to
choose the right kernel, and he needs to enter the partition and the
file system name.
I made this so I could run Slackware on a USB hard drive plugged into
many different boxes. And it makes setting up a new Slackware
installation easier. I skip the steps about lilo and the kernel.
My machines won't boot without the boot disk, but there are benefits.
OK, there is the work of making the boot disk.
Also something special... notice the line in init that runs ash? That
helps to boot a stubborn or broken system. I can use commands depmod,
fdisk, insmod, ldconfig, ls, lsmod, mkdir, modprobe, mount, mv, pwd,
rmmod, umount, vi, and a few others at the command line during the
first stage of the boot. Helpful.
-Joe
Helmut Hullen
Du meintest am 22.04.08:
> You gave some interesting information. I learned a few things.
> Especially, I didn't know how to make an initrd.gz except by use of
> mkinitrd. And I didn't know how to expand an initrd.gz. Thank you!
No thanks - I've learned changing the initrd last week ...
> It looks like you aren't interested in using a boot disk?
Kernel: about 1.8 MByte
initrd.gz: about 1.8 MByte
No chance for a Floppy disk.
> I'm not sure, but it seems you want to make packages that both install
> a kernel and make an initrd.gz that can be used by lilo. Have I got
> it right?
> This way the user just installs your package, and bingo, he has a
> bootable machine?
Yes - that's the way I need. And it seems to work now with the (ugly)
way to expand, change and repack the initrd.
> What I've done is a little different. It would be a shift of thought
> from what you are doing. Maybe it would help. You decide.
If I have understood your way you make a CD-ROM with all your needs -
it's not for installing on a hard disk.
I need the multi purpose kernel an initrd for a schoolserver which is
installed by people with no practice in linux.
> My way is to make a grub CD with one or more kernels on it. The
> initrd.gz includes modules for the various kernels and it has
> commands that I might want to use in the first stage of booting.
> Script init prompts the user like this:
I don't like grub ... but that's not the major problem.
> vvv
> ERR=1
> #JHR 060706
> #Do this until the mount succeeds
> while [ ! "$ERR" = "0" ]; do
> echo
> echo "Type the partition name you wish to boot followed,"
> echo "optionally, by the filesystem type (default: $ROOTFS)."
> echo "Then press <Enter>."
Imagine a teacher (m/f/n) on a primary school with no experience in
linux. He/she/it will only install a schoolserver, and the system asks
him/her those nasty things.
> So the user of my boot disk needs to think a little. He needs to
> choose the right kernel, and he needs to enter the partition and the
> file system name.
And that's too much for colleagues who only want a running machine (like
a hoover or a frigidaire).
> I made this so I could run Slackware on a USB hard drive plugged into
> many different boxes. And it makes setting up a new Slackware
> installation easier. I skip the steps about lilo and the kernel.
> My machines won't boot without the boot disk, but there are benefits.
It's a very interesting way, and I'll take a long look on it. But it
needs an experienced user (I am! Sure!!!!11).
> OK, there is the work of making the boot disk.
Just one problem: new laptops have no floppy disk drive, news desktops
and towers have no floppy disk drive.
My IBM Thinkpad T2x allows changing the CD-ROM drive against a floppy
disk drive, but I haven't seen yet a floppy disk drive for my T40.
Mainboards have still a connector for the floppy disk drive - may be it
will vanish in the next years.
Please excuse my gerlish.
Joseph Rosevear
[snip]
> Kernel: about 1.8 MByte
> initrd.gz: about 1.8 MByte
> No chance for a Floppy disk.
What floppy disk? The CD-ROM is the boot disk. I make it with this
script. (My initrd.gz is in dir iso. It is referenced by grub when
the user boots.):
vvv
#!/bin/sh
#prep, by Joseph Rosevear.
#Run this from the dir that contains this.
#This makes a grub boot disk to start Slackware on a USB device or IDE.
#functions
########################################################################
burnit() {
# Check $cd_dev against "cdrecord -scanbus" fix if needed.
# Check that $cd_speed is correct for what you are doing.
cdrecord -v speed=`echo -n $cd_speed` dev=`echo -n $cd_dev` $2 -data $1.iso
}
########################################################################
#main
#abort if grub.iso exists
if [ -e ../grub.iso ]; then
echo
echo grub.iso exists
echo aborting...
exit
fi
#make a working dir
rm -R ../../current
mkdir ../../current
cp -RLpi ../iso ../../current
pushd ../../current
#Make the disk image
mkisofs -R -b boot/grub/stage2_eltorito \
-no-emul-boot \
-boot-load-size 4 \
-boot-info-table \
-o grub.iso iso
#Burn cd
if [ "$1" = "rw" ]; then
burnit grub blank=fast
else
burnit grub
fi
popd
cp ../../current/grub.iso ..
^^^
[snip]
> > This way the user just installs your package, and bingo, he has a
> > bootable machine?
> Yes - that's the way I need. And it seems to work now with the (ugly)
> way to expand, change and repack the initrd.
But it works, right?
> > What I've done is a little different. It would be a shift of thought
> > from what you are doing. Maybe it would help. You decide.
> If I have understood your way you make a CD-ROM with all your needs -
> it's not for installing on a hard disk.
That is correct. I may try using my initrd.gz with lilo. This would
give a second way (with no boot disk) to boot the same system.
> I need the multi purpose kernel an initrd for a schoolserver which is
> installed by people with no practice in linux.
Sounds very interesting.
> > My way is to make a grub CD with one or more kernels on it. The
> > initrd.gz includes modules for the various kernels and it has
> > commands that I might want to use in the first stage of booting.
> > Script init prompts the user like this:
> I don't like grub ... but that's not the major problem.
I find grub to be annoyingly obscure, but it does something special...
it can boot from a CD-ROM. The user uses grub only to pick a choice of
kernel from a menu. Then grub uses that choice to start the first
stage of the boot using initrd.gz.
> > vvv
> > ERR=1
> > #JHR 060706
> > #Do this until the mount succeeds
> > while [ ! "$ERR" = "0" ]; do
> > echo
> > echo "Type the partition name you wish to boot followed,"
> > echo "optionally, by the filesystem type (default: $ROOTFS)."
> > echo "Then press <Enter>."
> Imagine a teacher (m/f/n) on a primary school with no experience in
> linux. He/she/it will only install a schoolserver, and the system asks
> him/her those nasty things.
Yes, that's funny. I've already experienced some of the "that's too
hard for me" knee-jerk thinking at the school where I work. There's
no quicker way it seems to lose interest and support than to ask a
person to think.
[snip]
> It's a very interesting way, and I'll take a long look on it. But it
> needs an experienced user (I am! Sure!!!!11).
It takes a little getting used to. You could do it.
> > OK, there is the work of making the boot disk.
> Just one problem: new laptops have no floppy disk drive, news desktops
> and towers have no floppy disk drive.
> My IBM Thinkpad T2x allows changing the CD-ROM drive against a floppy
> disk drive, but I haven't seen yet a floppy disk drive for my T40.
> Mainboards have still a connector for the floppy disk drive - may be it
> will vanish in the next years.
Yes, floppies are a vanishing breed. Sad. Initially I tried to use
floppies to make my boot disks, but as you pointed out, they are too
small. That is what pushed me to learn how to make grub boot disks (on
CD-ROM).
> Please excuse my gerlish.
> Viele Gruesse
> Helmut
> "Ubuntu" - an African word, meaning "Slackware is too hard for me".
Hallo, Helmut,
I understand better now what it is that you are trying to do. I too
have given some thought to providing Slackware servers to people. I
did not think of doing it your way. I work at an elementary school,
and I know about staff that are reluctant to do anything harder than
pushing a button. Still I have been hoping that some people may be
able to use a boot disk (on CD-ROM) and a USB hard drive. My plan was
to prepare USB hard drives and boot disks and distribute them... not
just to staff at school, but to anyone. It sounds like you are farther
along in this than I am. I don't have a product yet, nor have I gotten
a good handle on who my users would be.
This is great what you have done. I am interested to hear how it goes
for you, and I hope it goes well. If I do the same, but using USB hard
drives, then we could compare notes afterwards and learn from each
other... but I think you are way ahead of me.
I was thinking of teaching a class called "An Introduction to Slackware
Linux". Participants would bring USB hard drives to the class and
together we would install Slackware to them. We would try out the
installed systems in the class. Participants would take the USB hard
drives home (or to work) with them. That is what has been in the front
of my thoughts.
So we are going in two slightly different directions.
Good luck to you!
Your gerlish is far better than my engdeutsch.
Auf Wiederlesen
Joe
Helmut Hullen
Du meintest am 23.04.08:
[all about the CD way deleted - it's very interesting!]
> I understand better now what it is that you are trying to do. I too
> have given some thought to providing Slackware servers to people. I
> did not think of doing it your way. I work at an elementary school,
> and I know about staff that are reluctant to do anything harder than
> pushing a button. Still I have been hoping that some people may be
> able to use a boot disk (on CD-ROM) and a USB hard drive. My plan
> was to prepare USB hard drives and boot disks and distribute them...
> not just to staff at school, but to anyone. It sounds like you are
> farther along in this than I am. I don't have a product yet, nor
> have I gotten a good handle on who my users would be.
I only make the server. No GUI. No client. Seems you make the clients.
In germany my colleagues use mostly Edubuntu or Knoppix or SuSE/Novell
for linux clients.
I should take a new look at zenwalk ...
> This is great what you have done. I am interested to hear how it
> goes for you, and I hope it goes well. If I do the same, but using
> USB hard drives, then we could compare notes afterwards and learn
> from each other... but I think you are way ahead of me.
Last week I played with an installation on an USB stick (8 GByte - less
than 30 Euro ...). It didn't boot ... it's a new playground for me.
Joseph Rosevear
> Hallo, Joseph,
[snip]
> I only make the server. No GUI. No client. Seems you make the clients.
> In germany my colleagues use mostly Edubuntu or Knoppix or SuSE/Novell
> for linux clients.
> I should take a new look at zenwalk ...
My colleagues use Macs. And Windows.
[snip]
> Last week I played with an installation on an USB stick (8 GByte - less
> than 30 Euro ...). It didn't boot ... it's a new playground for me.
Ahh. That is where my boot disk steps in to save the day.
> Viele Gruesse
> Helmut
> "Ubuntu" - an African word, meaning "Slackware is too hard for me".
-Joe