Yes the name is indeed truncated for digestion by LILO. I'll have to
look at the latest code, but that is a bug that should be filed. We
should do something to prevent duplicate labels.

The kernels are chosen by what's in the /boot of the image when it is
built. This is determined by which kernel rpms are in the rpm list
handed to the image build. We take some primitive guesses about which
kernel to use by default, basically putting the SMP one first if it is
there.

Mike


On Thu, 2003-05-29 at 09:55, Vuko Brigljevic wrote:
> 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
-- 
Michael Chase-Salerno           [EMAIL PROTECTED]
IBM Linux Systems Technology    Poughkeepsie, NY 
Advanced Linux Response Team    http://www.ibm.com/linux



-------------------------------------------------------
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

Reply via email to