Newbie questions about Pliant

Newbie questions about Pliant

Problems installing FullPliant

I have some problems trying to install FullPliant using Pliant-78 running on Linux RedHat 7.3 system.
Message posted by thomasb on 2002/11/25 16:27:00
First off all "Upgrade Debian packages list" does not work unless there is a
"/" at the end of all repositories in /pliant/computer/computer/"some computer"/env/debian/repository

Maybe this is because the compurer.pdb at "" is out of date?

When i try to "Build the target system archive" I get this error message:

Failed to copy file /usr/lib/ to /lib/
Failed to copy file /usr/lib/gcc-lib/i386-linux/2.95.2/cpp to /bin/cpp
Failed to copy file /usr/bin/gcc to /bin/gcc
Failed to copy file /usr/lib/gcc-lib/i386-linux/2.95.2/cc1 to /bin/cc1
Failed to copy file /usr/sbin/grub to /bin/grub
Failed to copy file /usr/lib/ to /lib/
Failed to copy file /boot/boot.b to /boot/boot.b
Failed to copy file /boot/chain.b to /boot/chain.b
as requires
ld requires
ld requires

Message posted by hubert.tonneau on 2002/11/25 16:44:31
I have to upload a new computer.pdb and a new release of Pliant because
the FullPliant installation tend to have small problems from time to time,
due to Debian evolution.

Also I currently have one that works great since it installs Mozilla, OpenOffice
and others nicely.
Message posted by thomasb on 2002/11/25 17:01:03
Ok. There is now hurry.

Btw. Do you think a 32MB harddisc (flash) will be enough?
I am planning to use the computer as router, to share my ADSL-connection.
Message posted by hubert.tonneau on 2002/11/26 18:04:09
Using and the new
http:/ I've just uploaded should bring you
a working FullPliant installation system.
Message posted by hubert.tonneau on 2002/11/26 18:12:43
32 MB will be just enough. Here I have a 486 with 16 MB or RAM and a 100 MB
hard disk running FullPliant and handling NAT, DNS, SMTP plus driving some
home devices through an IO card. The fresh installed system consumes roughly
13 MB.

Here are the three extra constrains you have to check:
. the processor must be an i386 compatible one
. the available memory must be at least 16 MB
. the /tmp/ /pliant_data/ and /pliant_security/ directories must be read-write

Currenly, Pliant will not work at all if /tmp/ directory is read-only.
We might do small changes to allow that and use a RAM disk or even a Pliant
file system, but it's not done yet, mainly because I never tryed to run Pliant
on something with no hard disk.
I don't know if the flash is read-only or read-write.

Also, Pliant will work nicely when running, it will be penfully slow to boot
and restart on a 486 class processor (something like one hour), so It's not the
right plateform to experiment with. Better test everything on a fast system,
then install the small one only when you know that everything is fine. Keep in
mind that also FullPliant is a very powerfull installation system, it's both
young an not very much speaded, so it probably has quite a fiew small bugs or
missing features.
Message posted by thomasb on 2002/11/26 19:05:37
> 32 MB will be just enough. 


> . the processor must be an i386 compatible one

No problem. It's some kind of pentium clone. AMD-K5-PR133

> . the available memory must be at least 16 MB

I have lot of memory, 96 MB

> . the /tmp/ /pliant_data/ and /pliant_security/ directories must be read-write

Should be no problem

> mainly because I never tryed to run Pliant on something with no hard disk. 
> I don't know if the flash is read-only or read-write.

The flash card is a standard CompactFlash connected to build in IDE-controller.
Linux sees it as a standard ATA-disk, with read-write accesss. 

> Also, Pliant will work nicely when running, it will be penfully slow to boot
> and restart on a 486 class processor (something like one hour)

I know, I tried FullPliant on an 486DX50 several moths ago. The computer I am using
now is a lot faster.
Message posted by thomasb on 2002/11/27 15:04:24
I have now successfully completed the installation. I had some problemes but it
seems that they are all related. I had version 3.2.3 of pcmcia-cs, while 3.2.1 
was expected. Kernel compiling then simply fails, with no error message. First
I was trying to be smart, and did some hacks, but that just resulted in several
other problems.

