[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sisuite-users
Subject:    Re: [sisuite-users] a SLES 10 problem
From:       Andrea Righi <a.righi () cineca ! it>
Date:       2007-09-02 9:38:57
Message-ID: 46DA84B1.70404 () cineca ! it
[Download RAW message or body]

Andrea Righi wrote:
> keyesky wrote:
> > the golden client has  SLES 10 installed, sd based driver.
> > 
> > more etc/fstab
> > /dev/sdb2            /                    reiserfs  
> > acl,user_xattr        1 1
> > /dev/sdb1            swap                 swap      
> > defaults              0 0
> > /dev/VolGroup00/LogVol01 swap                 swap      
> > defaults              0 0
> > proc                 /proc                proc      
> > defaults              0 0
> > sysfs                /sys                 sysfs     
> > noauto                0 0
> > debugfs              /sys/kernel/debug    debugfs   
> > noauto                0 0
> > usbfs                /proc/bus/usb        usbfs     
> > noauto                0 0
> > devpts               /dev/pts             devpts    
> > mode=0620,gid=5       0 0
> > 
> > 
> > and i image it to another server, restore successfully ,but when start
> > the restored one , i got following error:
> > 
> > 
> > loading reiserfs
> > waiting for device /dev/sda2 to appear: input: PS/2 Generic mouse as
> > /class/input/input2
> > ........................ not found -- exiting to /bin/sh
> > $
> > 
> > i am new to systemimager. Just got this work from somebody who left.
> > can anyone give me some idea? thanks a lot !!
> 
> This seems to be a systemconfigurator issue... and I'm quite sure about
> it.. which version of SC are you using? Anyway, quickly looking at the
> code the problem seems to be present also in the latest release.
> 
> The point is that the /dev/sda was not found by the modules that you
> have in your initrd (the initrd of your SLES10 image).
> 
> Look at the modules defined in /etc/sysconfig/kernel (the INITRD_MODULES
> parameter) in your image, and probably they don't match with the modules
> required by your clients.
> 
> Has the client you're trying to install a different hardware respect to
> your original golden client?
> 
> As a workaround you could define a post-install script (see
> /var/lib/systemimager/scripts/post-install/README) to re-create the
> initrd at the end of the imaging, including all the needed modules that
> can be found in /etc/systemconfig/hardware.lst.
> 
> A simple post-install script should be following (untested).
> 
> -Andrea
> 
> ---
> [/var/lib/systemimager/scripts/post-install/50suse10.update_initrd]
> 
> #!/bin/sh
> 
> # Get modules from /etc/systemconfig/hardware.lst
> hw_modules=`sed 's/  */ /g' /etc/systemconfig/hardware.lst | cut -d' ' -f4`
> 
> # Add all the SC modules to INITRD_MODULES in /etc/sysconfig/kernel
> perl -pi -e "s/\\s*INITRD_MODULES\\s*=\"(.*)\"/INITRD_MODULES=\"\$1 $hw_modules\"/" \
> /etc/sysconfig/kernel 
> # Re-create the initrd
> /sbin/mkinitrd
> 

OK, I was able to reproduce this problem cloning a golden client with suse10 and
imaging another client with a different HD controller.

I can confirm that the post-install script above fixes the problem. Basically I
think that we should handle this kind of issues in systemconfigurator, but I see
that systemimager doesn't invoke systemconfigurator with --configrd to update
the ramdisk.

The point is that the initrd in the image is never updated and we keep the
original. Anyways, this seems to be the right approach for the other distro (for
example everything works fine with Ubuntu, because all the available block
device modules are included into the initrd).

So, if the problem occurs only with SuSE, IMHO the simplest solution would be to
always execute this post-install script (we should call it for example:
50all.update_initrd) and perform the initrd update operations only when
/etc/sysconfig/kernel exists (that probably means we're imaging a suse).

What do you think?

-Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
sisuite-users mailing list
sisuite-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-users


[prev in list] [next in list] [prev in thread] [next in thread]