We just tried to image our bran-spank'n new server (Socket F/Opteron 2218) with some new-fangled nVidia chip set housing an NFORCE MCP55 GbE mac. Apparently, the version of the busybox kernel SIS is using does not support this chip. We are running....
systemimager-server-3.8.2-1.noarch systemimager-common-3.8.2-1.noarch systemimager-client-3.8.2-1.noarch systemimager-x86_64boot-standard-3.8.2-1.noarch Is there a busybox kernel or newer version of SIS that supports the various devices in this MCP55 chipset? Or do we just twiddle the device id table and rebuild so that it knows that the forcedeth driver should work? Thanks, Charlie Taylor UF HPC Center lspci output below.... [EMAIL PROTECTED] log]# lspci 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Miscellaneous Control 02:00.0 Memory controller: Mellanox Technologies MT25208 [InfiniHost III Ex HCA Flash Recovery] (rev a0) 03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) 04:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 04:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 07:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 07:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 80:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 80:01.0 RAM memory: nVidia Corporation MCP55 LPC Bridge (rev a3) 80:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) 80:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 80:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 80:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 80:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 80:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 80:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 80:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 80:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 80:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 80:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 80:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 81:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 81:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 85:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 85:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 86:00.0 Ethernet controller: Chelsio Communications Inc Unknown device 0030 On Sep 11, 2007, at 9:44 AM, Andrea Righi wrote: > Carl J. Benson wrote: >> Andrea Righi wrote: >>> Carl J. Benson wrote: >>>> Hello. >>>> >>>> I have a cluster of Dell 1950 PowerEdge servers. The S.I. server >>>> and clients have S.I. version 3.8.2 installed. The OS on server >>>> and clients is openSUSE 10.2. >>>> >>>> The client PXE boots OK, and the master script for the image >>>> starts to execute. All goes surprisingly well until this bit >>>> of the master script: >>>> >>>> # Wipe the MBR (Master Boot Record) clean. >>>> logmsg "dd if=/dev/zero of=$DISK0 bs=512 count=1 || shellout" >>>> dd if=/dev/zero of=$DISK0 bs=512 count=1 || shellout >>>> >>>> At which point the script dies because there is no /dev/zero. >>>> >>>> "ls /dev" shows that there are files in /dev, just no /dev/zero. >>>> >>>> If I comment out the dd line, the partitioning proceeds, the >>>> restore >>>> runs great, and the new cluster node boots -- at least on my test >>>> node. I haven't tried it on a brand new 1950 just out of the box. >>>> I think it might fail if the MBR isn't wiped clean, because Dell >>>> systems come with stuff on the disk drive already. >>>> >>>> Can someone tell me how to get /dev/zero in there? >>>> >>> This looks strange... are you using UYOK or the default BOEL kernel >>> (http://wiki.systemimager.org/index.php/UYOK)? You shouldn't have >>> problems with BOEL since udev seems to correctly create it. >>> Anyway, I >>> think it should be good to permanently add it into the >>> initrd_template >>> to avoid this kind of problems with udev. Could you try to create it >>> into the initrd template and re-create the boot package? I mean, in >>> your golden client run a: >>> >>> # mknod -m 600 /usr/share/systemimager/boot/<golden_client_arch>/ >>> initrd_template/dev/zero c 1 5 >>> >>> Then re-run si_prepareclient (and if you want also si_getimage). >>> >>> You should find the boot package (kernel + initrd.img) in >>> /etc/systemimager/boot in your golden client or (if you re-run also >>> si_getimge) in /usr/share/systemimager/boot/<arch>/<imagename> in >>> your >>> image server. This new boot package should have /dev/zero into the >>> initrd.img. >>> >>> Regards, >>> -Andrea >> >> Andrea, >> >> I'm using UYOK, because I wanted the megaraid_sas driver. >> I don't know if that's in the BOEL kernel, though I suppose >> I could experiment and find out. >> >> I created a /dev/zero exactly as you described, but it didn't >> make it into initrd.img. I don't know why not. >> >> On the chance that there was a mknod command at that point, >> I added this code to the master script, just before "Wipe >> the MBR clean": >> >> # Make a /dev/zero. >> logmsg "mknod -m 600 /dev/zero c 1 5 || shellout" >> mknod -m 600 /dev/zero c 1 5 || shellout >> >> It looks like this worked. The partitioning went OK. >> >> Thanks for your help. >> >> I plan to drag another node up from the warehouse, and >> see if this setup will correctly partition a brand new >> PowerEdge 1950. >> > > So, probably the reason is that udev didn't create it after it has > been > started (see stard_udevd in /etc/init.d/functions into the initrd for > details). > > Instead of creating /dev/zero manually you should try to configure > udev > to do that. For example could you try to add an entry like the > following: > > KERNEL=="zero", NAME="zero" > > in: > > /usr/share/systemimager/boot/<golden_client_arch>/standard/ > initrd_template/etc/udev/rules.d/20-names.rules > > After that you should re-create the initrd with si_prepareclient or > si_mkbootpackage and try again with the new initrd. > > I know that the simplest solution for you should be to directly create > /dev/zero in the master script, but it would be great for us to have a > feedback to resolve this bug in a cleaner way... > > Thanks, > -Andrea > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > sisuite-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sisuite-users ------------------------------------------------------------------------- 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
