Hi, I tried it with the following rules in /etc/udev/rules.d/19-hd2sd.rules in my golden client:
KERNEL=="hda", NAME="sda" KERNEL=="hda[1-9]", NAME="sda%n" With these rules, I can work with my client as if my hard disk is really an sda (/etc/fstab is working with the sdaX-partitions, etc.). I had only 2 problems so far: 1.) for the kernel root-parameter you still need the original partition name. To solve this I'm now using disk labels for the kernel parameters as well as for /etc/fstab. 2.) Everything related to partitions in the proc-filesystem is still working with original real names (obviously). This shouldn't be a big problem normally, but si_prepareclient for example uses /proc/partitions to detect partitions in the system and then shows a warning because it cannot find the devices mentioned there. However the script still continues and worked fine on my system. To get rid of the warning I explicitly excluded /dev/hda with the -e option. I guess this won't work if you have partitions that are not currently mounted, but this is not a problem for me. After this change I still had some problems when I wanted to install the image on a real client, because SystemImager was now (correctly) expecting an sda hard disk, but the real clients showed up as hda during the installation (see previous posts). To fix this I made the same modifications as above to /usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d/ * and ran si_mkbootpackage. After that change it worked, but I also noticed that now the hard disks were already sda even without the udev rules. The difference to the previous configuration was that I did not use si_mkbootpackage the first time, but instead copied the kernel+initrd from /etc/systemimager/boot from my golden client to the /tftpboot-directory. I don't understand exactly what the difference between these two methods is and especially why si_mkbootpackage creates a new initrd, if si_prepareclient already does that, but I'm glad it works now... The udev-rules may still be useful for systemimager, for other sda vs. hda problems (I saw a few of them in the mailing list) and I like them better than creating symbolic links as suggested here. And of course they were are also useful for me to make my virtual golden client more similar to the real clients, so that I don't need systemconfigurator or other tools to change my configuration later on. Thomas Krause -----Ursprüngliche Nachricht----- Von: Andrea Righi [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 21. Juli 2007 16:51 An: Thomas Krause Cc: [email protected] Betreff: Re: [sisuite-users] Yet another SDA/HDA problem Thomas Krause wrote: > 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 It would great if you (or someone) could test if this solution fixes the problem. If it works we could write something to "detect" when this operation is needed at the golden client side and add those udev rules via UYOK stuff. Thanks, -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 [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
