Hello,
I ended up finding the source of the problem. My clients failed
to install due to a problem with LILO: 2 of the kernels defined
in /etc/lilo.conf had the same label. The file
/etc/systemconfig/systemconfig.conf (on the client system)
indeed looked as follows:
# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES
[BOOT]
ROOTDEV = /dev/hda6
BOOTDEV = /dev/hda
DEFAULTBOOT = 2.4.18-27.7.x.c
[KERNEL0]
PATH = /boot/vmlinuz-2.4.18-27.7.x.cernsmp
LABEL = 2.4.18-27.7.x.c
[KERNEL1]
PATH = /boot/vmlinuz
LABEL = vmlinuz
[KERNEL2]
PATH = /boot/vmlinuz-2.4.18-27.7.x.cern
LABEL = 2.4.18-27.7.x.c
Though I haven't seen exactly in which script it is done,
I believe that the label is being formed from the kernel
name cutting it to a maximal number of characters since
LILO won't take too long labels. And as a result, KERNEL0
and KERNEL2 in my case end up having the same label,
causing lilo to fail. I patched it by editing systemconfig.conf
and giving a different label to one of the kernels and the
clients installed fine.
Two questions:
1) How does oscar choose the list of kernels to install?
2) Is the problem I just had (same label given to 2 LILO
boot possibilities) a bug to be reported or did I do
something wrong?
Regards,
Vuko
Vuko Brigljevic wrote:
>
> Hello,
>
> Some additional information by looking at the failed client systems
> further (there is some reduced shell functionality available):
>
> The output of df is a bit weird (just copying part of it):
>
> Filesystem Blocks Mounted on
> rootfs 128 MB /
> /dev/root 1 MB /old_root
> tmpfs 128 MB /
> /dev/fd0 1.4MB /floppy
> /dev/hda6 18 GB /a
> /dev/hda1 40 MB /a/boot
>
> Several comments/questions:
> - The partitionning has been done according to what I had set up.
> - The image has appently been correctly copied to
> "/a". I've found there all binaries that are not to be
> found under "/". According to appendix B, the installation
> should at some point chroot to /a, that aparently did not
> happen in my case, but I don't know why.
> - What kind of filesystems are "rootfs" and "tmpfs", ram disks? And how
> comes
> there are 2 entries (rootfs and tmpfs) with the same mount point???
> They
> are obviously the same file system, because the number of bytes of the
> 2
> is exactly the same and they have the same amount of free/used space.
>
> So I am concluding that the rsynch worked but somehow, the clients
> failed in changing root to /a, but I have no clue how and why...
>
> Vuko
>
> Vuko Brigljevic wrote:
> >
> > Hello,
> >
> > I am still stuck in the client installation. I went through
> > all the steps up to Setup Networking in the installation,
> > and everything went OK so far as far as I can tell.
> >
> > I am using the autoinstall floppy to boot the clients.
> >
> > The problem I see:
> > - the installation fails on complaining that it cannot run
> > any boot loader (lilo, grub, ...). I see that the binaries
> > are indeed not there.
> > - A lot of files are also missing, just to name a few: rpm,
> > fdisk, which,... All these files can be found on the server
> > in the image tree /var/lib/systemimager/images/oscarimage/
> > Somehow the rsynch did not work. In particular, the /var/log
> > directory hasn't been copied on the clients so I can't check
> > for the log files there.
> >
> > Any idea what to look at?
> >
> > Thanks,
> >
> > Vuko
> >
> > --
> > ===========================================================|
> > Vuko Brigljevic, EP Research Fellow |
> > CERN - European Laboratory for Particle Physics |
> > --------------------------------------------------------- |
> > Mail Address: CERN, Div. EP, 1211 Geneve 23 (Switzerland) |
> > Office : B40-2B08 |
> > Phone : +41-22-767 1662 |
> > www : http://cern.ch/vuko |
> > ===========================================================|
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Oscar-users mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/oscar-users
>
> --
> ===========================================================|
> Vuko Brigljevic, EP Research Fellow |
> CERN - European Laboratory for Particle Physics |
> --------------------------------------------------------- |
> Mail Address: CERN, Div. EP, 1211 Geneve 23 (Switzerland) |
> Office : B40-2B08 |
> Phone : +41-22-767 1662 |
> www : http://cern.ch/vuko |
> ===========================================================|
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Oscar-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/oscar-users
--
===========================================================|
Vuko Brigljevic, EP Research Fellow |
CERN - European Laboratory for Particle Physics |
--------------------------------------------------------- |
Mail Address: CERN, Div. EP, 1211 Geneve 23 (Switzerland) |
Office : B40-2B08 |
Phone : +41-22-767 1662 |
www : http://cern.ch/vuko |
===========================================================|
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Oscar-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-users