Later discovered that the version is stored in component 'kernel/configuration'.
I have changed it there, and everything seems to be ok.

Anyway, error reporting really have to be improved. 
Eg. "Failed to download some packages" is not very informative. What packages? 
Why did it fail? Too many users on ftp-server? File not found? Download 
interrupted? etc... 
Message posted by thomasb on 2002/11/27 15:18:00
I tried to upgrade the computer by uploading a fullpliant.tgz in file:/boot/.
The upload failed for some reason, the file was just about 2.7MB of 6.5MB was
uploaded. This resulted in upgrading failing, and computer had to be rebooted.

To make things a bit more robust, I suggest that upgrading is not started until
a valid MD5-sum file is uploaded.

Message posted by thomasb on 2002/11/27 15:35:12
Upload failed because the disc got full. 

The easiest solution is probarly to by a bigger CF-card.

Message posted by hubert.tonneau on 2002/11/27 17:54:21
> Anyway, error reporting really have to be improved.

Fully agreed.
One reason for the current status is that the general design of FullPliant
installation system changed significantly several times during the development
because of constrains related to distribution packages.

Also the general design is now fully stable, this kind of program is the kind
of program that will probably need upgrades from time to time forever since it
has to deal with the kernel make system, with the Debian packaging system,
with Unix details, and with Pliant providing more and more services.

> To make things a bit more robust, I suggest that upgrading is not started until
> a valid MD5-sum file is uploaded.

Basically, cancelling an upload to a Pliant HTTP server should make the uploaded
file to be completely canceled by Pliant HTTP server layer, so not passed to the
application at all.

> Upload failed because the disc got full. 

Pliant will not recover gracefully from a disk full situation.
Also it would not be very difficult for me to provide a receive and untar
on the fly feature in the files browser.
Message posted by thomasb on 2002/11/27 18:25:28
> Pliant will not recover gracefully from a disk full situation.

At least it could check if there is enough space free space for the file, and 
refuse the upload if not.

Anyway, I have bought a 64MB CF-card now, so problem should be avoided.
Message posted by hubert.tonneau on 2002/11/27 22:48:43
> At least it could check if there is enough space free space for the file, and 
> refuse the upload if not.

Not so easy. There may be enough room to receive the file, but not to unpack
it, and there may be enough room at check time, but the database or SMTP server
files can extend in the mean time.

From my point of view, deciding what file to drop when there is not enough room
on the disk is an operating system issue. Basically each file belongs to a group,
each group should be assigned a profile (what percent it is expected to consume),
and when there is not enough room, the operating system should silently delete
files from the group which has exceeded it's profile specifications the most.

If we have only Pliant process, then I could probably do all that within Pliant
instead of the operating system, but in a mixed system with some services from
Pliant and some from other free softwares, it would not work anymore since
these software would not wait for Pliant to make room in case of starvation.
Once again, it is probably possible to do it mostly in Pliant through starting
to drop files before the all disk space is full, but once again, it's not very
reliable, and it would not scale to other potencial starvations such as
memory, handles, threads.

So the question is does it worse the effort ?
My current answer is no because Pliant is not the right place to do it so it
would exhaust my development capabilities through facing a huge number of
small problems without the ability to truely solve it once for all.
The right part to hack is the Linux kernel.

The situation seems to be the following: now we have a Linux kernel which is
entreprise level quality (or will soon be with the addition of things like
ReiserFS 4 and stabilisation of the VM and scheduler), but is far from beeing
small compagny level quality.
A large entreprise will run one service only on each server, so it want's
benchmark records so that it can have viewer servers for each service.
On the other hand, a small compagny will buy one server and run all it's service
on it, so needs that one of the services getting crazy cannot disturb others.
In very fiew words, no Unix system can currenly do that decently.

In order to achieve small compagny quality, you need basic hardware safety
such as RAID, but you also need two levels scheduling (first select the group
to run, then the process to run within the group), and you need a profile
notion for all limited ressources (memory, threads, handles, etc) so that in
case of starvation you know what process to kill or what files to delete.