From: [EMAIL PROTECTED] on behalf of Ashley Gould
Sent: Fri 02/12/2005 14:33
To: [email protected]
Subject: Re: [Sisuite-users] Having issues with 3.5.3 in prepareclient
Hmm, tried to send this a few hours ago, but the list says my
post is
too long and is awaiting apporval from the moderator. I've
shortened
the attachment this time. I hope it gets through.
I've
been meaning to test my fixes on other platforms here and then
post
individual bug reports, but I got pulled off onto other things
these
last 2 weeks. I'm attaching my full debugging notes. I came
up with
something like 12 bugs and fixes, and then rebuilt custom
rpms.
On Fri, Dec 02, 2005 at 10:30:08AM -0800, Bernard Li
wrote:
> Hey Ashley:
>
> FYI, this is already fixed in
trunk:
>
> http://svn.sisuite.org/diff.php?repname=systemimager&path=%2Ftrunk%2Flib
>
%2FSystemImager%2FUseYourOwnKernel.pm&rev=0&sc=0
>
> Do you
have any other related patches?
>
> Thanks,
>
>
Bernard
>
> > -----Original Message-----
> > From:
[EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
On Behalf
> > Of Ashley Gould
> > Sent: Friday, December 02,
2005 9:46
> > To: [email protected]
> >
Subject: Re: [Sisuite-users] Having issues with 3.5.3 in prepareclient
>
>
> > I found a bunch of issues running 3.5.3 on an rpm
system
> > (SLES9). This one
> > is because the perl
code which created the initrd does not
> > provide enough
> >
space in the loopback file. Here is extract from my notes:
>
>
> > ______
> > BUG 3: UseYourOwnKernel.pm: sub
_create_initrd_ext2: 534-539
>
> incorrect sizing when
creating loopback file.
> >
> > FIX:
increase $breathing_room to 2000
> >
>
> NOTE: this would be better
controlled by making
> > $breathing_room
>
> some value relative to
total size of $staging_dir or
> > perhaps the
>
> number of blocks mke2fs
wants to create. It's beyond me.
> >
> >
> >
>
> There is not enough space on the loopback device to
> > accomodate
the entire
> > initrd. The loopback file is too small.
>
>
> > # Source of initrd: 18MG
> > osiris:~ # du -ks
/tmp/.systemimager.1
> > 17971 /tmp/.systemimager.1
>
>
> > # loopback file: 18MG
> > osiris:~ # du -ks
/etc/systemimager/boot/initrd
> > 18090
/etc/systemimager/boot/initrd
> >
> > # loopback file mounted:
16MB
> > osiris:~ # df |grep systemimager
> >
/etc/systemimager/boot/initrd
>
>
16185
16185 0 100%
> >
/tmp/.systemimager.2
> >
> > The loopback file needs to be
2000 blocks larger. The available space
> > in the mounted ext2
filesystem is much less than the size of
> > the loopback file.
>
> Perhaps we loose a lot of blocks to administrative space.
>
> Does this vary
> > proportionally to fs size?
> >
>
>
> >
> >
> >
> > Here's the code
>
>
> > sub _create_initrd_ext2($$) {
> >
>
> my $staging_dir =
shift;
> > my
$boot_dir = shift;
>
> my $new_initrd =
$boot_dir . "/initrd";
>
> my $new_initrd_mount_dir =
_mk_tmp_dir();
> >
print ">>> New initrd mount point:
> >
$new_initrd_mount_dir\n" if($verbose);
>
> eval {
mkpath($new_initrd_mount_dir, 0, 0755) };
>
> if ($@) {
>
>
die "Couldn't mkpath $new_initrd_mount_dir $@";
>
> }
> >
>
> my $cmd;
>
>
> > # loopback
file
> > chomp(my $size
= `du -ks $staging_dir`);
>
> $size =~
s/\s+.*$//;
> > #my
$breathing_room = 100;
>
> my $breathing_room =
2000;
> > $size = $size
+ $breathing_room;
> >
run_cmd("dd if=/dev/zero of=$new_initrd bs=1024
> > count=$size",
$verbose, 1);
> >
> >
> >
> > The
patch:
> >
> > gemini0:~ # diff -Naur
UseYourOwnKernel.pm.orig
> > UseYourOwnKernel.pm.ash-fix
> >
---
> >
/usr/lib/systemimager/perl/SystemImager/UseYourOwnKernel.pm.or
> >
ig 2005-10-25 15:16:41.000000000 -0700
> >
+++
> >
/usr/lib/systemimager/perl/SystemImager/UseYourOwnKernel.pm.as
> >
h-fix 2005-11-16 15:08:37.251119171 -0800
> > @@ -534,7 +534,7
@@
> > # loopback
file
> > chomp(my
$size = `du -ks $staging_dir`);
>
> $size =~
s/\s+.*$//;
> > - my
$breathing_room = 100;
> > +
my $breathing_room = 2000;
>
> $size = $size +
$breathing_room;
>
> run_cmd("dd
if=/dev/zero of=$new_initrd bs=1024
> > count=$size", $verbose,
1);
> >
> >
> >
> >
> >
>
>
> >
> >
> >
> >
> >
>
> On Wed, Nov 30, 2005 at 02:48:19AM -0800, Jeremy Hansen wrote:
> >
> I'm attempting to do a prepareclient on a Red Hat EL4
> >
client. This is the
> > > result:
> > >
>
> > Using "sfdisk" to gather information about disk:
> >
> /dev/hda
> > >
> > > Use of
uninitialized value in hash element at
> > >
/usr/lib/systemimager/perl/SystemImager/Common.pm line
> > 1036,
<FH_IN> line
> > > 10.
> > > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/jbd/jbd.ko
> > >
Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/ext3/ext3.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/mii.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/e100.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/e1
> >
000/e1000.ko
> > > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/pci/ho
> >
tplug/shpchp.k
> > > o
> > > Adding:
> >
>
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/usb/ho
> >
st/uhci-hcd.ko
> > > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/acpi/ac.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/acpi/b
> >
attery.ko
> > > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/acpi/button.ko
>
> > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/md/dm-mod.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/md/dm-
> >
mirror.ko
> > > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/net/sunrpc/sunrpc.ko
>
> > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lockd/lockd.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/nfs/nfs.ko
> > >
Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/i2c/i2
> >
c-core.ko
> > > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/i2c/i2c-dev.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/autofs4/autofs4.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/parpor
> >
t/parport.ko
> > > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/char/lp.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/parpor
> >
t/parport_pc.k
> > > o
> > > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/net/ipv6/ipv6.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/crypto/md5.ko
> > >
Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/net/lustre/libcfs.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/net/lustre/portals.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/net/lustre/ksocknal.ko
>
> > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/lvfs.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/obdclass.ko
>
> > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/ptlrpc.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/osc.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/lov.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/mdc.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/fs/lustre/llite.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/block/loop.ko
>
> > Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/char/ppdev.ko
>
> > Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/tun.ko
> >
> Adding:
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/slhc.ko
> >
> Adding:
> > >
> >
/lib/modules/2.6.9-22.0.1.EL_SFS2.0_2smp/kernel/drivers/net/pp
> >
p_generic.ko
> > > >>> Filesystem for new initrd:
ext2
> > > >>> Creating new initrd from:
/tmp/.systemimager.6
> > > >>> find /tmp/.systemimager.6
-depth -exec touch -t
> > 196912311900 '{}' ';'
> > >
>>> New initrd mount point:
/tmp/.systemimager.7
> > > >>> dd if=/dev/zero
of=/etc/systemimager/boot/initrd
> > bs=1024 count=38152
> >
> 38152+0 records in
> > > 38152+0 records out
> >
>
> > > >>> mke2fs -m 0 -N 378 -F
/etc/systemimager/boot/initrd
> > > mke2fs 1.35
(28-Feb-2004)
> > > /etc/systemimager/boot/initrd is mounted; mke2fs
forced
> > anyway. Hope
> > > /etc/mtab is
incorrect.
> > > Filesystem label=
> > > OS type:
Linux
> > > Block size=1024 (log=0)
> > > Fragment
size=1024 (log=0)
> > > 400 inodes, 38152 blocks
> > > 0
blocks (0.00%) reserved for the super user
> > > First data
block=1
> > > Maximum filesystem blocks=39321600
> > > 5
block groups
> > > 8192 blocks per group, 8192 fragments per
group
> > > 80 inodes per group
> > > Superblock backups
stored on blocks:
> >
> 8193, 24577
> >
>
> > > Writing inode tables: done
> > > Writing
superblocks and filesystem accounting information: done
> >
>
> > > This filesystem will be automatically checked every 32
mounts or
> > > 180 days, whichever comes first. Use tune2fs
-c or -i to override.
> > >
> > > >>> mount
/etc/systemimager/boot/initrd
> > /tmp/.systemimager.7 -o loop -t
ext2
> > >
> > > >>> tar -C
/tmp/.systemimager.6 -cf - . | tar -C
> > /tmp/.systemimager.7 -xf
-
> > > tar: ./dev/log: socket ignored
> > > tar:
./usr/sbin/chroot: Cannot write: No space left on device
> > > tar:
Unexpected EOF in archive
> > > tar: Error is not recoverable:
exiting now
> > > FAILED: tar -C /tmp/.systemimager.6 -cf - . | tar
-C
> > /tmp/.systemimager.7
> > > -xf - at
> >
/usr/lib/systemimager/perl/SystemImager/UseYourOwnKernel.pm line
> >
> 649.
> > >
> > > I'm seeing recommendation on the
list to use 3.5.3 with a
> > 2.6 kernel but I'm
> > > also
seeing a lot of issues related to 3.5.3. Is there
> > something
I'm doing
> > > wrong here? The packages I'm using are from
oscar-4.2.
> > >
> > > Also, it seems it was necessary
to install:
> > >
> > >
systemimager-i386boot-standard-3.5.3-3oscar
> > >
systemimager-server-3.5.3-3oscar
> > >
> > > On the
client to get this far, which seemed strange.
> > >
> >
> Thanks
> > > -jeremy
> > >
> >
>
> > >
> > >
> > >
-------------------------------------------------------
> > > This
SF.net email is sponsored by: Splunk Inc. Do you grep
> > through log
files
> > > for problems? Stop! Download the new AJAX
search engine that makes
> > > searching your log files as easy as
surfing the web.
> > DOWNLOAD SPLUNK!
> > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>
> > _______________________________________________
> > >
Sisuite-users mailing list
> > >
[email protected]
> > > https://lists.sourceforge.net/lists/listinfo/sisuite-users
>
>
> > --
> >
> > -ashley
> >
> >
Did you try poking at it with a stick?
> >
> >
>
>
> >
-------------------------------------------------------
> > This SF.net
email is sponsored by: Splunk Inc. Do you grep
> > through log
files
> > for problems? Stop! Download the new AJAX search
engine that makes
> > searching your log files as easy as surfing
the web.
> > DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>
> _______________________________________________
> > Sisuite-users
mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/sisuite-users
>
>
>
>
>
-------------------------------------------------------
> This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files
> for
problems? Stop! Download the new AJAX search engine that
makes
> searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op?ick
>
_______________________________________________
> Sisuite-users mailing
list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sisuite-users
>
--
-ashley
Did
you try poking at it with a stick?
