Hi, Ben wrote: > On Tue, 15 Jan 2008, Paul Dekkers wrote: > >> Ben wrote: >> >>> I'm currently running RHEL 5.1 64-bit fully patched and kernel >>> 2.6.18-53.1.4.el5xen on a Sun x4200 M2 (8GB, 4 cores). I am attempting >>> to install RHEL 4.6 32-bit (kernel 2.6.9-67xen) as a paravirtualised >>> guest. >> >> I recently stumbled upon the same issue, using a RHEL 5.1 64-bit dom0 >> (running on a Dell PE 1850), and RHEL 4.6 32-bit as domU. I tried >> installing using virt-install and a kickstart file. > > Virt install just doesn't seem worth it to me to be honest. I'd rather > write my own configuration and just boot that, editing it for pygrub > etc. after install. Thanks for the confirmation though!
Works too, this saves me some time I guess, (and one command like this is easily documented ;-)) >> I'm afraid this is why running a 32-bit domU on 64-bit dom0 is a >> "technology preview" (see release notes)... as I had limited time, I >> just went ahead with a 32-bit dom0, that worked fine. > > Which is what I'm doing right now. Thanks for _that_ confirmation too! Oh, and as for PAE: the kernel is using the 4G in this machine, so I suppose PAE is working fine too; performance seems OK, never compared it with a 64-bit environment though. >>> Every time I try the install manually (I haven't figured out Xen >>> kickstarting yet, suggestions on how to provide a kickstart file to the >>> DomU please?) I whistle through the setup screens and then let the >> >> I'm using something similar to (fill in the dots): >> >> virt-install --name=test32 --nographics --paravirt --ram=512 >> --file=/dev/vg0/test --location=http://.../ >> --extra-args=ks=http://.../ks.cfg > > OK, how does test32 get access to the kickstart file given that that's > where test32's network information is stored? Does virt-install pass > the contents of ks.cfg to test32 somehow during initialisation? No, the kickstart does DHCP, you can pass an ip-address in the extra-args among with the kickstart though, if you like (or if there is no DHCP available), The real address comes from the kickstart, but you can use DHCP in there too, of course (with --bootproto dhcp), >> %post >> ( >> cat > /sbin/ifup-local << EOF >> #!/bin/sh >> ethtool -K \${1} tx off >> EOF >> chmod a+x /sbin/ifup-local >> rpm --import /usr/share/rhn/RPM-GPG-KEY >> /usr/sbin/rhnreg_ks --nohardware --activationkey=... >> up2date -uf >> ) 1>/root/post_install.log 2>&1 >> >> (My kickstart includes a RHN registration using an activation key, and >> the ifup-local script, that does a ethtool -K eth0 tx off, as that is >> apparently necessary for traffic between domU's.) > > Curious. I've never seen anyone do that before. I don't usually > register an installation with RHN until after reboot and first login. That works too of course, but this saves some work ;-) and I like to run an up2date at this stage too, so you have an up-to-date start, > Plus I put the activation key in the main body of the kickstart with > > key xxxx-xxxx-xxxx-xxxx Ah, ok. Well, you don't need that with RHEL 4, do you? >>> [slow] >> >> Same here >> >>> [kernel panic] >> >> Similar here > > It's nice to see it's consistent anyway! Yes, sad that it's not available yet, but now we have something to look forward too ;-) >> Not much help, but I can at least confirm this issue ;-) > > No, thanks, lots of good corroborative evidence. If you want to explain > (please) that kickstart file thing off the list, I'd be grateful! I hope this is what you meant, Paul _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
