Re: [sisuite-users] Yet another SDA/HDA problem
Hi On Fri, Jul 20, 2007 at 01:05:20AM +0200, Thomas Krause wrote: Any ideas? I could probably use overrides or change some scripts to work around this, but I want to avoid ugly hacks if possible. The clients are Dell Optiplex GX110 with an Ubuntu 7.04 image. I have some Dells. Recently the kernel modules for ide-scsi switched to hda and then back to sda. The SI installer kernel and the image kernel see a different device name. UYOK should overcome this, but... To get rid of all this I do, in the master script, and I still use the SI kernel: mount /dev /a/dev -o bind ln -s /dev/hda1 /dev/sda1 before the systemconfigurator part, which includes --runboot, which includes grub (or lilo). That symlink is good enough for grub-install. Of course your fstab and all those things stay the final device name. IIRC, the parted and mkfs sections will also need the device names that the installer see. cheers, Jan -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Wiki updates
Wade Hampton wrote: G'day, I just joined the wiki and made a few changes. I added some notes about using the kernel+initrd to reload a box (bypassing PXE), and fixed a few typos. I hope this info helps. Thanks for the help with systemimager. I am finally figuring out how to make it work in my environment. Very good! Thanks for the contribution. -Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] reimage a remote computer -- couple of questions....
Wade Hampton wrote: Simply append them in your grub.conf in the kernel line (in a single line). Note: you are limited to 256 characters in the kernel command line (see the docs for the 2.6.22 kernel and include/asm/setup.h). This works, but since my names on the server were dhcp1, dhcp2, etc., I had to also use SCRIPTNAME=dhcp1.sh. You have the 256 chars limit depending on the kernel you're using. Anyway in recent kernels this limit has been increased to 2048 characters. If this limit is too small you can define additional parameters via local.cfg: - create a /tmp/local.cfg (see for example doc/examples/local.cfg, or http://svn.systemimager.org/filedetails.php?repname=systemimagerpath=%2Ftrunk%2Fdoc%2Fexamples%2Flocal.cfgrev=0sc=0) - use si_mkbootpackage to re-create your kernel+initrd.img with your local.cfg included. It is even possible to use BOEL with si_mkbootpackage, for example: # mkdir /tmp/boot-package/ # si_mkbootpackage --destination /tmp/boot-package \ --kernel /usr/share/systemimager/boot/i386/standard/kernel \ --filesystem cramfs --config /tmp/local.cfg --yes I will have to write a post-install script to get these from variables.txt and setup networking on the new image (e.g., 98all.setup_networking). If you want to access them as env variables in your post-install scripts source the file /tmp/variables.txt on the top of your scripts. Can I add my own variables to this file? Yes. How can I add my own? I see how the kernel*txt file contains my own vars, but they don't make it to variables.txt (for example, I defined USER1=X,Y,Z). You can variableize the kernel parameters parsing /proc/cmdline and add the vars to /tmp/variables.txt. For example: cat /proc/cmdline | tr ' ' '\n' | grep '=' /tmp/kernel_append_parameter_variables.txt FEATURE REQUEST: Maybe a couple user variables could be added to si such as USER1=string, USER2=string, and these could be copied to variables.txt. Another feature might be to also copy the kernel variables file to /tmp/post-install? OK, appending kernel parameters to variables.txt seems a good idea (in a way similar to the script above). In this case we could have all the installation parameters as env variables available for our post-install scripts. FEATURE REQUEST: Could we add awk to the default busybox image (good for pre-install scripts that could use awk)? NACK. I think it's better to have a light initrd.img: this is very very important in massive installation when you have hundreds or thousands of nodes (typically HPC clusters) and the transfer of the initrd.img via TFTP could be a critical bottleneck in these cases. I am installing CentOS 5 using Systeminstaller 3.8.1. Also, I would like to mirror my systemimager server, but to a separate network. The instructions expect the networks to be connected. What directories would I need to copy besides /var/lib/systemimager, /usr/share/systemimager, and /tftpboot? Install the systemimager server packages in the mirror and simply use si_cpimage: mirror:~/# si_cpimage --server orig_image_server source_image destination_image That will work if they are on the same network or are connected. I need to copy the image to a DVD then move it to the other, non-connected network. Unfortunately you can't use si_cpimage if your image servers are not connected to a network. So, to copy your image using a DVD you have to manually do the following steps: 1) copy your image to the mounted DVD: # cp -af /var/lib/systemimager/images/your_image /media/dvd/ 2) copy the rsync_stub: # cp -p /etc/systemimager/rsync_stubs/40your_image /media/dvd What about /usr/share/systemimager/boot and /tftpboot? Correct. If you're using UYOK you have to copy also the UYOK files. -Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Yet another SDA/HDA problem
Thomas Krause wrote: Hello again, I have the following problem. My master client (Virtual Machine) uses /dev/hda as hard disk. The other clients use /dev/sda. If I understand correctly this shouldn’t be a problem because the master script will correct the necessary files. However for some reason the client hard disk shows up as /dev/hda (instead of /dev/sda) during the SI installation scripts so that the master script does not change the files. As soon as I boot into the new installed kernel, the hard disk is available as /dev/sda again and the boot (obviously) fails. My first idea was that this was that the BOEL kernel detects the hard disk differently than the kernel that the client has, so I configured SI to use UYOK (without --my-modules switch to support more clients), but I have the same problem. Any ideas? I could probably use overrides or change some scripts to work around this, but I want to avoid ugly hacks if possible. The /dev/[hs]da naming depends on the udev configuration. Theoretically to fix this problem the SI environment should be able to use the same udev configuration of your image. Unfortunately it's not so easy to find a solution for this problem. A simple copy of /etc/udev/ into the initrd.img is not a clean solution (ugly hack), because the udev configuration of your image could use binaries, packages, etc that will be not available from the busybox environment. Maybe you could try to replace all the occurrences of hd with sd in /usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d/* (saving the original files!) and re-create a kernel+initrd.img with si_mkbootpackage... My $0.02... -Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Yet another SDA/HDA problem
If I understand correctly udev will use the kernel name by default, when no matching rule with a NAME action is found, but I can't find any rule that matches hard disks and reNAMEs a device node, neither in the systemimager default, nor in my ubuntu client. And as I already said they are using the same kernel. So by using the same kernel the original name should already be the same and never be changed by udev. Am I missing something here? And speaking of ugly hacks, instead of replacing everything in rules.d/*, couldn't I just add a rule like: KERNEL==hda, NAME=sda KERNEL==hdb, NAME=sda to my (virtual) golden clients udev-rules, so that the original image already has the correct devices? If this works I believe this would be a better hack (tm), since it would only affect my golden client and it would make it more similar to the real clients. Thanks, Thomas Krause -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andrea Righi Gesendet: Freitag, 20. Juli 2007 12:49 An: sisuite-users@lists.sourceforge.net Betreff: Re: [sisuite-users] Yet another SDA/HDA problem Thomas Krause wrote: Hello again, I have the following problem. My master client (Virtual Machine) uses /dev/hda as hard disk. The other clients use /dev/sda. If I understand correctly this shouldnt be a problem because the master script will correct the necessary files. However for some reason the client hard disk shows up as /dev/hda (instead of /dev/sda) during the SI installation scripts so that the master script does not change the files. As soon as I boot into the new installed kernel, the hard disk is available as /dev/sda again and the boot (obviously) fails. My first idea was that this was that the BOEL kernel detects the hard disk differently than the kernel that the client has, so I configured SI to use UYOK (without --my-modules switch to support more clients), but I have the same problem. Any ideas? I could probably use overrides or change some scripts to work around this, but I want to avoid ugly hacks if possible. The /dev/[hs]da naming depends on the udev configuration. Theoretically to fix this problem the SI environment should be able to use the same udev configuration of your image. Unfortunately it's not so easy to find a solution for this problem. A simple copy of /etc/udev/ into the initrd.img is not a clean solution (ugly hack), because the udev configuration of your image could use binaries, packages, etc that will be not available from the busybox environment. Maybe you could try to replace all the occurrences of hd with sd in /usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d/ * (saving the original files!) and re-create a kernel+initrd.img with si_mkbootpackage... My $0.02... -Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
