Re: Simplist way to boot only to a shell

I have taken a little look at PxesconfigModel.pm
I added a trace print to the sum it has computed
and it showed 14352.

Assuming it was just needing a little bump up, 
set it to return 32768 from sub calculate_fssize.  

The result was that I still got the cpio error about
no space left, from pxesconfig.

So I mounted the /tmp/my.initrd it had written
before aborting.  It had only a bin and lost+found.
du -s on bin showed it was 32829 in size.
Strange.  I checked and all of the items that
should be symbolic links to busybox are
actually copies that are 704764 bytes in size. 

That is, I see this:

ls -l /tmp/pxes/bin/
total 32827
-rwxr-xr-x  1 root root 704764 Dec 23 14:30 [
-rwxr-xr-x  1 root root 704764 Dec 23 14:30 ash
-rwxr-xr-x  1 root root   6759 Oct 21 00:07 aumix-minimal
-rwxr-xr-x  1 root root  11300 Oct 21 00:07 autodetect
-rwxr-xr-x  1 root root 704764 Dec 23 14:30 bash
-rwxr-xr-x  1 root root 704764 Dec 23 14:30 busybox
-rwxr-xr-x  1 root root 704764 Dec 23 14:30 cat

So this is what is eating up too much space.

Checking back in /opt/pxes-0.9/stock/dist/bin/
I see most of the executables are indeed
symbolic links to busybox.  Somehow the
copying is changing them to full copies.

Since my last good run of pxesconfig I've updated
several packages on my system (hey, it's
Gentoo).  So there is room for coreutils, or perl
to have become newer and changed the
behaviour of the scripts.

I'm running perl 5.8.5.  I'd think the flaw would
happen from the cp command in sub
check_and_copy (if that is where it happens).

If I try to reproduce this from the shell:

cp -a /opt/pxes-0.9/stock/dist/bin/vi /tmp/pxes
(the latter is mounted /tmp/pxes.initrd),
I get a sym link file of size 7 moved in,
as one would expect.

If I run this line in a perl script, I also get
a symlink:
`cp -a /opt/pxes-0.9/stock/dist/bin/vi /tmp`

So, I'm puzzled why it happens.

The command I'm running is as you
suggested:

pxesconfig -c my.conf -i my.initrd --initialize
--dontreadconfiguration --druid=0

That is what I meant by the normal way
to build a new initrd for my content changes.

Any ideas of things to check?

Regards,

Donald Teed


On Thu, 10 Feb 2005 00:38:44 -0300, Diego Torres Milano
<[email protected]> wrote:
> Something should be wrong somewhere else, because filesystem size is
> computed at runtime.
> Anyway, just increase initrd_fssize_inc in PxesconfigModel.pm.
> 
> On Wed, 2005-02-09 at 22:14, Donald Teed wrote:
> > Hello,
> >
> > I had this working in early January.  Now for some
> > unknown reason I get an error from cpio
> > about not enough space.  All I changed in
> > the building dist area was a small shell script
> > by perhaps 200 bytes size.
> >
> > I run:
> > # pxesconfig -c my.conf -i my.initrd --initialize
> > --dontreadconfiguration --druid=0
> > Initializing ram disk.
> > Fatal error:
> > cpio: write error: No space left on device
> >
> > Looking at /tmp/pxes.initrd size it is 17 MB
> > If I mount it, it does show 100% full.  What can
> > I use to configure the initialized size?
> >
> > I tried some values for INITRD_FSSIZE=
> > in my.conf but it didn't seem to make
> > a difference.
> >
> > My temporary workaround was to uncompress
> > my last good my.initrd, mount it, and copy in
> > my new shell script.  That worked OK.
> > But I'd like to better understand what is
> > doing wrong with doing it the normal way.
> >
> You didn't tell what is the normal way.
> > One other change is that my system kernel
> > (not used by PXES) is changed to a newer one,
> > but still in 2.4 land.  Is there any thing in my
> > kernel environment that could impact this?
> > It is mainly a make oldconfig build, compared
> > to the previous, from what I remember.
> >
> > I'm working with pxes-0.9 .  pxesconfig v 1.36 2004/08/06 04:01:54 diego
> >
> > --Donald Teed


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click