Oops sent it directly to you. Here it is via the list... Cheers Phill.
-------- Forwarded Message -------- > From: Phill Wombat <[EMAIL PROTECTED]> > To: Blaisorblade <[EMAIL PROTECTED]> > Subject: Re: [uml-user] x86_64 UML won't boot on IBM x336 > Date: Tue, 19 Jul 2005 08:27:50 +1000 > > Hi Paolo, > > Firstly, allow me to compliment you on the quality of your English, I > assume you're a native Italian speaker. I'm sure there's a story just > there... > > ====================================== > FC4 under UML on 32 bit: > > Firstly, I removed (renamed) all */tls to */tls.001. i.e. cd /; find . > -name tls* and then rename them. (possibly not required but I did it > anyway). > > Secondly, do surgery to rc.sysinit. Cut out all lines that refer to > fsck. Turns out fsck uses threads and wants NPTL working. Just cut all > the lines out (it feels painful, but just do it). You can still fsck > your disks from the host by using e2fsck filename (with the UML shutdown > obviously). > > Thirdly, comment out: > > #session required pam_loginuid.so > > in /etc/pam.d/login. Not sure why this is so (possibly NPTL again) but > if you don't then you cannot log in because the PAM backend can't create > a session for you. > > I also fixed inittab commenting out all terminals and only leaving tty0 > so the console comes out the session you started the UML from. I use > this in conjunction with the screen program to provide root console > access for maintenance. > > That's where I am right now. I have really run anything with it yet, but > so far so good. > ==================================== > > The kernel on x86_64: > > I think you've put your finger on it. I am pretty certain now that I'm > trying to run an x86_64 kernel against a 32 bit rootfs. I did not use > the SUBARCH=i386. I tried it but it wouldn't compile, so I sort of hoped > it would just be a 32 bit kernel hosted on x86_64 :( > > This is what I did: > > #!/bin/bash > > VERSION=2.6.12 > PATCHVERSION=2.6.13-rc3 > UML=uml-2.6.12-bs7.patch > > cd /home/phill > rm -rf linux-$VERSION > echo "Unzip linux-$VERSION.tar.bz2" > tar -jxf /home/phill/download/linux-$VERSION.tar.bz2 > #echo "Copy patch-$PATCHVERSION.bz2" > #cp /home/phill/download/patch-$PATCHVERSION.bz2 /home/phill/linux-$VERSION > echo "Copy uml-$PATCHVERSION.bz2" > cp /home/phill/download/$UML.bz2 /home/phill/linux-$VERSION > > cd /home/phill/linux-$VERSION > echo "Unzip $UML into /home/phill/linux-$VERSION" > bunzip2 $UML.bz2 > > patch -p1 < $UML > > make mrproper ARCH=um > make menuconfig ARCH=um > make linux ARCH=um SUBARCH=i386 > > I just exit and save the menuconfig. > > This is what I get if I compile with SUBARCH=i386. > > # > # using defaults found in arch/um/defconfig > # > > > *** End of Linux kernel configuration. > *** Execute 'make' to build the kernel or try 'make help'. > > CHK include/linux/version.h > UPD include/linux/version.h > SYMLINK include/asm -> include/asm-um > SPLIT include/linux/autoconf.h -> include/config/* > HOSTCC scripts/basic/fixdep > In file included from /usr/include/features.h:337, > from /usr/include/sys/types.h:27, > from scripts/basic/fixdep.c:105: > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > directory > scripts/basic/fixdep.c: In function ‘parse_config_file’: > scripts/basic/fixdep.c:245: warning: pointer targets in passing argument > 1 of ‘use_config’ differ in signedness > scripts/basic/fixdep.c: In function ‘parse_dep_file’: > scripts/basic/fixdep.c:299: warning: pointer targets in passing argument > 1 of ‘__builtin_strchr’ differ in signedness > scripts/basic/fixdep.c:299: warning: pointer targets in assignment > differ in signedness > make[1]: *** [scripts/basic/fixdep] Error 1 > make: *** [scripts_basic] Error 2 > > Essentially, this is what I get if I add SUBARCH=i386 at any of the > earlier stages (make menuconfig ARCH=um SUBARCH=i386...) > > It seems pretty clear from your post that I have to have a clean compile > with SUBARCH=i386. > > If I just take the working UML kernel from the 32 bit machine and just > run it, should it work? It seems to start the init process and just > hangs there. Seems to indicate that the 32 bit kernel can tell the CPU > is different and does different things. > > Cheers and thanks for the help > Phill. > > On Mon, 2005-07-18 at 20:33 +0200, Blaisorblade wrote: > > On Monday 18 July 2005 13:45, Phill Wombat wrote: > > > Further to the previous post, > > > > > I noticed, after posting, that the SKAS3 patch is not recognized by the > > > kernel compiled on the x336. > > For 64-bit host kernels, SKAS is still a work in progress. With that patch > > I'm > > able to run some simple test programs, but not UML itself, so you should > > for > > now pass mode=tt on the command line. > > > > Where SKAS mode isn't recognised the SKAS patch is already implied. > > > > > However, here are a couple of lines from the linux kernels from RH73 and > > > FC4/32 booting up (both of which recognize SKAS3 on FC4-x86_64). I just > > > copied the binaries over and ran them: > > > > > > I've compiled up a kernel using FC4 x86_64 patched with > > > > skas-2.6.12-rc4-v9-pre4 after jigging the FC4 rpm spec file. > > > > > > > > I think it should be OK because I can run an FC4 UML (with a few > > > > things *fixed* in the rootfs) > > How did you do that? There was a thread about that but I didn't see any > > "ACK, > > it works" (there was a suggestion about avoiding nash being called). > > > > > > on the 32 bit version of the FC4. (NPTL > > > > can be worked around for the moment in FC4). > > > > > > While I can get the UML booting and working on 32 bit, the 64 bit > > > > machine produces: > > > > > > VFS: Mounted root (ext3 filesystem) readonly. > > > > request_module: runaway loop modprobe binfmt-464c > > > > This is interesting and clear, however I've resumed this below: > > > > http://lists.debian.org/debian-amd64/2004/01/msg00132.html > > > > However there's something I've not clear: are you trying to run a 32 or > > 64-bit > > UML ? I'm not referring to the filesystem, but to the UML kernel itself. > > I.e., do you get that with the same UML binary? > > > > > > So I Google about somewhat and all I can find is some references to > > > > ELF files not being recognized. This in turn causes the OS to modprobe > > > > for the above mentioned module which is meant to gobble up the ELF and > > > > load it. > > > > > > More Googling produces references to AMD x86_64 Opterons not having 32 > > > > bit mode compiled in.... Anyway it's somewhat beyond my understanding > > > > at this stage. The IBM x336 is a Xeon with EM64T. > > It's not an hardware problem, it's not related to the processor, just to > > the > > kernel configuration (both host and guest). > > > > Make sure CONFIG_IA32_EMULATION is enabled on the host, and that you're > > running a 32-bit UML kernel (to compile it on x86_64 host, replace ARCH=um > > with ARCH=um SUBARCH=i386). > > > > And explain what was the configuration, I'm just curious how you got this > > situation... ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
