Hi Mike, Thanks for your reply!
Michael Chase-Salerno wrote: > 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. I submitted the bug in sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=745584&group_id=9368&atid=109368 Regards, Vuko > 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 -- ===========================================================| 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
